full-disclosure - Re: Google vulnerabilities with PoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJB2Jztgx0gGMbePvsLtwnbkUQc3Kj_7zBPfNLr_H_4doiysjA@mail.gmail.com>
Date: Sat, 15 Mar 2014 14:17:05 +0100
From: Mario Vilas <mvilas@...il.com>
To: Gynvael Coldwind <gynvael@...dwind.pl>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
 M Kirschbaum <pr0ix@...oo.co.uk>
Subject: Re: Google vulnerabilities with PoC

Thank you. :)


On Sat, Mar 15, 2014 at 1:45 PM, Gynvael Coldwind <gynvael@...dwind.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.”

Content of type "text/html" skipped

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