>The first bug that our retrospective found was CVE-2015-5243. This is a monster of a bug, in which the prolific phpWhois library simply executes data obtained from the WHOIS server via the PHP ‘eval’ function, allowing instant RCE from any malicious WHOIS server.
As has been demonstrated many, many (many, many (many many many many many...)) times: there is no such thing as computer security. If you have data on a computer that is connected to the Internet, you should consider that data semi-public. If you put data on someone else's computer, you should consider that data fully public.
Our computer security analogies are modeled around securing a home from burglars, but the actual threat model is the ocean surging 30 feet onto our beachfront community. The ocean will find the holes, no matter how small. We are not prepared for this.
It's a matter of opinion, but no, I disagree. People are building new software all the time. It all has bugs. It will always have bugs. The only way to build secure software is to increase its cost by a factor of 100 or more (think medical and aviation software). No one is going to accept that.
Computer security is impossible at the prices we can afford. That doesn't mean we can't use computers, but it does mean we need to assess the threats appropriately. I don't think most people do.
It's not a matter of opinion at all. You can disagree but you can disagree with the earth being a sphere also.
> People are building new software all the time. It all has bugs. It will always have bugs.
No. Most bugs these days are due to legacy decisions where security was not an issue. We are making advances in both chip and software security. Things are already vastly more secure than they were 20 years ago.
20 years from now, security will be a lot closer to being a solved problem.
> The only way to build secure software is to increase its cost by a factor of 100 or more (think medical and aviation software). No one is going to accept that.
What are you basing that cost on?
> Computer security is impossible at the prices we can afford.
No, it really isn't. There's a reason some organizations have never been hacked and likely never will be. Largely because they have competent people implementing security that very much exists.
> Our computer security analogies are modeled around securing a home from burglars
Well, no home is burglar-proof either. Just like with computer security, we define , often just implicitly, a threat model and then we decide which kind of security measures we use to protect our homes. But a determined burglar could still find a way in. And here we get to a classic security consideration: if the effort required to break your security is greater than the benefit obtained from doing so, you're adequately protected from most threats.
I agree, my point is we need to be using the correct threat model when thinking about those risks. You might feel comfortable storing your unreplaceable valuables in a house that is reasonably secure against burglars, even if it's not perfectly secure. But you'd feel otherwise about an oceanfront property regularly facing 30 foot storm surges. I'm saying the latter is the correct frame of mind to be in when thinking about whether to put data onto an Internet-connected computer.
It's no huge loss if the sea takes all the cat photos off my phone. But if you're a hospital or civil services admin hooking up your operation to the Internet, you gotta be prepared for it all to go out to sea one day, because it will. Is that worth the gains?
And I think there's some cognitive problem that prevents people from understanding that "the effort required to break your security" has been rapidly trending towards zero. This makes the equation effectively useless.
(Possibly even negative, when people go out and deliberately install apps that, by backdoor or by design, hoover up their data, etc. And when the mainstream OSes are disincentivized to prevent this because it's their business model too.)
There was a time, not very long ago, when I could just tcpdump my cable-modem interface and know what every single packet was. The occasional scan or probe stuck out like a sore thumb. Today I'd be drinking from such a firehose of scans I don't even have words for it. It's not even beachfront property, we live in a damn submarine.
Do you use a bank account? Or do you still trade using only the shells you can carry in your arms? Perhaps networked computers are secure enough to be useful after all.
I never claimed the Internet isn't useful. I just think people don't recognize how vulnerable computers are to attack. Search this very incomplete list for "bank": https://en.wikipedia.org/wiki/List_of_data_breaches
The non-sensicalness of it is just a phase. Remember the Tower of Babel didn't stop humanity.
Here is a link that was posted a few days ago regarding how great things are compared to 200 years ago. Ice cream has only become a common experience in the last 200 years..
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
I don't want to live on this planet anymore