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

We now have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize operate. We have been additionally awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks exit to cutz for porn co-authoring this article. 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 an advanced attacker with the full intent to get as deep as possible into the system, specializing in one essential objective: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we shortly detected the utilization of unserialize on the web site. In all circumstances a parameter named "cookie" bought unserialized from Post data and afterwards mirrored through Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that involve abusing already existing lessons with specifically outlined "magic methods" to be able to trigger undesirable and malicious code paths.

Unfortunately, it was troublesome for us to gather any information about Pornhub’s used frameworks and PHP objects basically. Multiple courses from frequent frameworks have been tested - all without success. The core unserializer alone is comparatively complicated because it includes greater than 1200 traces of code in PHP 5.6. Further, many inner PHP lessons have their very own unserialize strategies. By supporting buildings like objects, arrays, integers, strings and even references it is not any shock that PHP’s monitor report reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such kind for newer PHP versions like PHP 5.6 or PHP 7, especially as a result of unserialize already bought numerous attention 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 should have been drained out and it should be secure, shouldn’t it? To search out an answer Dario carried out a fuzzer crafted particularly for fuzzing serialized strings which were passed to unserialize.

Running the fuzzer with PHP 7 instantly result in unexpected conduct. This behavior was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer against a newer version 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 behavior once more. Several questions had to be answered: is the issue safety related? If so can we solely exploit it regionally or additionally remotely? To further complicate this situation the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An incredible period of time was vital to investigate potential issues. In any case, we may extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we discovered that the root cause may very well be found in PHP’s rubbish collection algorithm, a component of PHP that is totally unrelated to unserialize.

However, the interplay of each parts occurred only after unserialize had completed its job. Consequently, it was not nicely suited to distant exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and numerous exhausting work a similar use-after-free vulnerability was found that seemed to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it crucial to write down separate articles. You possibly can learn extra 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 considerably troublesome to take advantage of. Particularly, it concerned multiple exploitation stages. 1. The stack and heap (which also embody any potential person-enter) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you're in a position to control the instruction pointer you have to know what you want to execute i.e. it's essential have a valid handle of an executable memory section.