I haven't read the whole thread, so I apologize in advance for commenting
on it. But I think it's important to mention that "not a vulnerability" and
"not exploitable" are entirely different concepts. Since conclusively
proving that a vulnerability is 100% not exploitable for all code paths in
all possible environments is difficult at best (if not downright
impossible), you can still consider something a vulnerability even if you
don't have a proof of concept - you can assign it lower risk, of course,
but it doesn't disappear, because there's at least a theoretical
possibility that it may be exploited.
So, let's not get into a flame war yet. :)
On Fri, Feb 7, 2014 at 12:15 AM, Egidio Romano <resea...@karmainsecurity.com
> wrote:
> Hello again,
>
> today a little bird known as "i0n1c" twitted something about me [1],
> claiming that I was wrong, and that CVE-2014-1860 could actually be
> exploited, "because there is S: which allows encoded NUL bytes" [2], and
> that's true in part. So, instead of using a string like this:
>
> O:9:"ZipWriter":1:{s:10:"\0*\0strTemp";s:11:"/etc/passwd";}
>
> An attacker might be able to bypass the filter implemented within the
> Input::xssClean() method because she can also use a string like this:
>
> O:9:"ZipWriter":1:{S:10:"\00*\00strTemp";s:11:"/etc/passwd";}
>
> The Input::xssClean() method removes not only NULL bytes, but also the
> string "\0", meaning that the above string will be converted to:
>
> O:9:"ZipWriter":1:{S:10:"0*0strTemp";s:11:"/etc/passwd";}
>
> Of course this could easily be bypassed using a string like this:
>
> O:9:"ZipWriter":1:{S:10:"\\000*\\000strTemp";s:11:"/etc/passwd";}
>
> However, in such case there's another filter which doesn't allow to
> inject *protected* or *private* objects' properties, and that is
> implemented within the Input::encodeSpecialChars() method [3], which
> converts backslashes into "\", meaning that the above string will be
> converted to:
>
> O:9:"ZipWriter":1:{S:10:"\00*\00strTemp";s:11:"/etc/passwd";}
>
> Therefore, unless somebody (like Pedro Ribeiro or Mr. Stefan Esser)
> provides a working Proof of Concept, I will continue to believe that
> CVE-2014-1860 should be rejected as non-vulnerability.
>
> References:
> [1] https://twitter.com/i0n1c/status/431367715941400576
> [2] https://twitter.com/i0n1c/status/431368722624704512
> [3] http://git.io/DFkxDQ
>
> Kind Regards,
> Egidio Romano
>
> >
> > On Wed, Feb 05, 2014 at 11:13:29PM +0100, Egidio Romano wrote:
> > Hello,
> >
> > I believe this CVE should be rejected, because the vulnerabilities
> > actually don't exist, at least the ones mentioned in this report.
> >
> > The reason is that user input is passed to the unserialize() function
> > through the Contao Input class, in which the Input::xssClean() method
> > removes all the NULL bytes from user input, meaning that an attacker can
> > be able to manipulate only the *public* properties of the injected
> > objects, because *protected* and *private* properties of a serialized
> > object are encoded with NULL bytes.
> >
> > I haven't found any exploitable magic method in Contao which uses only
> > *public* properties, and the ones mentioned in the original report are
> > exploitable only through *protected* properties.
> >
> > Therefore, unless someone provides a working Proof of Concept, I think
> > these shouldn't be considered actual security vulnerabilities.
> >
> > Best Ragards,
> > Egidio Romano
> >
> >>
> >> Hi,
> >>
> >> I have discovered a vulnerability that might lead to code execution in
> >> Contao CMS <= 3.2.4
> >> Contao CMS <= 3.2.4 does not properly validate user input in several
> >> locations which is then passed directly into PHP's unserialize.
> >>
> >> This has been fixed in Contao 3.2.5 as per commit:
> >>
>
> https://github.com/contao/core/commit/8c9cb044bdc887a8202bb65a64545c025664f957
> >> and
> >>
>
> https://github.com/contao/core/commit/1717336598fdcf1ed3f4ad488e140147cb31516d
> >>
> >> Announcements can be found at
> >>
> >> https://contao.org/en/news/contao-3_2_5.html
> >>
> >> https://contao.org/en/news/contao-2_11_14.html
> >>
> >> Thanks to the Contao developers for being so responsive.
> >> The full report can be found at my repo in
> >> https://github.com/pedrib/PoC/blob/master/contao-3.2.4.txt
> >>
> >> Regards,
> >>
> >> Pedro Ribeiro
> >> Agile Information Security
> >>
>
> _______________________________________________
> 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.”
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
