Mailing List Archive

[CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4
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/
Re: [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4 [ In reply to ]
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/
Re: [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4 [ In reply to ]
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 "&#92;", meaning that the above string will be
converted to:

O:9:"ZipWriter":1:{S:10:"&#92;00*&#92;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/
Re: [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4 [ In reply to ]
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 <research@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 "&#92;", meaning that the above string will be
> converted to:
>
> O:9:"ZipWriter":1:{S:10:"&#92;00*&#92;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.”
Re: [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS <= 3.2.4 [ In reply to ]
Hello Mario,

Rest assured, it wasn't my intention to get into a flame war! :)

The thing is that I am one of that kind of people that is called "like
San Tommaso" in Italy. In other words, I'm not able to believe in
something until I can see it with my eyes. Well, now Stefan Esser has
provided a PoC for CVE-2014-1860 [1], proving that I was wrong. Sadly,
I'm just a human being, and as everybody knows, "errare humanum est".

I just hope that now he is happy to have proven to be smarter than me.
On the other hand, just because his PHP exploitation skills are better
than mine, it doesn't necessarily mean he's smarter than me, especially
considering the fact that he is part of the PHP development team.
However, I never thought to be such a smart guy, and very likely he is
actually smarter than me.

So, it seems I need to apologize to Pedro Ribeiro: please accept my
apologies for doubting about the validity of your report. Nevertheless,
if we want to be picky, actually your report is only 33.3% true, since
you reported two deserialize()s called with user input accessed via the
Input::post method (which seems to be not vulnerable), and only one via
the Input::postRaw method, that is what I missed, and this made me
think it wasn't exploitable.

Finally, I really would like to congratulate with Mr. Esser, since he
claims [2] to be aware of this security hole for (who knows how many)
years. However it seems he preferred to keep this as 0-day, instead of
reporting to the Contao team and help to improve the security of an
open source project.

References:
[1] http://pastebin.com/DFh1FVdb
[2] http://oi59.tinypic.com/2rpwthj.jpg

Have a great weekend!
/Egidio


On 07/02/2014 11:46, Mario Vilas wrote:
> 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 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 "&#92;", meaning that the above string will be
> converted to:
>
> O:9:"ZipWriter":1:{S:10:"&#92;00*&#92;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/