We have found two use-after-free vulnerabilities in PHP’s rubbish collection algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. We had been additionally 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've taken the angle of a sophisticated attacker with the full intent to get as deep as potential into the system, specializing in one essential objective: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we rapidly detected the utilization of unserialize on the web site. In all cases a parameter named "cookie" received unserialized from Post data and afterwards mirrored via Set-Cookie headers. Standard exploitation methods require so referred to as Property-Oriented-Programming (POP) that involve abusing already existing lessons with particularly defined "magic methods" with the intention to set off undesirable and malicious code paths.

Unfortunately, it was tough for us to gather any details about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from frequent frameworks have been tested - all with out success. The core unserializer alone is comparatively complex because it entails greater than 1200 lines of code in PHP 5.6. Further, many inner PHP classes have their own unserialize methods. By supporting buildings like objects, arrays, integers, strings or even references it is not any surprise that PHP’s monitor document reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no known vulnerabilities of such kind for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already obtained a whole lot of consideration previously (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, xhamster after so much attention and so many safety fixes its vulnerability potential should have been drained out and it should be secure, shouldn’t it? To seek out a solution Dario applied a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.

Running the fuzzer with PHP 7 instantly lead to unexpected habits. This conduct was not reproducible when examined in opposition to Pornhub’s server though. Thus, we assumed a PHP 5 version. However, working the fuzzer against a newer model of PHP 5 just generated more than 1 TB of logs with none success. Eventually, after putting an increasing number of effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions had to be answered: is the difficulty safety related? In that case can we only exploit it domestically or also remotely? To additional complicate this situation the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. An incredible period of time was obligatory to research potential points. In any case, we could extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon further investigation we discovered that the root cause may very well be present in PHP’s garbage collection algorithm, a part of PHP that is completely unrelated to unserialize.

However, the interaction of each parts occurred only after unserialize had completed its job. Consequently, it was not well fitted to distant exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and numerous hard work an identical use-after-free vulnerability was found that appeared to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it needed to write separate articles. You can learn more particulars in Dario’s fuzzing unserialize write-up. In addition, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably tough to take advantage of. Specifically, it involved multiple exploitation phases. 1. The stack and heap (which additionally embrace any potential person-input) as well as any other writable segments are flagged non-executable (c.f. 2. Even in case you are able to manage the instruction pointer you want to know what you need to execute i.e. it's essential have a legitimate handle of an executable reminiscence phase.