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

Now we have found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize function. We had been also 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 relatively excessive rewards on Hackerone caught our attention. That’s why we have now taken the angle of a complicated attacker with the complete intent to get as deep as potential into the system, specializing in one principal goal: 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 web site. In all instances a parameter named "cookie" obtained unserialized from Post knowledge and afterwards reflected through Set-Cookie headers. Standard exploitation methods require so called Property-Oriented-Programming (POP) that contain abusing already existing lessons with particularly outlined "magic methods" in an effort to trigger undesirable and malicious code paths.

Unfortunately, it was troublesome for us to assemble any details about Pornhub’s used frameworks and PHP objects basically. Multiple classes from frequent frameworks have been tested - all with out success. The core unserializer alone is relatively complex because it includes greater than 1200 strains of code in PHP 5.6. Further, xnxx many internal PHP courses have their own unserialize methods. By supporting constructions like objects, arrays, integers, strings or even references it is not any surprise that PHP’s monitor document exhibits a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no recognized vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, especially as a result of unserialize already got quite a lot of attention in the past (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after so much attention and so many security fixes its vulnerability potential ought to have been drained out and it ought to be safe, shouldn’t it? To find an answer Dario applied a fuzzer crafted specifically for fuzzing serialized strings which were handed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected conduct. This behavior was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 version. However, operating the fuzzer against a newer version of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after putting an increasing number of effort into fuzzing we’ve stumbled upon unexpected habits once more. Several questions had to be answered: is the issue safety associated? In that case can we only exploit it locally or also remotely? To additional complicate this situation the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. A tremendous amount of time was mandatory to research potential points. In any case, we could extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon further investigation we found that the foundation cause could possibly be present in PHP’s garbage collection algorithm, a component of PHP that is totally unrelated to unserialize.

However, the interaction of each components occurred only after unserialize had finished its job. Consequently, it was not well suited to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and plenty of arduous work the same use-after-free vulnerability was discovered that gave the impression to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and their discovery made it mandatory to write separate articles. You possibly can read more details in Dario’s fuzzing unserialize write-up. In addition, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to take advantage of. Specifically, it involved a number of exploitation stages. 1. The stack and heap (which also embody any potential user-enter) in addition to any other writable segments are flagged non-executable (c.f. 2. Even if you are ready to manage the instruction pointer it is advisable to know what you want to execute i.e. it is advisable to have a valid tackle of an executable reminiscence phase.