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: <CAAnPYQ7Qghi-1_zXD5+bHm29g_c+93KoeucBJY6XFL7+e-51Tw@mail.gmail.com>
Date: Sat, 15 Mar 2014 13:45:37 +0100
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: M Kirschbaum <pr0ix@...oo.co.uk>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Google vulnerabilities with PoC

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