(Reliable)? php2shell exploitability
Yesterday everyone was running around like crazy (me included :) because of the php2shell vulnerability.
However, after looking closely at some published PoC's - and there is an unbelievable amount of AI generated - erm, slop - it looks like building a universal, reliable, one click exploit is quite difficult (unless I'm missing something, so please do let me know).
The PoC's that have been released so far have several pre-requirements and are almost cheating.
First, in order to have a clean initial state, the one PoC that makes sense sends a POST HTTP request with a number of small fields (3000 bytes each, 1001 of them), for bulk allocation pressure, prepare PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS and then append a big field of 12 MB.
This guarantees that emalloc fails, since the PoC require that memory limit is set to 8 MB.
This is the first issue; in real world setups memory_limit is usually 128 MB, making this a bit more demanding.
An even bigger issue is that real world setups will have multiple workers - the demo uses a single-worker prefork configuration which guarantees that the next phase lands with this worker. In real world this is not guaranteed and an attacker would have to consume all workers and release one (and catch that one). Not sure how difficult this is.
The next phase now (phase 1) leaks the Zend MM chunk base, which is a piece of heap, from which the 2 MB-aligned Zend MM chunk base is extracted.
This is needed for calculation of HashTable.
Then phase 2 leaks the libphp.so base address.
This is needed to defeat ASLR, but it's not the only component required. Specifically, once Apache starts, it will pick a randomized base address for libphp.so. However, offsets of other functions/pointers in libphp.so will be static.
So phase 2 will leak one specific code pointer: zval_ptr_dtor, which has a static offset from libphp.so base address. In other words, by knowing this offset, we can calculate the base address of libphp.so and defeat ASLR.
The problem here is that this depends on many factors - how libphp.so was compiled, what's the exact PHP version, distro etc).
This is where shown PoC's are "cheating" they read offsets of zval_ptr_dtor (and zif_system) from libphp.so on the server.
In real world an attacker would have to know this. I presume someone could compile list of all possible options for commonly used distro combinations.
Now in phase 3 (and I haven't thoroughly checked this one), the exploit will change pDestructor to zif_system, and this will result in execution of code. There is one limit here; the size of command can be up to 14 bytes.
As we can see, there's a lot of prerequisites here that make a reliable exploit difficult.
I'm pretty sure that smart researchers that found the vulnerability know (much) more, but clearly it's not as simple as perhaps initially thought.
The general recommendation to put session.upload_progress.enabled = 0 should help, especially since there apparently is a way to bypass even the (currently) available fix so do put this until the next update.
PHP Vulnerability Wrap-Up
This morning, we returned to Infocon Green. As usual, we are raising the Infocon to alert you to emerging situations requiring immediate attention. PHP fit that description. By now, you either know about it, or you probably never will, so it is time to go back to "business as usual".
Many vendors have released patches for the vulnerability in sync with PHP.net, showing that the coordinated vulnerability disclosure worked and achieved its goal of providing tested and working patches in a timely manner. Some vendor(s) not playing by the rules and leaking details early is unfortunate but should not overshadow the overall success of providing the patches.
At this point, no reliable exploit has been made available publicly as far as I know. Several firms stated that they possess working exploit code, and I consider it a matter of time before such code becomes publicly available, at which point we will likely see more widespread exploitation. Cloudflare and Amazon have stated that they are seeing a large number of exploit attempts, but it is not clear if these are actual working exploits.
Applying the patch remains your best and only reliable defense. Treat the time you have now as a gift and use it wisely to find and patch applications in your organization.
If you are not able to upgrade, do your best to isolate vulnerable applications. There are various workarounds, but none are considered 100% effective. They may buy you more time. The same is true for web application firewall rules.
Today, php.net advised keeping the "session.upload_progress.enabled=0" workaround in place until the next update. In other words: We are not done patching PHP yet!
As so often, embedded devices and appliances are a major concern, and many of them have not been updated or are unlikely to ever receive a patch. These types of devices should be isolated regardless. The PHP issue is likely just one of many weaknesses that could be exploited. Router admin interfaces, network storage devices, cameras, cat feeding stations, and refrigerators should not be exposed to the internet, and should be isolated on internal networks. At this point, this is table stakes regardless if they are running PHP.
This vulnerability is also a good "dress rehearsal" of what is likely going to come. Vulnerability disclosure worked in this case. Patches were available. There will likely be many more vulnerabilities of similar severity that will be released and exploited with less responsibility. Be ready, run your tabletop exercises, update your inventories...
Many partial exploits have been released. Be careful; some of them may be "parasitic," trying to exploit whoever runs them. It may be hard to even identify the working exploit once it comes out.
The vulnerability and the risk are real, even if we did not see immediate mass exploitation. That part is still to come; it is just delayed. Just like we lower our infocon, make sure to rest and disconnect a bit, and do not stay "on alert" for too long. You will need the strength for the next issue. And do not overlook other issues that may have been missed this week: Node.js, Fortinet ... and more
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments