• 글쓰기
• 목록

We've discovered two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize perform. We had been 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 consideration. That’s why now we have taken the attitude of a sophisticated attacker with the total intent to get as deep as attainable into the system, specializing in one major purpose: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we rapidly detected the utilization of unserialize on the web site. In all instances a parameter named "cookie" received unserialized from Post data and afterwards reflected via Set-Cookie headers. Standard exploitation methods require so referred to as Property-Oriented-Programming (POP) that involve abusing already existing classes with specifically defined "magic methods" in order to set off unwanted and malicious code paths.

Unfortunately, it was difficult for us to gather any information about Pornhub’s used frameworks and PHP objects basically. Multiple courses from widespread frameworks have been examined - all with out success. The core unserializer alone is relatively complicated because it entails more than 1200 lines of code in PHP 5.6. Further, many internal PHP courses have their very own unserialize strategies. By supporting structures like objects, arrays, integers, strings or even references it isn't any shock that PHP’s monitor record shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no recognized vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, particularly because unserialize already got a lot of consideration up to now (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many security fixes its vulnerability potential should have been drained out and it should be secure, shouldn’t it? To search out a solution 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 habits. This conduct was not reproducible when tested against Pornhub’s server although. 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 placing increasingly effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions had to be answered: is the problem security related? If so can we solely exploit it domestically or also remotely? To further complicate this example the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. A tremendous amount of time was needed to analyze potential points. In any case, we may extract a concise proof of idea of a working memory corruption bug - a so called use-after-free vulnerability! Upon further investigation we discovered that the basis 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 both components occurred solely after unserialize had completed its job. Consequently, it was not nicely fitted to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and a number of onerous work an identical use-after-free vulnerability was discovered that seemed to be promising for distant exploitation. The excessive sophistication of the found PHP bugs and their discovery made it crucial to write down separate articles. You can learn more details 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 exploit. Particularly, it concerned multiple exploitation stages. 1. The stack and heap (which also include any potential person-input) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you are in a position to control the instruction pointer you might want to know what you wish to execute i.e. you want to have a legitimate tackle of an executable memory section.