Now we have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize perform. We were also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks exit to cutz for co-authoring this text. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why we have now taken the perspective of an advanced attacker with the full intent to get as deep as possible into the system, focusing on one main 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 quickly detected the usage of unserialize on the website. In all circumstances a parameter named "cookie" bought unserialized from Post knowledge and afterwards reflected through Set-Cookie headers. Standard exploitation strategies require so called Property-Oriented-Programming (POP) that contain abusing already existing lessons with particularly outlined "magic methods" with the intention to trigger undesirable and malicious code paths.

Unfortunately, it was difficult for us to gather any details about Pornhub’s used frameworks and PHP objects on the whole. Multiple classes from common frameworks have been examined - all without success. The core unserializer alone is comparatively complicated because it involves more than 1200 lines of code in PHP 5.6. Further, many internal PHP classes have their very own unserialize methods. By supporting buildings like objects, arrays, integers, strings or even references it is not any surprise that PHP’s observe document shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, especially because unserialize already obtained loads of consideration previously (e.g. phpcodz). Hence, auditing it can be in comparison with squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many safety fixes its vulnerability potential should have been drained out and it ought to be safe, shouldn’t it? To seek out a solution Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This conduct was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 model. However, operating the fuzzer towards a newer model of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after placing more and more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions had to be answered: is the problem security associated? If that's the case can we solely exploit it domestically or additionally remotely? To additional complicate this case the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An amazing amount of time was mandatory to research potential issues. In spite of everything, we may extract a concise proof of concept of a working reminiscence corruption bug - a so referred to as use-after-free vulnerability! Upon additional investigation we discovered that the root trigger may very well be found in PHP’s rubbish assortment algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interplay of each parts occurred solely after unserialize had completed its job. Consequently, it was not well suited to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and a variety of laborious work an analogous use-after-free vulnerability was found that seemed to be promising for distant exploitation. The excessive sophistication of the found PHP bugs and their discovery made it mandatory to put in writing separate articles. You'll be able to read extra details 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 significantly difficult to use. Particularly, it involved multiple exploitation stages. 1. The stack and heap (which also embrace any potential user-input) in addition to another writable segments are flagged non-executable (c.f. 2. Even in case you are able to control the instruction pointer it's good to know what you want to execute i.e. it's essential have a legitimate address of an executable reminiscence section.