Hacker News Reader

Comment by stickfigure | Hacker News Reader

> It isn't a Log4J moment.

The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.

I wouldn't downplay this.

View on HN

Core run time vulnerabilities in PHP, the language and runtime itself, are rare. I remember the days when an exploit in the JVM was a daily announcement. To the point where they had to ban java applets from the web.

> Core run time vulnerabilities in PHP, the language and runtime itself, are rare.

They may be rare today but they have historically been very common.

> To the point where they had to ban java applets from the web.

Those are not RCEs, they were sandbox violations. Sandboxing untrusted code is hard and really only javascript engines have pulled it off. Java and Dotnet gave up, and that's fine.

PHP's security failures are not from trying something ambitious. They're from generating web content on a server. These are not comparable.

Sandbox violations in a technology marketed as a way to run untrusted remote code safely are RCEs.

Did they learn not to fix overflows by checking a variable for "> PHP_INT_MAX"? That patch was hilarious. But you might have to meet Perl greybeards to understand the fun the internet made of the PHP core devs after that.

> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.

Some software written in PHP has a long history like that.

PHP itself mostly dont. Tbh runtime itself has fairly stellar track record on security considering it written in C.

This doesn't look like a stellar track record to me.

Year CVE Vulnerability Exploitation prerequisites

2004 CVE-2004-1019 Memory corruption in unserialize() Application processes untrusted serialized data

2006 CVE-2006-4812 Integer overflow in PHP's memory allocator through unserialize() Untrusted serialized data

2007 CVE-2007-0906 Buffer overflows in bundled PHP modules and string handling Application passes attacker-controlled data

2007 CVE-2007-1286 Integer overflow in unserialize() reference counting Untrusted serialized data

2010 CVE-2010-2225 Use-after-free in SplObjectStorage deserialization Untrusted serialized data

2012 CVE-2012-1823 PHP-CGI argument injection Vulnerable CGI deployment

2014 CVE-2014-8142 Use-after-free in PHP's unserialize() implementation Untrusted serialized data

2015 CVE-2015-0231 Use-after-free in PHP's object deserialization Untrusted serialized data

2015 CVE-2015-2787 Another use-after-free in unserialize() Untrusted serialized data

2016 CVE-2016-10160 Memory corruption in PHP's PHAR extension Application processes crafted PHAR archive

2019 CVE-2019-11043 Buffer underflow in PHP-FPM Particular web-server configuration

2024 CVE-2024-4577 PHP-CGI argument injection on Windows Particular Windows CGI configuration

IDK why someone flagged your reply, but basically your list shows that since 2015 there been practically no security issues that can really be exploited in default configuration.

10 years like thid seem pretty stellar for me considering half of internet runs on PHP.

To be fair, 2024's "PHP-CGI" and "Windows" are legacy features nobody is probably using. CGI was a technology to write servers using bash scripts (most popular programming language for Linux) and has been outdated for like what, 20 years?

That's not what CGI is. CGI is just mode of operation where full php process being spawned on each request and then killed. It's kind a less prone to security actually because no memory or state is reused ever.

But yeah since it's inefficient I doubt it used much after 2010 when php-fpm matured and nginx got popular.

> It wasn't even a problem with the most popular logging framework at the time.

I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.

My employer at the time didn’t use log4j, but we were still plenty vulnerable. All sorts of open source packages we used had a transitive dependency on it.

Very few opensource packages actually used log4j directly. Libraries generally use some sort of shim like commons-logging or slf4j so they can log into whatever your application chooses as a long sink.

Merely declaring a transitive dependency didn't mean that the code was executing nor did it mean that user input was actually being logged through those libraries.

Log4j v2 (the vulnerable version) just wasn't that common at the time. Most everyone had moved on to Logback, and Log4j v1 (not vulnerable) was still more popular than v2.

Was it actually though? I worked at an MSP at the time and our tools were just flagging the mere existence of the library. It either wasn't being used or wasn't exposed in any meaningful way. Oh a dev happens to have it installed on his laptop? Who cares.

I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)

> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.

What makes you say that? I know several websites that ran on unpatched PHP 5 versions for over a decade, without a care in the world until now, because there were no known serious vulnerabilities in the interpreter itself.

I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.

upgrading php is much easier.

It's a weird move for this post to simultaneously line this vulnerability up against Log4Shell (very few serversides are going to measure up to L4S) and insinuate that it's not practically exploitable at all.

If it was just "everyone take a breath, we've been through something worse with Log4Shell", that would make a lot more sense.

Log4g was exploitable from the second it was published

Log4J was utterly trivially exploitable across basically all configurations, so in that sense it was worse. But any unauthenticated RCE that's on the default configuration of such a widely deployed piece of software is a good cause for sounding the alarms, even if there isn't a script kiddie exploit that will do all of those versions.

Reply on news.ycombinator.com