You must be new.
On Sat, Mar 15, 2014 at 3:43 PM, Thomas Williams <thomas@trwilliams.me.uk>wrote:
> I signed onto this mailing list as an interested person in security - not
> to see everyone moan. We will all have differences in opinion and we should
> all respect that. This goes for everyone and I feel I speak for a lot of
> people here, everyone needs to grow up, and shut up.
>
>
>
> Email scanned and verified safe.
>
> On 15 Mar 2014, at 13:43, Mario Vilas <mvilas@gmail.com> wrote:
>
> Sockpuppet much?
>
>
> On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:
>
>> Gynvael Coldwind,
>>
>> What Alfred has reiterated is that this is a security vulnerability
>> irrelevantly of whether it qualifies for credit.
>>
>> It is an unusual one, but still a security vulnerability. Anyone who says
>> otherwise is blind, has little or no experience in hands on security, or
>> either has a different agenda.
>>
>> The obvious here is that Google dismissed it as a non-security issue
>> which I find rather sad and somewhat ridiculous.
>>
>> Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't
>> be much different.
>>
>> Rgds,
>>
>>
>> On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <
>> gynvael@coldwind.pl> wrote:
>> Hey,
>>
>> I think the discussion digressed a little from the topic. Let's try to
>> steer it back on it.
>>
>> What would make this a security vulnerability is one of the three
>> standard outcomes:
>>
>> - information leak - i.e. leaking sensitive information that you normally
>> do not have access to
>> - remote code execution - in this case it would be:
>> -- XSS - i.e. executing attacker provided JS/etc code in another user's
>> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
>> youtube.com)
>> -- server-side code execution - i.e. executing attacker provided code on
>> the youtube servers
>> - denial of service - I think we all agree this bug doesn't increase the
>> chance of a DoS; since you upload files that fail to be processed (so the
>> CPU-consuming re-encoding is never run) I would argue that this decreases
>> the chance of DoS if anything
>>
>> Which leaves us with the aforementioned RCE.
>>
>> I think we all agree that if Mr. Lemonias presents a PoC that uses the
>> functionality he discovered to, either:
>> (A) display a standard XSS alert(document.domain) in a sensitive domain
>> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
>> OR
>> (B) execute code to fetch the standard /etc/passwd file from the youtube
>> server and send it to him,
>> then we will be convinced that this is vulnerability and will be
>> satisfied by the presented proof.
>>
>> I think that further discussion without this proof is not leading
>> anywhere.
>>
>>
>> One more note - in the discussion I noticed some arguments were tried to
>> be justified or backed by saying "I am this this and that, and have this
>> many years of experience", e.g. (the first one I could find):
>>
>> "have worked for Lumension as a security consultant for more than a
>> decade."
>>
>> Please note, that neither experience, nor job title, proves
>> exploitability of a *potential* bug. Working exploits do.
>>
>>
>> That's it from me. I'm looking forward to seeing the RCE exploits (be it
>> client or server side).
>>
>> Kind regards,
>> Gynvael Coldwind
>>
>>
>>
>
>
> --
> “There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to become the
> people.â€
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.â€
On Sat, Mar 15, 2014 at 3:43 PM, Thomas Williams <thomas@trwilliams.me.uk>wrote:
> I signed onto this mailing list as an interested person in security - not
> to see everyone moan. We will all have differences in opinion and we should
> all respect that. This goes for everyone and I feel I speak for a lot of
> people here, everyone needs to grow up, and shut up.
>
>
>
> Email scanned and verified safe.
>
> On 15 Mar 2014, at 13:43, Mario Vilas <mvilas@gmail.com> wrote:
>
> Sockpuppet much?
>
>
> On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum <pr0ix@yahoo.co.uk> wrote:
>
>> Gynvael Coldwind,
>>
>> What Alfred has reiterated is that this is a security vulnerability
>> irrelevantly of whether it qualifies for credit.
>>
>> It is an unusual one, but still a security vulnerability. Anyone who says
>> otherwise is blind, has little or no experience in hands on security, or
>> either has a different agenda.
>>
>> The obvious here is that Google dismissed it as a non-security issue
>> which I find rather sad and somewhat ridiculous.
>>
>> Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't
>> be much different.
>>
>> Rgds,
>>
>>
>> On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <
>> gynvael@coldwind.pl> wrote:
>> Hey,
>>
>> I think the discussion digressed a little from the topic. Let's try to
>> steer it back on it.
>>
>> What would make this a security vulnerability is one of the three
>> standard outcomes:
>>
>> - information leak - i.e. leaking sensitive information that you normally
>> do not have access to
>> - remote code execution - in this case it would be:
>> -- XSS - i.e. executing attacker provided JS/etc code in another user's
>> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
>> youtube.com)
>> -- server-side code execution - i.e. executing attacker provided code on
>> the youtube servers
>> - denial of service - I think we all agree this bug doesn't increase the
>> chance of a DoS; since you upload files that fail to be processed (so the
>> CPU-consuming re-encoding is never run) I would argue that this decreases
>> the chance of DoS if anything
>>
>> Which leaves us with the aforementioned RCE.
>>
>> I think we all agree that if Mr. Lemonias presents a PoC that uses the
>> functionality he discovered to, either:
>> (A) display a standard XSS alert(document.domain) in a sensitive domain
>> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
>> OR
>> (B) execute code to fetch the standard /etc/passwd file from the youtube
>> server and send it to him,
>> then we will be convinced that this is vulnerability and will be
>> satisfied by the presented proof.
>>
>> I think that further discussion without this proof is not leading
>> anywhere.
>>
>>
>> One more note - in the discussion I noticed some arguments were tried to
>> be justified or backed by saying "I am this this and that, and have this
>> many years of experience", e.g. (the first one I could find):
>>
>> "have worked for Lumension as a security consultant for more than a
>> decade."
>>
>> Please note, that neither experience, nor job title, proves
>> exploitability of a *potential* bug. Working exploits do.
>>
>>
>> That's it from me. I'm looking forward to seeing the RCE exploits (be it
>> client or server side).
>>
>> Kind regards,
>> Gynvael Coldwind
>>
>>
>>
>
>
> --
> “There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to become the
> people.â€
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
--
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.â€
