upvote

points

by stickfigure4 hours ago |
comments
upvoteby bouncycastle3 hours ago|
next
[-]
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.
reply
upvoteby stickfigure2 hours ago|
parent|
next
[-]
> 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.

reply
upvoteby GuestFAUniverse1 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby Insimwytim4 hours ago|
prev|
next
[-]
> 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.

reply
upvoteby esikich3 hours ago|
parent|
next
[-]
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.
reply
upvoteby kgeist2 hours ago|
parent|
[-]
I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)
reply
upvoteby bunderbunder4 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby stickfigure2 hours ago|
parent|
[-]
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.

reply
upvoteby SXX2 hours ago|
prev|
next
[-]
> 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.

reply
upvoteby stickfigure1 hours ago|
parent|
[-]
[flagged]
reply
upvoteby bawolff3 hours ago|
prev|
next
[-]
I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.

upgrading php is much easier.

reply
upvoteby tptacek3 hours ago|
parent|
[-]
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.

reply
upvoteby bakugo1 hours ago|
prev|
[-]
> 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.

reply