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

We've got discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize function. We were additionally awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks exit to cutz for co-authoring this text. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why we have now taken the attitude of an advanced attacker with the complete intent to get as deep as possible into the system, specializing in one foremost purpose: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we rapidly detected the utilization of unserialize on the website. In all cases a parameter named "cookie" received unserialized from Post data and afterwards mirrored by way of Set-Cookie headers. Standard exploitation methods require so referred to as Property-Oriented-Programming (POP) that involve abusing already current classes with particularly outlined "magic methods" so as to set off undesirable and malicious code paths.

Unfortunately, porn it was troublesome for us to collect any details 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 as it includes greater than 1200 traces of code in PHP 5.6. Further, many inner PHP courses have their very own unserialize strategies. By supporting constructions like objects, arrays, integers, strings or even references it is not any surprise that PHP’s monitor file reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already bought a number of attention previously (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after a lot consideration and so many security fixes its vulnerability potential should have been drained out and it needs to be safe, shouldn’t it? To seek out a solution Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which have been passed to unserialize.

Running the fuzzer with PHP 7 instantly result in unexpected habits. This habits was not reproducible when examined towards Pornhub’s server though. Thus, we assumed a PHP 5 version. However, working the fuzzer towards a newer model of PHP 5 just generated more than 1 TB of logs without any success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions needed to be answered: is the problem safety associated? If that's the case can we solely exploit it locally or additionally remotely? To further complicate this case the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. An amazing amount of time was needed to investigate potential issues. After all, we might extract a concise proof of concept of a working reminiscence corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we found that the basis cause could possibly be present in PHP’s rubbish collection algorithm, a element of PHP that is completely unrelated to unserialize.

However, the interaction of both components occurred solely after unserialize had completed its job. Consequently, it was not effectively suited to remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and a whole lot of exhausting work a similar use-after-free vulnerability was found that seemed to be promising for distant exploitation. The excessive sophistication of the found PHP bugs and their discovery made it essential to put in writing separate articles. You can read more 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 difficult to use. In particular, it involved a number of exploitation phases. 1. The stack and heap (which additionally embrace any potential user-input) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you're ready to control the instruction pointer you could know what you want to execute i.e. it's good to have a valid address of an executable reminiscence section.