Re: [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4

[Egidio Romano <research () karmainsecurity com>]

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/