클잼 로고

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

We've found two use-after-free vulnerabilities in PHP’s rubbish collection algorithm. Those vulnerabilities had 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 exit to cutz for co-authoring this article. Pornhub’s bug bounty program and its comparatively high rewards on Hackerone caught our attention. That’s why now we have taken the angle of a complicated attacker with the total intent to get as deep as doable into the system, focusing on one important goal: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we shortly detected the usage of unserialize on the web site. In all instances a parameter named "cookie" bought unserialized from Post knowledge and afterwards mirrored through Set-Cookie headers. Standard exploitation strategies require so called Property-Oriented-Programming (POP) that involve abusing already present classes with specifically outlined "magic methods" to be able to trigger unwanted and malicious code paths.

Unfortunately, it was difficult for us to assemble any details about Pornhub’s used frameworks and PHP objects typically. Multiple classes from common frameworks have been tested - all without success. The core unserializer alone is comparatively complicated because it entails more than 1200 strains of code in PHP 5.6. Further, many inside PHP lessons have their own unserialize strategies. By supporting buildings like objects, arrays, integers, strings or even references it isn't any surprise that PHP’s monitor record exhibits a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, particularly because unserialize already got plenty of attention prior to now (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 should have been drained out and it ought to be secure, shouldn’t it? To search out an answer Dario carried out a fuzzer crafted particularly for fuzzing serialized strings which were handed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected habits. This conduct was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 version. However, working the fuzzer against a newer model of PHP 5 just generated more than 1 TB of logs without any success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions had to be answered: is the problem security related? If that's the case can we solely exploit it domestically or additionally remotely? To further complicate this case the fuzzer did generate non-printable knowledge blobs with sizes of greater than 200 KB. An incredible period of time was obligatory to research potential issues. In spite of everything, we might extract a concise proof of concept of a working memory corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we discovered that the foundation cause could be present in PHP’s garbage collection algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interaction of each parts occurred solely 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 a number of exhausting work the same use-after-free vulnerability was found that seemed to be promising for remote exploitation. The high sophistication of the discovered PHP bugs and their discovery made it obligatory to write separate articles. You'll be able to read more particulars in Dario’s fuzzing unserialize write-up. As well as, we have now written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly tough to take advantage of. Particularly, it involved a number of exploitation stages. 1. The stack and heap (which additionally 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 it's good to know what you need to execute i.e. that you must have a legitimate tackle of an executable memory section.