We’ve got found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize function. We have been also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for co-authoring this text. Pornhub’s bug bounty program and its comparatively high rewards on Hackerone caught our consideration. That’s why we have taken the perspective of a sophisticated attacker with the total intent to get as deep as potential into the system, focusing on one major purpose: gaining remote 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 circumstances a parameter named « cookie » received unserialized from Post knowledge and afterwards reflected via Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that involve abusing already present classes with particularly defined « magic methods » as a way to trigger undesirable and malicious code paths.
Unfortunately, it was troublesome for us to collect any information about Pornhub’s used frameworks and PHP objects typically. Multiple classes from common frameworks have been tested – all without success. The core unserializer alone is relatively complex as it entails more than 1200 strains of code in PHP 5.6. Further, many internal PHP courses have their very own unserialize methods. By supporting structures like objects, arrays, integers, strings and even references it is no surprise that PHP’s monitor report shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no known vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, especially as a result of unserialize already acquired a number of attention prior to now (e.g. phpcodz). Hence, xhamster auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many security fixes its vulnerability potential should have been drained out and it must be safe, shouldn’t it? To search out a solution Dario applied a fuzzer crafted specifically for fuzzing serialized strings which have been passed to unserialize.
Running the fuzzer with PHP 7 immediately result in unexpected behavior. This behavior was not reproducible when examined in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer in opposition to a newer model of PHP 5 simply generated more than 1 TB of logs with none success. Eventually, after placing increasingly effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions had to be answered: is the difficulty security related? In that case can we solely exploit it locally or also remotely? To further complicate this situation the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An amazing amount of time was needed to investigate potential issues. In any case, we may extract a concise proof of concept of a working reminiscence corruption bug – a so referred to as use-after-free vulnerability! Upon further investigation we discovered that the basis trigger could be found in PHP’s garbage collection algorithm, a part of PHP that is totally unrelated to unserialize.
However, the interaction of each elements occurred solely after unserialize had finished its job. Consequently, it was not well fitted to remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and numerous arduous work an analogous use-after-free vulnerability was found that seemed to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it essential to write separate articles. You possibly can read more particulars in Dario’s fuzzing unserialize write-up. In addition, now we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly difficult to take advantage of. Particularly, it involved a number of exploitation stages. 1. The stack and heap (which additionally include any potential person-input) as well as any other writable segments are flagged non-executable (c.f. 2. Even in case you are in a position to regulate the instruction pointer you need to know what you need to execute i.e. you need to have a legitimate deal with of an executable memory segment.