클잼 로고

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

We now have discovered two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We were additionally 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 excessive rewards on Hackerone caught our attention. That’s why now we have taken the perspective of a sophisticated attacker with the full intent to get as deep as possible into the system, focusing on one major objective: gaining distant 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 utilization of unserialize on the website. In all cases a parameter named "cookie" obtained unserialized from Post information and afterwards reflected through Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that involve abusing already current classes with specifically defined "magic methods" as a way to set off unwanted and malicious code paths.

Unfortunately, it was troublesome for us to assemble any details about Pornhub’s used frameworks and PHP objects on the whole. Multiple courses from frequent frameworks have been tested - all with out success. The core unserializer alone is relatively complicated because it includes greater than 1200 strains of code in PHP 5.6. Further, many inside PHP classes have their own unserialize strategies. By supporting structures like objects, arrays, integers, strings or even references it isn't any surprise that PHP’s monitor document shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, particularly because unserialize already acquired loads of consideration up to now (e.g. phpcodz). Hence, auditing it may be in comparison with 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 should be secure, shouldn’t it? To find a solution Dario implemented 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 examined towards Pornhub’s server though. Thus, we assumed a PHP 5 version. However, operating the fuzzer towards a newer version of PHP 5 just generated greater than 1 TB of logs with none success. Eventually, after placing more and more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the difficulty security associated? In that case can we solely exploit it domestically or additionally remotely? To additional complicate this example the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. A tremendous amount of time was crucial to research potential issues. After all, we may extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon additional investigation we found that the root trigger could be found in PHP’s rubbish collection algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interplay of each components occurred only after unserialize had completed its job. Consequently, it was not properly fitted to remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and lots of hard work an analogous use-after-free vulnerability was found that seemed to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and porn their discovery made it necessary to put in writing separate articles. You may learn more details in Dario’s fuzzing unserialize write-up. In addition, we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly difficult to use. Particularly, it involved a number of exploitation stages. 1. The stack and heap (which additionally embrace any potential user-enter) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you're ready to manage the instruction pointer it's essential to know what you wish to execute i.e. you should have a valid address of an executable memory segment.