The linked CVE-2024-2961 article is a pretty fantastic read on its own:
https://www.ambionics.io/blog/iconv-cve-2024-2961-p1
People are so creative, I can't help but feel some hope for our future :)
That’s for that. I’ve never seen it before. What a neat path they took.
> I find it fascinating that people are putting so much efforts optimizing exploitation techniques, yet ~nobody bothers fixing them, even if it only takes a couple of lines of code and 20 minutes.
There's definite reward in having a 0-day. Either you can get a bounty, or sell it in the hacker-souk.
That "couple of lines of code and 20 minutes" is sort of in the eye of the beholder. If you are a highly-experienced language developer, the fixes are likely to be a lot more obvious, simpler, more comprehensive, and robust, than if you are a relatively junior IC.
I think it is probably because a lot of things are deemed as acceptable. For example, the stream filter chain one is only exploitable if the input to some php IO functions like file_get_contents are attacker-controlled, and those things are already treated as LFR vulnerabilities in application, not the language runtime. Also some of the them (e.g. stream filter chain) are fun and useful enough (turning LFI into RCE), so I bet there definitely some people would rather those thing is not fixed. Given that a properly-secured application wouldn't be affected.
Breaking something is easier than protecting everything from all fronts.
Hackers write the worst code, but all the mess needs only one successful hit to become a 0day.
Well, you can produce the exploit all on your own and showcase it.
But to get your fix in, you'd have to interact with the PHP ecosystem.
> I find it fascinating that people are putting so much efforts optimizing exploitation techniques, yet ~nobody bothers fixing them, even if it only takes a couple of lines of code and 20 minutes.
Like it or not, exploiting seems just more fun and rewarding. A lot of people will be interested to learn on your blog how you came to find and exploit a vulnerability. The 10 line of code patch gets little attention. Not even taking into consideration bug bounties...
> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain.
Big Oof. :( :( :(
I'm okay with the tradeoff. PHP prioritizing speed over uncommon security is the right call here.
missing /j
Are these issues very particular to PHP? Honest question, this is all above my current programming knowledge.
Yes. Most languages don't have anything like the filter notation for arbitrary reads to escalate through.
The real question is why does PHP have so many bugs that it's so trivial to exploit?
Seems like an attitude problem.
Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version.
The last part makes the fact their could be massive security holes like RCE in the core language very worrying.