[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52F41798.4080802@karmainsecurity.com>
Date: Fri, 07 Feb 2014 00:15:36 +0100
From: Egidio Romano <research@...mainsecurity.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [CVE-2014-1860] PHP object insertion /
possible RCE in Contao CMS <= 3.2.4
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/
Powered by blists - more mailing lists