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

We now have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize function. We had been additionally awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for co-authoring this article. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our consideration. That’s why we have taken the attitude of a sophisticated attacker with the complete intent to get as deep as possible into the system, specializing in one essential objective: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we rapidly detected the usage of unserialize on the web site. In all circumstances a parameter named "cookie" got unserialized from Post data and afterwards mirrored via Set-Cookie headers. Standard exploitation strategies require so called Property-Oriented-Programming (POP) that involve abusing already current courses with specifically outlined "magic methods" to be able to trigger unwanted and malicious code paths.

Unfortunately, it was difficult for us to collect any details about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from frequent frameworks have been examined - all with out success. The core unserializer alone is comparatively complex because it entails more than 1200 traces of code in PHP 5.6. Further, many internal PHP courses have their own unserialize methods. By supporting constructions like objects, arrays, xnxx integers, strings or even references it is not any surprise that PHP’s track document exhibits 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, particularly because unserialize already got a number of consideration previously (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after so much attention and so many security 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 passed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected conduct. This conduct was not reproducible when tested against Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer towards a newer version of PHP 5 simply generated more than 1 TB of logs without any success. Eventually, after putting increasingly more effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions had to be answered: is the issue security related? If so can we only exploit it regionally or also remotely? To further complicate this situation the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An incredible amount of time was mandatory to investigate potential issues. In any case, we could 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 cause could be found in PHP’s garbage assortment algorithm, a part of PHP that is completely unrelated to unserialize.

However, the interaction of both components occurred only after unserialize had completed its job. Consequently, it was not effectively suited to distant exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and a number of arduous work the same use-after-free vulnerability was found that gave the impression to be promising for remote exploitation. The high sophistication of the discovered PHP bugs and their discovery made it necessary to write separate articles. You'll be able to learn more details in Dario’s fuzzing unserialize write-up. In addition, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly difficult to use. Specifically, it involved a number of exploitation phases. 1. The stack and heap (which also embody any potential user-input) in addition to every other writable segments are flagged non-executable (c.f. 2. Even if you are ready to control the instruction pointer you could know what you wish to execute i.e. you could have a legitimate tackle of an executable memory segment.