If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C’s lack of memory safety, it’s very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C’s foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it’s not C’s problem, it’s just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn’t also running into these issues.
The time to be deploying PHP applications in production is long over. At this point it should be considered malpractice.
score 1 · canonical
WTF so if we find a similar bug in ruby then we ditch ruby, same for JS ?
I hope you never used or intend to use moodle, nextcloud, wikipedia, a forum, mailcow, mailchimp…
score 3 · canonical
PHP has a horrible security track record. This particular bug isn’t the reason to claim that, rather its history should be.
score 2 · canonical
If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C’s lack of memory safety, it’s very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C’s foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it’s not C’s problem, it’s just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn’t also running into these issues.
score 1 · canonical
not precisely that one but the problem has been known for over 6 years. https://bugs.php.net/bug.php?id=78876 https://gist.github.com/cmb69/384d5f5bb6b2de834877348dcdbe3282
score 1 · canonical