Re: Remote code execution in Pimcore CMS

[Pedro Ribeiro <pedrib () gmail com>]

On 19 April 2014 18:39,  <cve-assign () mitre org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > I have discovered a PHP object injection in Pimcore CMS.
> > https://github.com/pedrib/PoC/blob/master/pimcore-2.1.0.txt
>
> MITRE currently doesn't look for "CVE request" in the Subject line.
> For some posts, the right number of CVE IDs can be determined more
> quickly than for others. So, in this case, we'll just ask for
> additional information.
>
> pimcore-2.1.0.txt says:
>
>   Payload [1] abuses several Zend classes to achieve remote code
>   execution
>
> and then says:
>
>   payload [3] does not work on Pimcore versions between 2.0.1 and
>   2.1.0
>
> Is it also true that:
>
>   payload [1] does not work on Pimcore versions between 2.0.1 and
>   2.1.0
>
> ?
>
> The payload [1] code is obviously a close derivative of the payload
> [3] code, but they are not identical. We're not sure whether there was
> an important reason for mentioning [3] specifically.

I agree the advisory is too ambiguous, let me state the facts for clarity:
- All versions suffer from the same flaw, passing user data to the
unserialize() function, therefore in theory it is possible to achieve
PHP code execution in all versions from 1.4.9 up to and including
2.1.0.
- At this point, I can only prove code execution in versions 1.4.9 and
1.4.10 with payload [1] under the condition of running under PHP 5.3.3
or lower.
- Version 2.0.0 and above should only run in PHP 5.4+. However, this
is only enforced in version 2.0.1 and above. Therefore it might be
possible to run 2.0.0 on PHP 5.3.3, but I have not attempted this, and
it might be unlikely to find it deployed it anywhere in this
configuration.
- For versions 1.4.9 and 2.1.0, running under any PHP version, payload
[3] provides a proof of concept for arbitrary file deletion.

However, a fellow researcher has sent me a private mail indicating
that it might be possible to achieve code execution on any PHP
version. I am working on a PoC for that but it's not available at this
point.

> For this statement:
>
>   Version 2.0.0 might be vulnerable if anyone is running it
>   on PHP versions <= 5.3.3... which according to the developers is
>   not possible, but the requirement was only enforced in 2.0.1.
>
> First, we think that "Version 2.0.0 might be vulnerable" means
> "Version 2.0.0 might be vulnerable to exactly the same remote code
> execution problem that existed in 1.4.9 to 1.4.10 (inclusive)."

Correct.

> Also, we think you mean that the correct set of affected versions has
> two possibilities. The set is possibly disputed by the developers, but
> it is either:
>
>    1.4.9 to 1.4.10 (inclusive): Remote code execution (when server is running PHP <= 5.3.3).
>
> or
>
>    1.4.9 to 1.4.10 (inclusive) and 2.0.0: Remote code execution (when server is running PHP <= 5.3.3).
The 2nd one is correct, 1.4.9, 1.4.10 and 2.0.0.

> Also, based on
> http://sourceforge.net/projects/pimcorebuilds/files/archive/ it seems
> that version 1.4.10 was the last 1.x version. In other words, it's not
> a situation in which the problem was fixed within a later 1.x version,
> but then reappeared in 2.0.0 because of a regression.
>
> Is all of this correct?

Correct.

> It seems very likely that the right number of CVE IDs is two, but the
> questions above can clarify that. (Separate CVE IDs are needed when
> the usable attack methodology differs across versions.)


So in conclusion:
- theoretically code execution on all version
- in practice, code execution in 1.4.9 and 1.4.10 and arbitrary file
deletion in 1.4.9 to 2.1.0

It's all the same flaw and the same attack methodology, just different
proof of concept. At the moment I am not able to achieve code
execution on 2.0.0 and above with PHP > 5.3.3, but this might be just
a question of time.
So I think it is really only one CVE number.

Regards,
Pedro

