[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Google vulnerabilities with PoC
- To: Gynvael Coldwind <gynvael@xxxxxxxxxxx>
- Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
- From: M Kirschbaum <pr0ix@xxxxxxxxxxx>
- Date: Sat, 15 Mar 2014 13:35:43 +0000 (GMT)
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@xxxxxxxxxxx> 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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/