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.
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!
PHP loads all available functions into a giant hashset (see zend_disable_function in PHP's source). 'disable_functions' removes the functions from the hashset, making them unavailable to be called. Due to its interpreted nature, this indirection works much like a sandbox would.
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.
Placating some users - mainly shared web hosting providers - who still think that disabling functions like system() and exec() is an effective security measure.
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.
[1] https://en.wikipedia.org/wiki/Object_resurrection
> Does PHP just not care about memory corruption
They didn't in the past, it "freed" memory by killing the (per request) worker. Such legacy takes a long time to overcome.
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
PHP loads all available functions into a giant hashset (see zend_disable_function in PHP's source). 'disable_functions' removes the functions from the hashset, making them unavailable to be called. Due to its interpreted nature, this indirection works much like a sandbox would.
> I think PHP has in the past explicitly stated its not a security feature.
I'm struggling to think what it's for then?
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.
> 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.
a lazy security feature that stops 90% of problems?