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

We now have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize perform. We were 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 excessive rewards on Hackerone caught our consideration. That’s why we've got taken the angle of a complicated attacker with the complete intent to get as deep as potential into the system, focusing on one important objective: gaining remote 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 instances a parameter named "cookie" received unserialized from Post data and afterwards reflected via Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that involve abusing already current lessons with particularly defined "magic methods" in order to set off unwanted and malicious code paths.

Unfortunately, it was tough for us to collect any details about Pornhub’s used frameworks and PHP objects basically. Multiple courses from common frameworks have been examined - all without success. The core unserializer alone is relatively complicated as it includes greater than 1200 lines of code in PHP 5.6. Further, many inside PHP lessons have their own unserialize strategies. By supporting constructions like objects, arrays, integers, strings and even references it isn't any shock that PHP’s track record exhibits a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such kind for porn newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already obtained plenty 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 security fixes its vulnerability potential ought to have been drained out and it needs to be secure, 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 behavior. This conduct was not reproducible when examined towards Pornhub’s server although. Thus, we assumed a PHP 5 version. However, working the fuzzer towards a newer model of PHP 5 simply 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 once more. Several questions had to be answered: is the issue security associated? If so can we solely exploit it regionally or additionally remotely? To further complicate this example the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An incredible amount of time was obligatory to research potential issues. In any case, we might extract a concise proof of idea of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon further investigation we discovered that the foundation cause might be present in PHP’s rubbish collection algorithm, a part of PHP that is completely unrelated to unserialize.

However, the interplay of each components occurred solely after unserialize had completed its job. Consequently, it was not properly suited for remote exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and lots of laborious work the same use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The excessive sophistication of the found PHP bugs and their discovery made it crucial to write down separate articles. You possibly can learn 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 difficult to exploit. In particular, it concerned multiple exploitation phases. 1. The stack and heap (which also embrace any potential user-enter) as well as any other writable segments are flagged non-executable (c.f. 2. Even if you're able to manage the instruction pointer that you must know what you want to execute i.e. you want to have a valid tackle of an executable memory section.