We now have discovered two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We have 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 relatively high rewards on Hackerone caught our consideration. That’s why we now have taken the attitude of an advanced attacker with the total intent to get as deep as potential into the system, specializing in one most important objective: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we quickly detected the usage of unserialize on the web site. In all instances a parameter named « cookie » bought unserialized from Post knowledge and afterwards reflected through Set-Cookie headers. Standard exploitation strategies require so referred to as Property-Oriented-Programming (POP) that contain abusing already existing classes with particularly defined « magic methods » in order to trigger unwanted and malicious code paths.
Unfortunately, it was troublesome for us to assemble any details about Pornhub’s used frameworks and PHP objects typically. Multiple courses from widespread frameworks have been examined – all without success. The core unserializer alone is comparatively advanced because it involves more than 1200 lines of code in PHP 5.6. Further, many internal PHP courses have their own unserialize methods. By supporting structures like objects, arrays, integers, strings and even references it is no surprise that PHP’s monitor record reveals 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, particularly as a result of unserialize already acquired a variety of consideration in the past (e.g. phpcodz). Hence, auditing it can be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many safety fixes its vulnerability potential should have been drained out and it ought to be secure, shouldn’t it? To search out an answer Dario applied a fuzzer crafted specifically for fuzzing serialized strings which were passed to unserialize.
Running the fuzzer with PHP 7 instantly result in unexpected behavior. This conduct was not reproducible when tested in opposition to Pornhub’s server though. Thus, we assumed a PHP 5 model. However, operating the fuzzer towards a newer model of PHP 5 simply generated more than 1 TB of logs without any success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions needed to be answered: is the problem security associated? If that’s the case can we only exploit it domestically or also remotely? To additional complicate this case the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. An incredible amount of time was vital to research potential points. In any case, xhamster we could extract a concise proof of idea of a working memory corruption bug – a so referred to as use-after-free vulnerability! Upon additional investigation we found that the root cause may very well be present in PHP’s rubbish collection algorithm, a component of PHP that is totally unrelated to unserialize.
However, the interplay of both components occurred only after unserialize had completed its job. Consequently, it was not nicely suited to remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and a number of onerous work the same use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The high sophistication of the found PHP bugs and their discovery made it obligatory to write separate articles. You’ll be able to read more particulars in Dario’s fuzzing unserialize write-up. As well as, we 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. Particularly, it concerned a number of exploitation phases. 1. The stack and heap (which also embrace any potential user-input) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you are ready to regulate the instruction pointer it is advisable know what you want to execute i.e. it’s good to have a sound address of an executable memory segment.