We now have found two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. We have been also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks exit to cutz for co-authoring this article. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our consideration. That’s why we have now taken the angle of a complicated attacker with the full intent to get as deep as doable into the system, specializing in one principal purpose: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we shortly detected the usage of unserialize on the web site. In all cases a parameter named "cookie" received unserialized from Post information and afterwards mirrored via Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that contain abusing already present classes with particularly defined "magic methods" with the intention to set off undesirable and malicious code paths.

Unfortunately, it was troublesome for us to collect any details about Pornhub’s used frameworks and PHP objects typically. Multiple lessons from widespread frameworks have been tested - all with out success. The core unserializer alone is relatively complicated as it includes more than 1200 traces of code in PHP 5.6. Further, many inner PHP courses have their very own unserialize strategies. By supporting constructions like objects, arrays, integers, strings or even references it isn't any shock that PHP’s observe report reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, porn particularly because unserialize already acquired loads of consideration prior to now (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot consideration and so many safety fixes its vulnerability potential should have been drained out and it should be safe, shouldn’t it? To search out an answer Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which had been passed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected behavior. This behavior was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 model. However, working the fuzzer towards a newer model of PHP 5 just generated greater than 1 TB of logs with none success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions needed to be answered: is the problem security related? If so can we only exploit it domestically or also remotely? To additional complicate this example the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An incredible period of time was necessary to investigate potential points. In spite of everything, we might extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the root trigger could possibly be found in PHP’s rubbish collection algorithm, a part of PHP that is completely unrelated to unserialize.

However, the interaction of both parts occurred solely after unserialize had completed its job. Consequently, it was not effectively fitted to remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and loads of exhausting work a similar use-after-free vulnerability was discovered that gave the impression to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it necessary to write separate articles. You may read more particulars in Dario’s fuzzing unserialize write-up. In addition, we've written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably troublesome to use. In particular, it concerned multiple exploitation levels. 1. The stack and heap (which additionally include any potential consumer-enter) in addition to some other writable segments are flagged non-executable (c.f. 2. Even if you're in a position to regulate the instruction pointer you'll want to know what you wish to execute i.e. it is advisable have a sound deal with of an executable reminiscence section.