Fuzzing Unserialize

While auditing Pornhub we have stumbled across several pages where user input was evaluated by unserialize and the result was reflected back to the page. After enumerating class names from known frameworks and testing for old vulnerabilities in unserialize itself we realized that it could be much harder to exploit this issue than initially assumed.

The first thought was: OK, why not just find a new 0day in unserialize? This function has a very bad history and many bugs have been discovered over the past years. It can’t be /that/ hard, challenge accepted! I spent some time on reading code and checking fixes for old bugs, but I couldn’t find anything interesting. Most of the bugs from the last years were type confusions and use-after-free vulnerabilities. In most cases the bugs were so simple that twiddling some values in a legit serialized string could lead to pwnage. So, why not just write a fuzzer that crafts syntactically correct strings and passes them to unserialize?

At that point the motivation was not only to get a bounty from Pornhub but also to find a new PHP bug since there could be no way that unserialize is secure. In the end, this project was very helpful to earn some money: How we broke PHP, hacked Pornhub and earned $20,000

Unserializing data from user input in PHP is dangerous for the following reasons:

• As we all know, methods of unserialized classes can be invoked (ROP in PHP applications).
• It is possible to set references at almost arbitrary locations (often leads to use-after-free vulnerabilities).
• Types of variables can be defined in the serialized string (can lead to type confusion if internal classes make wrong assumptions about property types).

Unserialize Syntax

Before a fuzzer can be implemented the syntax of PHP’s serialize must be understood. There are 12 different symbols, each of them for one data type and use case. The following code shows the switch table that can be found in the source code of PHP

Accordingly, the following table shows all symbols and their meanings. It is helpful to understand how PHP’s variables work. PHP Internals Book – Basic zval structure

Each unserialized value has an index that can be referred by r and R. The first element (outer array or object) has key 1. References using the uppercase R and keys of any kind (array keys and property names) do not increase the index. Keys and property names can be of type i, s and S. PHP’s unserializer is very strict about the syntax. If a single character is not legit the function aborts the parser and nothing is returned. I had to make sure that the fuzzer did not generate invalid test samples for optimal efficiency.

Fuzzing Unserialize

A good fuzzer should be able to generate any syntactically correct payload. I decided to ignore parser bugs and focused on finding incorrect handling of variables and references. Unfortunately, PHP’s serialize() is not capable of generating arbitrary outputs. For example it is not possible to define the same array key twice in the serialized string. Also one cannot place arbitrary references at arbitrary locations. That’s why I implemented a custom serializer that let me construct whatever I wanted.

From here I only needed to obtain a list of internal classes and their properties from PHP’s source code. Now I was able to generate random samples and pass them to unserialize in order to (hopefully) trigger unexpected behavior.

Unexpected Behavior

You could argue that a memory corruption in PHP’s unserialize is in fact expected behavior because everyone knows the history of that function. However, the following events indicate that something went wrong during the unserialization process.

• Segmentation fault:
  The most obvious event is a segmentation fault which can easily be detected by checking the return code of the process.
• PHP prints zend_mm_heap_corrupted:
  PHP uses its own memory manager for allocations. In case the allocator detects a corruption on the heap a corresponding message is printed.
• &UNKNOWN;:
  The type of a value is stored inside the zval structure and can be a number between 0 and 10. For example the type 1 indicates an integer and type 6 is used for strings. When a variable that is printed with var_dump has an unknown type (not in the range 0-10) the string “&UNKNOWN;” is printed instead. This indicates a memory corruption since it is normally not possible to craft a data type which is unknown to PHP.
• Crafted integer zval:
  In PHP 5.6 zval structs have a size of 24 bytes. If this struct is entirely filled with \x01 the resulting value is an integer with the value 72340172838076673. I let the fuzzer place 24 byte long strings consisting of \x01 in the test cases. The presence of 72340172838076673 in the resulting deserialized data indicates that a use-after-free vulnerability has been found and successfully been exploited.
• Incorrect return value:
  The fuzzer always used an array as outer element leading to two possible return data types of unserialize: “array” when no errors occurred, or “NULL” in case the input was not satisfying for unserialize. Every data type different to array or null means that something unexpected has happened.
• Post-unserialize allocation:
  The occurence of variables that are defined between unserializing and var_dump most likely are a sign of a use-after-free vulnerability.

Test Cases

With the different behaviors that could occur in mind I designed the following test cases which were executed one after another with the same payload.

• Unserialize only:
  This test case does nothing but unserializing the provided serialized string.
