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

We now have discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We have 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 consideration. That’s why we have now taken the angle of a sophisticated attacker with the total intent to get as deep as attainable into the system, specializing in one primary aim: 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 usage of unserialize on the website. In all instances a parameter named "cookie" got unserialized from Post information and afterwards mirrored by way of Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that involve abusing already current lessons with particularly defined "magic methods" with a purpose to set off undesirable and malicious code paths.

Unfortunately, it was troublesome for us to collect any information about Pornhub’s used frameworks and PHP objects normally. Multiple classes from frequent frameworks have been tested - all without success. The core unserializer alone is relatively complicated as it entails more than 1200 strains of code in PHP 5.6. Further, many inside PHP lessons have their own unserialize methods. By supporting constructions like objects, arrays, integers, strings and even references it isn't any shock that PHP’s monitor document shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no recognized vulnerabilities of such kind for newer PHP versions like PHP 5.6 or PHP 7, particularly because unserialize already acquired numerous attention up to now (e.g. phpcodz). Hence, auditing it can 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 needs to be secure, shouldn’t it? To seek out a solution Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which were passed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected behavior. This conduct was not reproducible when examined in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 model. However, working the fuzzer against a newer version of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions had to be answered: is the difficulty security associated? If so can we only exploit it domestically or additionally remotely? To additional complicate this situation the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. A tremendous period of time was crucial to research potential issues. In spite of everything, we could extract a concise proof of idea of a working memory corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we discovered that the root cause may very well be found in PHP’s garbage collection algorithm, a element of PHP that is totally unrelated to unserialize.

However, the interaction of both components occurred solely after unserialize had completed its job. Consequently, it was not nicely fitted to distant exploitation. After further evaluation, gaining a deeper understanding for porn the problem’s root causes and a whole lot of laborious work a similar use-after-free vulnerability was found that gave the impression to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it crucial to jot down separate articles. You possibly can 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. In particular, it concerned a number of exploitation levels. 1. The stack and heap (which also include any potential consumer-enter) in addition to another writable segments are flagged non-executable (c.f. 2. Even in case you are able to regulate the instruction pointer it's essential know what you need to execute i.e. it's worthwhile to have a valid handle of an executable memory section.