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

We now have found two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize operate. 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 article. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our consideration. That’s why now we have taken the perspective of a sophisticated attacker with the full intent to get as deep as attainable into the system, focusing on one essential 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 quickly detected the usage of unserialize on the website. In all cases a parameter named "cookie" received unserialized from Post data and afterwards reflected through Set-Cookie headers. Standard exploitation methods require so referred to as Property-Oriented-Programming (POP) that contain abusing already current classes with particularly outlined "magic methods" in order to set off unwanted and malicious code paths.

Unfortunately, it was difficult for us to collect any details about Pornhub’s used frameworks and PHP objects basically. Multiple courses from widespread frameworks have been tested - all with out success. The core unserializer alone is relatively complex as it includes more than 1200 traces of code in PHP 5.6. Further, many internal PHP classes have their very own unserialize methods. By supporting structures like objects, arrays, integers, strings or even references it is no shock that PHP’s track record exhibits a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, particularly because unserialize already received a lot of attention prior to now (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many security fixes its vulnerability potential should have been drained out and it needs to be safe, shouldn’t it? To find an answer Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which have been passed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected habits. This behavior was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 model. However, running the fuzzer in opposition to a newer model of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected behavior again. Several questions had to be answered: is the difficulty safety related? In that case can we solely exploit it domestically or also remotely? To additional complicate this case the fuzzer did generate non-printable knowledge blobs with sizes of greater than 200 KB. An incredible amount of time was vital to research potential points. In spite of everything, we might extract a concise proof of idea of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we found that the root cause may very well be found in PHP’s garbage assortment algorithm, a element of PHP that is completely unrelated to unserialize.

However, the interaction of each elements occurred only after unserialize had finished its job. Consequently, it was not effectively suited for remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and a lot of onerous work an identical use-after-free vulnerability was discovered that gave the impression to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it mandatory to write down separate articles. You may read extra particulars in Dario’s fuzzing unserialize write-up. In addition, 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 use. In particular, it involved multiple exploitation phases. 1. The stack and heap (which additionally include any potential consumer-input) as well as another writable segments are flagged non-executable (c.f. 2. Even if you are ready to manage the instruction pointer it's worthwhile to know what you want to execute i.e. that you must have a sound deal with of an executable memory segment.