• Unserialize var_dump:
  Here, the string is unserialized and every value in the result is accessed and printed via var_dump.
• Unserialize unserialize var_dump:
  A second unserialize has been added. Its purpose is to increase the amount of memory operations after the initial unserialize.
• Unserialize alloc var_dump:
  Here, the string is unserialized, some fix values are assigned to variables and finally the result of unserialize is printed.

All test cases are required because bugs can occur in different stages (e.g. unserialize, printing or shutdown of the PHP engine). By looking at the results of the different test cases it is also possible to determine where the bug has happened (if any was found).

Calibration and Tests

Before running the fuzzer I looked at PoCs of some old unserialize bugs to make sure I didn’t miss something. Turned out the fuzzer covered almost everything from the past. A first test against an old PHP version produced more segfaults than the kernel could handle. A second test against a recent PHP 7 version also spit out results very quickly. Unfortunately, it was a very unreliable bug that has not been investigated further – yet. The first tests against PHP 5.6.21 only resulted in some lame DoS bugs which are described at the bottom of this article.

Findings

The very first version of the fuzzer logged the serialized strings and var_dump outputs of all test cases and ended up filling my hard drive very quickly. It took some time and adjustments to the fuzzer until unexpected behavior was detected. Finally, after setting a decent fuzzing depth and generating large samples that were about 1-2M in size I found unexpected behavior. The interesting thing here was, that it didn’t happen reliably and depended on how many objects were allocated before or while unserializing the string. Together with evonide we figured out that the required number of objects was around 10000. After excluding irrelevant classes one by one I finally managed to get a working testcase that only was ~1000 bytes in size. After some more work I finally crafted the smallest possible test case.

Unfortunately, it is not guaranteed that ZipArchive exists on a target system since some distributions make it optional. So I continued fuzzing and included the amount of objects/arrays in the sample that were required to trigger the first bug. I found another bug almost instantaneously. Similar to the first test case I had to minimize a 500kb sample before going on.

This bug seemed to be promising. Unfortunately, it turned out that it was not suitable for remote exploitation in this form. A lot of follow-up research and adjustments had to be done. For more information you can read evonide’s write-up Breaking PHP’s Garbage Collection and Unserialize.

Bonus Round

Unserialize is still riddled with bugs. Here are a few strings that lead to – lets say – “problems”.

The first two bugs lead to stackoverflows and cause segmentation faults, the third payload consumes “some” CPU resources and the last one is a mid-unserialize type confusion.

Another bug can be triggered by using a custom class with a wakeup method. __wakeup gets invoked every time this object gets unserialized. In this example, the property kiri is a reference to the outer array which gets destroyed by setting $this->kiri.

1. The string is passed to unserialize.
2. As soon as the closing } for the object is found the wakeup method of the object is called.
3. The wakeup method destroys the outer array.
4. The unserializer tries to add the object to the array. Unfortunately, this array has already been destroyed.
5. The application crashes.

When a value is assigned to a property the internal function zend_std_write_property is eventually reached. Here, the zval of the old data is copied into a temporary zval. This temporary zval is passed to zval_dtor where the actual contents are destroyed. In our example the zval represents the outer array and contains a pointer to a HashTable. zval_dtor does not do any refcounter checks and frees the HashTable without mercy. Unfortunately, unserialize still operates on this HashTable and will crash as soon the wakeup function returns.

This bug is a classical use-after-free vulnerability but sadly no zval but rather only a HashTable is freed. Nevertheless, this is still an exploitable bug that exists since early php4 versions. However, this bug is difficult to exploit as I could achieve no means to leak arbitrary memory with it. As such, it is difficult to craft necessary fake HashTables that could be used for further exploitation purposes.

Closing Words

PHP’s unserializer suffers from insecurity since its existence and probably will until it dies. The use of unserialize on user input should be considered critical in every pentest report – even when the PHP version is up to date.

Always keep in mind that deserialization of user input is a bad idea in every language if not done right. In Python (pickles) and Java (readObject) things are even worse because the deserializers allow to execute code using only language defaults. You should rely on less complex serialization formats like json.

The outcome of this project is very interesting as we expected to find vulnerabilities in unserialize itself but ended up finding 2 bugs in a totally different core component. It also shows that a highly specialized fuzzer can be very powerful.

At the moment I have no intention to release this fuzzer. Nevertheless, if you have questions you can leave me a comment or contact me via Twitter @haxonaut for further discussion.