Show HN: PHP 8 disable_functions bypass PoC (github.com)
25 points by m0x41nos 3 hours ago
from a quick skim, it looks like the underlying bug is just not handling object resurrection[1] at all (FreeMe adds a reference to $array while its destructor is called).
I'm not really familiar with PHP but this seems like a surprising oversight for a popular language. Does PHP just not care about memory corruption? The fact that it is this easy is far more surprising than it being used to circumvent a questionable security feature.
there was a php-only million-rows challenge that was posted here recently. This uaf offers the opportunity for the funniest solution.
Tell us more about how you searched for and uncovered this? Do you normally use PHP? What disclosure process did you use?
That's a nice find. People rely a little heavily on this, and it only says in the manual "This directive allows certain functions to be disabled." but its not a security sandbox.
I think PHP has in the past explicitly stated its not a security feature.
There have been a few issues over the years with this.
Anyway - good OS security is required anytime you run software!
heres one from 6 years ago https://bugs.php.net/bug.php?id=76047
> I think PHP has in the past explicitly stated its not a security feature.
I'm struggling to think what it's for then?
> I'm struggling to think what it's for then?
Placating some users - mainly shared web hosting providers - who still think that disabling functions like system() and exec() is an effective security measure.
likely intended more as a lint than a security feature, it's not unusual to want to exclude commonly misused features from your code and any libraries you use.
Knowing the mess that is the php standard library, I imagine many applications would want to just straight up ban the really bad parts.
a lazy security feature that stops 90% of problems?