Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function.
As of now, PHP emits an error if arguments are missing but not if there are too many.
A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword:
A few month ago I discussed this on the development mailing list and people seemed to agree and even suggested that this would be a good idea by default without the keyword thing I suggested. But I never got the time to properly write an RFC. There is already an old one from years ago that was voted against but In was told it was from before anything strict and typing related was considered important in PHP. If anyone's up to it, please write this RFC :) !
> 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.
> 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...
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.
Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways.
Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today.
Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading that java swing application or that react app that's 15 months old. Go, haskell, vue, python 2 to 3 are more difficult because of syntax changes where in php you have some breaking changes like globals being removed or ereg removal or mysql_ being removed. The changes were small like using mysqli instead of mysql or using preg instead of ereg.
My complaint was adding lots of breaking changes to minor version upgrades. The fact, historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standard.
There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and something you haven’t done. And the claim that php 4 code will work on php 8 is 100% nonsense. The syntax for how classes were defined in 4 is not supported in 8.
I’ve upgraded the code to the major versions of other languages without hassle. But they generally have fewer breaking changes in their major versions when I upgraded to Vue3 that super painless.
And can you point to a minor upgrade where Go changed the syntax to the point the old one no longer works? With Go normally it's the tooling that changes. I can't remember the syntax changing on me.
I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.
As of now, PHP emits an error if arguments are missing but not if there are too many.
A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword:
A few month ago I discussed this on the development mailing list and people seemed to agree and even suggested that this would be a good idea by default without the keyword thing I suggested. But I never got the time to properly write an RFC. There is already an old one from years ago that was voted against but In was told it was from before anything strict and typing related was considered important in PHP. If anyone's up to it, please write this RFC :) !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 :)
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.
Hackers write the worst code, but all the mess needs only one successful hit to become a 0day.
But to get your fix in, you'd have to interact with the PHP ecosystem.
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...
Big Oof. :( :( :(
The last part makes the fact their could be massive security holes like RCE in the core language very worrying.
Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today.
Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading that java swing application or that react app that's 15 months old. Go, haskell, vue, python 2 to 3 are more difficult because of syntax changes where in php you have some breaking changes like globals being removed or ereg removal or mysql_ being removed. The changes were small like using mysqli instead of mysql or using preg instead of ereg.
There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and something you haven’t done. And the claim that php 4 code will work on php 8 is 100% nonsense. The syntax for how classes were defined in 4 is not supported in 8.
I’ve upgraded the code to the major versions of other languages without hassle. But they generally have fewer breaking changes in their major versions when I upgraded to Vue3 that super painless.
And can you point to a minor upgrade where Go changed the syntax to the point the old one no longer works? With Go normally it's the tooling that changes. I can't remember the syntax changing on me.
Just use rector
https://github.com/rectorphp/rector