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]

Date: Sat, 15 Mar 2014 13:35:43 +0000 (GMT)
From: M Kirschbaum <pr0ix@...oo.co.uk>
To: Gynvael Coldwind <gynvael@...dwind.pl>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Google vulnerabilities with PoC

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@...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
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/