Upcoming Hardening in PHP
dustri.org
Upcoming Hardening in PHP
1–10 of 130 posts
Re: Upcoming Hardening in PHP
#2> 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.
Re: Upcoming Hardening in PHP
#3The real question is why does PHP have so many bugs that it's so trivial to exploit?
Re: Upcoming Hardening in PHP
#4Are these issues very particular to PHP? Honest question, this is all above my current programming knowledge.
Re: Upcoming Hardening in PHP
#5The 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 :)
Re: Upcoming Hardening in PHP
#6> 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. :( :( :(
Re: Upcoming Hardening in PHP
#7The 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.
Re: Upcoming Hardening in PHP
#8[dead]
Re: Upcoming Hardening in PHP
#9> 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 lan…
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.
Re: Upcoming Hardening in PHP
#10> 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...