• 글쓰기
• 목록

We now have discovered two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize perform. We were 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 relatively high rewards on Hackerone caught our consideration. That’s why now we have taken the attitude of an advanced attacker with the full intent to get as deep as potential into the system, focusing on one essential 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 shortly detected the usage of unserialize on the web site. In all circumstances a parameter named "cookie" got unserialized from Post information and afterwards reflected by way of Set-Cookie headers. Standard exploitation strategies require so referred to as Property-Oriented-Programming (POP) that involve abusing already current lessons with specifically defined "magic methods" in an effort to trigger unwanted and malicious code paths.

Unfortunately, it was tough for us to collect any details about Pornhub’s used frameworks and PHP objects on the whole. Multiple lessons from common frameworks have been tested - all without success. The core unserializer alone is relatively advanced as it includes more than 1200 traces of code in PHP 5.6. Further, many inside PHP courses have their own unserialize strategies. By supporting buildings like objects, arrays, integers, strings and even references it is not any surprise that PHP’s monitor record reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such sort for porn newer PHP variations like PHP 5.6 or PHP 7, especially as a result of unserialize already acquired lots of attention in the past (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after so much attention and so many safety fixes its vulnerability potential ought to have been drained out and it ought to be secure, shouldn’t it? To seek out an answer Dario implemented a fuzzer crafted specifically for fuzzing serialized strings which were passed to unserialize.

Running the fuzzer with PHP 7 instantly lead to unexpected conduct. This conduct was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 version. However, running the fuzzer in opposition to a newer model of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after placing more and more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions needed to be answered: is the difficulty safety related? If so can we solely exploit it locally or also remotely? To further complicate this example the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. A tremendous period of time was essential to research potential points. After all, we may extract a concise proof of concept of a working memory corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we discovered that the basis cause could possibly be present in PHP’s rubbish assortment algorithm, a element of PHP that is completely unrelated to unserialize.

However, the interplay of both components occurred solely after unserialize had finished its job. Consequently, it was not effectively fitted to remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and plenty of arduous work an identical use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The excessive sophistication of the found PHP bugs and their discovery made it crucial to write down separate articles. You can 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 considerably tough to exploit. Particularly, it involved multiple exploitation stages. 1. The stack and heap (which also embody any potential person-enter) as well as another writable segments are flagged non-executable (c.f. 2. Even if you're in a position to manage the instruction pointer it's essential know what you need to execute i.e. it is advisable have a legitimate handle of an executable reminiscence segment.