Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Hardening in PHP

dustri.org

Post reply on HN
Print view View original

71–80 of 130 posts

Re: Upcoming Hardening in PHP

#71

Post by cess11 »

phplovesong wrote: post #41
justinclift wrote: post #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. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

PHP has decent FFI, nothing is stopping you from using the same libraries as you would with Python. Here's someone's quick hack as an example: https://github.com/dstogov/php-tensorflow

For an interpreted language PHP itself is ridiculously fast and the VM is rather small so you can use something else coughElixircough for parallellisation. I use it all the time for data wrangling stuff and database imports because it's robust, fast and PsySh is a pretty neat environment.

The array data structure is quite nice too. It's built on simple parts that are foundational to the VM itself, and very flexible, similar to lists in Lisp-like languages but without the seek lag when data grows due to the indexing.

Re: Upcoming Hardening in PHP

#72

Post by tored »

p4bl0 wrote: post #70
tored wrote: post #67

Earlier quoted context omitted.

If I understood your proposal correctly, to get the new behavior add an explicit stop to the function, my proposal add attribute to keep old behavior. Thus if understanding this right that would require to update every function signature to new behavior rather than marking a few functions to get the old behavior and automatically get the new better behavior of every other function for free.

Oh okay, you would do it in reverse. I strongly agree with that. But that means the new feature is opt-out rather than opt-in, and it may break some old code. Maybe it should be done in two-steps (opt-in + deprecation, then opt-out).

Typically you emit E_DEPRECATED for a full major version, then in the next major version you throw an error, e.g if it would land in PHP 9.0 then E_DEPRECATED for non-compliant functions and in PHP 10.0 start throwing errors.

Re: Upcoming Hardening in PHP

#73

Post by [deleted] »

ChrisMarshallNY wrote: post #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 lan…

[deleted]

Re: Upcoming Hardening in PHP

#74

Post by withinboredom »

p4bl0 wrote: post #54
notresidenter wrote: post #43

Earlier quoted context omitted.

You should look at `func_get_args()` usage in the wild. This is sometimes used for (mostly outdated) good-enough reasons and doing this might break it?

I know of func_get_args, but proper variadic functions have been a thing since PHP 5.6 (released more than 10 years ago) using the ... operator. Also, my initial proposal doesn't break existing code :).

Variadic functions serve a purpose but also change how the engine parses arguments. func_get_args is faster and more efficient.

Re: Upcoming Hardening in PHP

#75

Post by tored »

MH15 wrote: post #28
p4bl0 wrote: post #24

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: function foo (int $a, string $b, void) : bool { ...…

I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

I work on multiple projects from PHP 5.2 to PHP 8.3 and everything in between.

Statistics based on packagist(composer)

https://stitcher.io/blog/php-version-stats-january-2024

Statistics based on web servers in the wild

https://w3techs.com/technologies/details/pl-php

https://w3techs.com/technologies/history_details/pl-php

Re: Upcoming Hardening in PHP

#76

Post by withinboredom »

p4bl0 wrote: post #35
withinboredom wrote: post #30

Earlier quoted context omitted.

I don’t really understand the issue. Already if you have a mismatch, the only way you’d ever know is through static analysis. It will run and maybe crash during run time. I always joke that changing a function signature is the single most risky thing you can do in php (especially if you have any dynamic dispatch). Making it even more risky isn’t the right answer, IMHO. Oh, and doing this would literally break class a…

> the only way you’d ever know is through static analysis Not for builtin PHP functions which already throw errors on arity mismatch. > this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature I don't understand. Could you point to where in the Symfony code it relies on being able to wrongly call a function with more arguments than it expects and will use? For…

> Not for builtin PHP functions which already throw errors on arity mismatch.

It still only happens during run time. Having a never-called function with an incorrect number of arguments is not an error.

Re: Upcoming Hardening in PHP

#77

Post by p4bl0 »

withinboredom wrote: post #76
p4bl0 wrote: post #35

Earlier quoted context omitted.

> the only way you’d ever know is through static analysis Not for builtin PHP functions which already throw errors on arity mismatch. > this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature I don't understand. Could you point to where in the Symfony code it relies on being able to wrongly call a function with more arguments than it expects and will use? For…

> Not for builtin PHP functions which already throw errors on arity mismatch. It still only happens during run time. Having a never-called function with an incorrect number of arguments is not an error.

Of course! And I strongly agree that static analysis is a good thing. But PHP still is a dynamically typed language and most of its development and usage is done with this dynamic approach in mind. It's not a XOR either, we can have better dynamic error reporting AND develop better static analysis tools at the same time.

Also, due to the nature and usage of PHP, some things cannot be statically analyzed because they're inherently dynamic. A simple example would be MVC frameworks where the routing is done like so: /controller/action/param1/param2/param3 where "controller" references a class and "action" references a method, which will take the "paramN" as arguments through the splicing of an array: `$ctrl->$actn(...$args);`. In such situations it would be nice to have errors/exceptions raised automatically if the URL is wrong (not enough OR too much arguments) without having to manually assess everything inside each method. Since PHP 7 and 8 over we're moving away from long lines of isset() and !empty() (and verifications such as is_numeric() etc. thanks to argument typing).

Re: Upcoming Hardening in PHP

#78

Post by noduerme »

p4bl0 wrote: post #66
noduerme wrote: post #63

Earlier quoted context omitted.

I think this would be nice ergonomically, from a coding perspective, but I'm curious as to how it would be a security threat to pass too many arguments. What's the potential exploit here?

Exploit I don't know, but as any stricter type verification, it would catch some bugs for sure. Note that builtin functions already throw an ArgumentCountError when passing fewer OR more parameters than the signature allows. My proposal consists in (optionally in a first place) make this behavior consistent for user-defined functions.

The trouble for me, where the rubber meets the road, is external API calls that spread their arguments into a PHP function that takes a bunch of args. So I would love a way to detect if they're sending too many, which I don't think currently exists (?) but not at the expense of breaking the API if they actually do send too many.

Re: Upcoming Hardening in PHP

#79

Post by blueflow »

est wrote: post #14
ChrisMarshallNY wrote: post #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 lan…

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.

Instead of making a website about it, you can take any step of your exploit chain and change the code that exploit cannot possibly work, and submit that as patch. You would still get a CVE number assigned that you can add to your resume.

For example, look at the glibc/iconv CVE some other user posted[1]. In the section "Out-of-bound write when converting to ISO-2022-CN-EXT" they have mapped out the boundary checks. By diagnosing the problem this detailed, they already did 90% of the work. The other 10% are the patch and writing to the mailing list.

[1] https://www.ambionics.io/blog/iconv-cve-2024-2961-p1

Re: Upcoming Hardening in PHP

#80

Post by withinboredom »

naiv wrote: post #36
reddalo wrote: post #31

Earlier quoted context omitted.

The Laravel ecosystem folks seem to be always up to date in recent PHP developments. At least, that's my impression.

Symfony also does a great job adding polyfills way ahead of a PHP release , eg https://github.com/symfony/polyfill-php84

Yes, and this is incredibly annoying. Many packages add them as a dependency, and then you get subtle bugs because of it. Or worse, they add a dependency for the polyfill that is related to an extension and suffer performance issues when the extensions are not installed; yet no warning is output.
Post reply on HN