> - --
> CVE assignment team, MITRE CVE Numbering Authority
> M/S M300
> 202 Burlington Road, Bedford, MA 01730 USA
> [ PGP key available through http://cve.mitre.org/cve/request_id.html ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (SunOS)
>
> iQEcBAEBAgAGBQJTUrQLAAoJEKllVAevmvmskG0H/Ri4cooLcXXm54PAtXLu6aX7
> WdlXx2KQuypsyada/3rXXOSNRqowJoBJiB3KGeyt6Y3SUiLG/2hsmoOqMotEXyMB
> TRTkbKn0PZOGZMCzaAQN2iwJnAPfcU5I6YEP2s7D6DjiT0KXSGh5kRsuolVeWqMD
> FPxxxp3blLDj+7rVX59PLJREYN8y2go7qIKVdAzv+aZ4nrKeIt+c0msbBfyqNvxe
> +vEW6ByZw8sFxFIFMUXhS2v6GN5kssFMWNA46594BzQcwaXIZ4knqTAENgbarXp7
> eAojDQ7MVTDnWy5oqmO3Ma3Ys5uURpWMNaQtyOhOU+JK1wTmuyj0JjessLEFwXA=
> =kCC0
> -----END PGP SIGNATURE-----





On 19 April 2014 18:39,  <cve-assign () mitre org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > I have discovered a PHP object injection in Pimcore CMS.
> > https://github.com/pedrib/PoC/blob/master/pimcore-2.1.0.txt
>
> MITRE currently doesn't look for "CVE request" in the Subject line.
> For some posts, the right number of CVE IDs can be determined more
> quickly than for others. So, in this case, we'll just ask for
> additional information.
>
> pimcore-2.1.0.txt says:
>
>   Payload [1] abuses several Zend classes to achieve remote code
>   execution
>
> and then says:
>
>   payload [3] does not work on Pimcore versions between 2.0.1 and
>   2.1.0
>
> Is it also true that:
>
>   payload [1] does not work on Pimcore versions between 2.0.1 and
>   2.1.0
>
> ?
>
> The payload [1] code is obviously a close derivative of the payload
> [3] code, but they are not identical. We're not sure whether there was
> an important reason for mentioning [3] specifically.
>
> For this statement:
>
>   Version 2.0.0 might be vulnerable if anyone is running it
>   on PHP versions <= 5.3.3... which according to the developers is
>   not possible, but the requirement was only enforced in 2.0.1.
>
> First, we think that "Version 2.0.0 might be vulnerable" means
> "Version 2.0.0 might be vulnerable to exactly the same remote code
> execution problem that existed in 1.4.9 to 1.4.10 (inclusive)."
>
> Also, we think you mean that the correct set of affected versions has
> two possibilities. The set is possibly disputed by the developers, but
> it is either:
>
>    1.4.9 to 1.4.10 (inclusive): Remote code execution (when server is running PHP <= 5.3.3).
>
> or
>
>    1.4.9 to 1.4.10 (inclusive) and 2.0.0: Remote code execution (when server is running PHP <= 5.3.3).
>
> Also, based on
> http://sourceforge.net/projects/pimcorebuilds/files/archive/ it seems
> that version 1.4.10 was the last 1.x version. In other words, it's not
> a situation in which the problem was fixed within a later 1.x version,
> but then reappeared in 2.0.0 because of a regression.
>
> Is all of this correct?
>
> It seems very likely that the right number of CVE IDs is two, but the
> questions above can clarify that. (Separate CVE IDs are needed when
> the usable attack methodology differs across versions.)
>
> - --
> CVE assignment team, MITRE CVE Numbering Authority
> M/S M300
> 202 Burlington Road, Bedford, MA 01730 USA
> [ PGP key available through http://cve.mitre.org/cve/request_id.html ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (SunOS)
>
> iQEcBAEBAgAGBQJTUrQLAAoJEKllVAevmvmskG0H/Ri4cooLcXXm54PAtXLu6aX7
> WdlXx2KQuypsyada/3rXXOSNRqowJoBJiB3KGeyt6Y3SUiLG/2hsmoOqMotEXyMB
> TRTkbKn0PZOGZMCzaAQN2iwJnAPfcU5I6YEP2s7D6DjiT0KXSGh5kRsuolVeWqMD
> FPxxxp3blLDj+7rVX59PLJREYN8y2go7qIKVdAzv+aZ4nrKeIt+c0msbBfyqNvxe
> +vEW6ByZw8sFxFIFMUXhS2v6GN5kssFMWNA46594BzQcwaXIZ4knqTAENgbarXp7
> eAojDQ7MVTDnWy5oqmO3Ma3Ys5uURpWMNaQtyOhOU+JK1wTmuyj0JjessLEFwXA=
> =kCC0
> -----END PGP SIGNATURE-----