HN user
I argue the opposite: there’s no better fix for this
The better fix would be to not have the username pass through a parser looking for cli flags in the first place.
A correct implementation would be to just call glibc directly, this seems like a hasty fix to get the patch out the door. The history of vulns from bad shell escaping is as old as bash, whenever possible you probably shouldn't be mixing code and data, especially in a security critical application like this.
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.
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.
Its been a while since I've touched this stuff but my recollection is the ELF interpreter (ldso, not the kernel) is responsible for everything after mapping the initial ELF's segments.
iirc execve maps pt_load segments from the program header, populates the aux vector on the stack, and jump straight to the ELF interpreter's entry point. Any linked objects are loaded in userspace by the elf interpreter. The kernel has no knowledge of the PLT/GOT.