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] [day] [month] [year] [list]
Message-ID: <CAJB2Jzs9LV0obJoQJ+R+DobQqW=3N-qkv9+99a=gozAUpmwbjg@mail.gmail.com>
Date: Sat, 15 Mar 2014 12:08:29 +0100
From: Mario Vilas <mvilas@...il.com>
To: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Fwd: Google vulnerabilities with PoC

That is not what this email says. You can't reply "correct" to criticism
and pretend it's praise.


On Sat, Mar 15, 2014 at 6:11 AM, Nicholas Lemonias. <
lem.nikolas@...glemail.com> wrote:

> Correct.
>
> The mime type can be circumvented. We can confirm this to be a valid
> vulnerability.
>
> For the PoC's :
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> On Fri, Mar 14, 2014 at 8:40 PM, Krzysztof Kotowicz <
> kkotowicz+fd@...il.com> wrote:
>
>>
>> 2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. <lem.nikolas@...glemail.com
>> >:
>>
>> Then that also means that firewalls and IPS systems are worthless. Why
>>> spend so much time protecting the network layers if a user can send any
>>> file of choice to a remote network through http...
>>>
>>
>> No, they are not worthless per se, but of course for an user content
>> publishing service they need to allow file upload over HTTP/s. How far
>> those files are inspected and later processed is another question - and
>> that could lead to a vulnerability that you DIDN'T demonstrate.
>>
>> You just uploaded a .sh file. There's no harm in that as nowhere did you
>> prove that that file is being executed. Similarly (and that has been
>> pointed out in this thread) you could upload a PHP-GIF polyglot file to a
>> J2EE application - no vulnerability in this. Prove something by overwriting
>> a crucial file, tricking other user's browser to execute the file as HTML
>> from an interesting domain (XSS), popping a shell, triggering XXE when the
>> file is processed as XML, anything. Then that is a vulnerability. So far -
>> sorry, it is not, and you've been told it repeatedly.
>>
>>
>> As for the uploaded files being persistent, there is evidence of that.
>>> For instance a remote admin could be tricked to execute some of
>>> the uploaded files (Social Engineering).
>>>
>>
>> Come on, seriously? Social Engineering can make him download this file
>> from pastebin just as well. That's a real stretch.
>>
>> IMHO it is not a security issue. You're uploading a file to some kind of
>> processing queue that does not validate a file type, but nevertheless only
>> processes those files as video - there is NO reason to suspect otherwise,
>> and I'd like to be proven wrong here. Proven as in PoC.
>>
>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