The fact they're using `eval()` to execute variable assignment... They could've just used the WTF-feature in PHP with double dollar signs. $$var = $itm; would've been equivalent to their eval statement, but with less code and no RCE.
The fact PHP is used for any critical web infrastructure is concerning. I used PHP professionally years ago and don't think it's that awful but certainly not something I'd consider for important systems.
https://gitlab.com/gitlab-org/gitlab/-/issues/327121 is the first one, and I'm having trouble locating up the second (possibly due to the search pollution from the first one) but there are a bunch of "Exiftool has been updated to version [0-9.]+ in order to mitigate security issues" style lines in their security releases feed so it's possible they were bitten by upstream Exiftool CVEs
Anyway, turns out that shelling out to an external binary fed with bytes from the Internet is good fun
a) system doesn't let you modify the state of the running process so it doesn't attract abuse like the example here. It's still a bad function but calling it effectively the same is absurd - the scope for "clever" usage of it is much much lower.
b) It's a legacy misfeature that I hope new compiled languages don't copy. There are much much better better interfaces for running processes that don't rely on an intermediate shell.
c) Shell escaping is much more stable than some hipster language like PHP where you'd need to update your escaping for new language changes all the time.
You can build an eval for a compiled language, absolutely. You can embed an interpreter, for example, or build one using closures. There's entire books on this, like LiSP in Small Pieces.
>crc32($str) and hash("crc32",$str) use different algorithms ..
>Password_verify() always returns true with some hash
>md5('240610708') == md5('QNKCDZO')
>crypt() on failure: return <13 characters of garbage
> strcmp() will return 0 on error, can be used to bypass authentication
> crc32 produces a negative signed int on 32bit machines but positive on 64bit mahines
>5.3.7 Fails unit test, released anyway
The takeaway from these titles is not the problems themselves but the pattern of failure and the issue of trusting the tool itself. Other than that if you've used php enough yourself you will absolutely find frustration in the standard library
If you're looking for something more exhaustive there's the certified hood classic "PHP: A fractal of bad design" article as well that goes through ~~300+~~ 269 problems the language had and/or still has.
Though most of it has been fixed since 2012, there's only so much you can do before the good programmers in your community (and job market) just leave the language. What's left is what's left.
It's very easy to make PHP safe, certainly now that we've passed the 7 mark and we have internal ASTs. Even when using eval, it's beyond trivial to not make gross mistakes.
Any language can be insecure. There’s nothing inherently bad about PHP, other than it’s the lowest-hanging fruit of CGI languages and has some less-than-ideal design decisions.
Modern PHP is about as solid as comparable languages. It's two biggest problems are:
Lingering bad reputation, from the bad old days
Minimal barrier to entry - which both makes it a go-to for people who should not be writing production code in any language, and encourages many higher-skill folks to look down on it
