• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Now we have discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. 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 excessive rewards on Hackerone caught our consideration. That’s why we've taken the attitude of a sophisticated attacker with the total intent to get as deep as possible into the system, specializing in one foremost goal: gaining distant 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 utilization of unserialize on the web site. In all instances a parameter named "cookie" obtained unserialized from Post information and afterwards reflected via Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that involve abusing already existing classes with specifically outlined "magic methods" with a view to trigger unwanted and malicious code paths.

Unfortunately, it was tough for us to gather any details about Pornhub’s used frameworks and PHP objects normally. Multiple lessons from widespread frameworks have been examined - all without success. The core unserializer alone is relatively complicated as it entails more than 1200 strains of code in PHP 5.6. Further, many inside PHP lessons have their very own unserialize methods. By supporting structures like objects, arrays, integers, strings and even references it is not any shock that PHP’s track document shows a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such sort for newer PHP variations like PHP 5.6 or PHP 7, especially because unserialize already received a number of consideration previously (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many safety fixes its vulnerability potential ought to have been drained out and it should be safe, shouldn’t it? To search out a solution Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which had been handed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This habits was not reproducible when examined in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer towards a newer version of PHP 5 just generated more than 1 TB of logs without any success. Eventually, after putting an increasing number of effort into fuzzing we’ve stumbled upon unexpected behavior again. Several questions needed to be answered: is the difficulty security associated? If so can we only exploit it domestically 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 obligatory to investigate potential issues. In spite of everything, we may extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we found that the root trigger may very well be present in PHP’s rubbish collection algorithm, a component of PHP that is completely unrelated to unserialize.

However, the interplay of both parts occurred only after unserialize had finished its job. Consequently, it was not properly fitted to distant exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and plenty of laborious work a similar use-after-free vulnerability was found that appeared to be promising for remote exploitation. The high sophistication of the discovered PHP bugs and their discovery made it mandatory to write down separate articles. You can learn more details in Dario’s fuzzing unserialize write-up. As well as, we've got written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly tough to exploit. Particularly, it concerned a number of exploitation levels. 1. The stack and heap (which also embody any potential consumer-enter) as well as another writable segments are flagged non-executable (c.f. 2. Even if you are ready to control the instruction pointer you'll want to know what you need to execute i.e. you must have a legitimate tackle of an executable reminiscence section.