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  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]
Date: Fri, 07 Feb 2014 00:15:36 +0100
From: Egidio Romano <>
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:


An attacker might be able to bypass the filter implemented within the
Input::xssClean() method because she can also use a string like this:


The Input::xssClean() method removes not only NULL bytes, but also the
string "\0", meaning that the above string will be converted to:


Of course this could easily be bypassed using a string like this:


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 "&#92;", meaning that the above string will be
converted to:


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.


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:
>> and
>> Announcements can be found at
>> Thanks to the Contao developers for being so responsive.
>> The full report can be found at my repo in
>> Regards,
>> Pedro Ribeiro
>> Agile Information Security

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists