Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC
From: Thomas Williams <thomas () trwilliams me uk>
Date: Sat, 15 Mar 2014 14:43:37 +0000

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.

On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <gynvael () coldwind pl> wrote:

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
(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/

Attachment: smime.p7s

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]