Is PHP unserialize() exploitable without any magic methods?

Question

Say that there was a publicly accessible web page with the following PHP code:

<?php
class NotInteresting
{
    public function noExploits() {
        echo "Whatever.";
    }
}
$unsafe = unserialize($_GET['data']);
$unsafe->noExploits();
?>

The code would expect the data URL parameter to contain a serialized instance of NotInteresting, but of course the data parameter can be manipulated. When unserialize() is used on user supplied data it often leads to PHP Object Injection.

However, all the examples of PHP Object Injection I have seen so far (1,2,3) have been dangerous for one of two reasons:

1. There were some exploitable classes with dangerous methods (which were only meant to be called internally) which were leveraged to execute arbitrary code, often the case for a CMS.
2. The version of PHP was old or outdated and vulnerabilities in the PHP code were exploited.

Given that the PHP version is current - that is, no known vulnerabilities exist in the unserialize() function - and that there are no custom classes defined (just the default ones - Exception, stdClass etc.), is it possible to leverage the above code for a successful attack on a default PHP installation?

Extra info:

As far as I know there are only four exploitable magic methods when constructing an arbitrary class from an unserialize() call: __call(), __wakeup(), __destruct() and __toString():

• __wakeup() is called when an object is unserialized.
• __call() is called when invoking inaccessible methods (or non-existent ones).
• __destruct() is always called after no more references to the object exist.
• __toString() is called when an object is treated as a string.

So I wrote a PHP script to quickly generate a list of the classes which contains these magic methods: See here for a pastebin. Some of these look very 'interesting':

• The XML classes (could lead to XXE)
• The Phar classes

However I am unable so far to construct an attack just with these: I will need someone more experienced to weigh in.

Answer 1

The exploitability of PHP object deserialization depends solely on the available classes (standard classes as well as custom classes), their methods and behavior, and whether it is possible to get one of these exploitable methods triggered.

Note that the exploitable methods may not be that trivial. You may need to create complex object structures using multiple, nested objects to trigger a certain behavior. The number of exploitable methods or their behavior may also change during the time. So even if you may not be able to exploit it today, someone may sometimes be able.

Answer 2

OK, for this to be safe for a particular setup, you would have to be absolutely sure that there are no classes with exploitable behaviour. Given that this likely includes various modules (DB access, whatever), and their behaviour could include "magic methods" like getters or __wakeup(), this is a difficult thing to know fully.

You should also think of your fellow developers/maintainers (including future you). Firstly, they might not remember that they should be writing every class with this security constraint in mind (which seems easy to forget). Secondly the code looks insecure, and it doesn't make sense to constantly have people run over for you to carefully explain how you sanitised every other part of the system to make this particular thing work.

A better plan would be to serialise to/from something like JSON - which is not only safer, but makes your API compatible with other languages as well.