• 글쓰기
• 목록

We've got discovered two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize function. We have been 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 comparatively high rewards on Hackerone caught our attention. That’s why we now have taken the angle of a sophisticated attacker with the complete intent to get as deep as potential into the system, specializing in one major goal: gaining distant 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 website. In all cases a parameter named "cookie" obtained unserialized from Post information and afterwards mirrored via Set-Cookie headers. Standard exploitation methods 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 troublesome for us to assemble any information about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from widespread frameworks have been tested - all without success. The core unserializer alone is relatively complex because it includes more than 1200 strains of code in PHP 5.6. Further, many internal PHP lessons have their very own unserialize methods. By supporting structures like objects, arrays, integers, strings and even references it isn't any shock that PHP’s monitor file 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, particularly because unserialize already received loads of consideration prior to now (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 security fixes its vulnerability potential ought to have been drained out and it ought to be safe, shouldn’t it? To seek out an answer Dario applied a fuzzer crafted specifically for fuzzing serialized strings which had been passed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This behavior was not reproducible when examined towards 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 once more. Several questions needed to be answered: is the difficulty security related? If that's the case can we solely exploit it locally or also remotely? To additional complicate this case the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An amazing period of time was crucial to investigate potential points. In spite of everything, xhamster we could extract a concise proof of concept of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we found that the foundation cause could be present in PHP’s rubbish collection algorithm, a element of PHP that is completely unrelated to unserialize.

However, the interplay of both components occurred only after unserialize had completed its job. Consequently, it was not well suited for distant exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and a lot of exhausting work a similar use-after-free vulnerability was found that gave the impression to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it crucial to put in writing separate articles. You may 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 troublesome to take advantage of. Particularly, it involved multiple exploitation phases. 1. The stack and heap (which additionally embody any potential person-input) as well as every other writable segments are flagged non-executable (c.f. 2. Even in case you are ready to regulate the instruction pointer you should know what you want to execute i.e. you have to have a legitimate handle of an executable reminiscence section.