Joomla itself isn't handling the encoding of session data, rather relying on PHP's built in session API to resolve it. So the data object goes through session_encode() and session_decode() to function.

As for object serialization in the session, yes it is happening. The JUser object for the active user is serialized into the session and a Joomla\Registry\Registry object is serialized as part of the session with a container that's mainly used for the user state endpoints. Also, since JsonSerializable isn't a part of PHP 5.3, you couldn't rely on being able to json_*code() an object's data.

Thank you for the detailed answer.

Sorry, I'm not an expert but I'm trying to better understand this attack in order to prevent similar issues.

So, maybe someone should try to report this issue to PHP developers? What do you think?

There are known issues for unserialize and they did a secure unserialize RFC (with implementation ready) to allow developers to fix Object Injection, it's proposed for PHP 7 (sigh):

https://wiki.php.net/rfc/secure_unserialize
php/php-src#315

but what about session_decode?

They say:

Please note the unserialization method is not the same as unserialize(). The serialization method is internal to PHP and can be set using session.serialize_handler.
http://us.php.net/session_decode

So, session_decode isn't using unserialize implementation, so they may implement also a secure session_decode with a new session.serialize_handler and allow us to set to a custom filter in some way... Or the json session.serialize_handler.

Returning to Joomla related considerations:

If JUser and Joomla\Registry\Registry are stored in the session i fear some "user input" data in those objects... user states? user profile strings? submitted form data? saved return URLs? Are we sure we are 'sanitizing' or at least have in control, all the data we put in the session?

Should we consider to add a 'filter' for common expoit patterns in JSession->set() and to not allowing anymore to store whole php objects in this method?

If you still need to save JUser and JRegistry to the session can't you write a custom json serializer for JRegistry and JUser fields?

Does what I'm saying makes sense? Sorry if not, I'm just trying to start some 'prevention'

For a mass distributed application, you can't rely on being able to change PHP configuration values. So having Joomla be dependent on being able to manipulate the PHP configuration isn't going to be acceptable for a lot of users who end up using those types of cheap hosting platforms.

Joomla\Registry\Registry is a data storage object. It's purpose in life is for the storage of data. It doesn't care about whether the data it's been given is sanitized or the biggest exploit known to PHP. Internally it stores all data within stdClass objects.

The session API in and of itself should not care about filtered or sanitized data. Single Responsibility Principle says that whatever is injecting data into the session should be sanitizing it beforehand, it is not the responsibility of the session API to try and sanitize data (it won't have awareness of what types of rules need to be applied to a piece of data). There is nothing in PHP that allows someone to inject data into a session without a middle layer taking that user input and passing it into the session store. In the case of Joomla, it is reading several bits of data out of the $_SERVER superglobal and storing that as part of the session. Everything else stored into the session by default is either created by the JSession object itself or goes through the application or MVC layers and should be filtered via JFilterInput (which is done automatically with request data if using JInput or JRequest).

Even setting filters in JSession::set() wouldn't bypass any use after free vulnerabilities unless when the session is started it passed every stored variable from the serialized data object into the data store via the set method instead of direct assignment.

What Joomla cannot control is how developers design their extensions. What Joomla can control is how its core APIs store and retrieve data from various locations. For the most part, Joomla does a good job with ensuring data is filtered when using the appropriate APIs. This last security release was one instance where something had been overlooked for quite some time (by both developers and the hacker community) and it finally came back to bite the project on its backside.

Thanks again

Ok so you found that my fear was true?

https://docs.joomla.org/J3.x:Backward_Compatibility_in_Joomla_3.4.7

any user 'string' input, also if validated as a string as it should be in some forms, saved to the session was an attack vector! That is an epic security issue of PHP, not a Joomla issue!

It seems now a good solution to double encode all the session data array with base64 and serialize, good job!

Hi @brianteeman , was the issue of CVE-2015-8562 ever addressed? :)
And if so could you kindly point out to me where/what were the vulnerable files?

Thank you in advance !