Third High Severity CVE in Log4j Is Published • Hacker News Board

Re: Third High Severity CVE in Log4j Is Published

#151

Post by dakra » Sat, Dec 18, 2021, 10:14 PM UTC

scrame wrote: post #59

peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

The issue is that java did not initially ship with logging capabilities, and by the time it was part of the java.util package, a handful of logging systems had already been introduced by library vendors. JBoss, Jakarta Commons, Log4j and ultimately slf4j all were introduced to address these shortcomings. The larger issue is in javas dependency system are built with dependencies on these libraries, so if there is no c…

I found this a good overview of the history/current status of Java logger libraries https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-...

Re: Third High Severity CVE in Log4j Is Published

#152

Post by dylan604 » Sat, Dec 18, 2021, 10:19 PM UTC

TedDoesntTalk wrote: post #117

dylan604 wrote: post #53

Earlier quoted context omitted.

Just because someone releases code with AS IS/NO WARRANTY/BLAH BLAH BLAH doesn't mean they should not get called out for introducing such a vuln. Yes, you chose the code, failed to evaluate it's security, etc, but at the end of they day, the Log4* devs made a very very bad decision. Sadly, because of it's deep use in so many projects, it has kind of become too big to fail. I doubt %1 of users will swap out the loggin…

> I'm saying that the original devs are criminals That’s an unbelievable stretch. I wonder how your mind works.

Sorry, I absolutely meant to include NOT in that sentence. No, I do not believe they are criminals. I am guilty of not double checking my post to make sure it says what I meant to say.

Re: Third High Severity CVE in Log4j Is Published

#153

Post by throwuxiytayq » Sat, Dec 18, 2021, 10:19 PM UTC

diob wrote: post #99

alanfranz wrote: post #4

Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…

So happy to see this as the top comment. We need way more positivity in tech.

I was here just to say this - seeing this comment at the top of the thread restores my faith in people.

Re: Third High Severity CVE in Log4j Is Published

#154

Post by ahtihn » Sat, Dec 18, 2021, 10:20 PM UTC

johnisgood wrote: post #36

peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

Whenever I write C, the goal is to have no or very few dependencies. When I see projects written in C, one of the features is that it has no dependencies. This is a good thing. I do not know why we are steering away from this.

Dependency management in C is absolutely awful, that's why "no dependencies" is a "feature"

Re: Third High Severity CVE in Log4j Is Published

#155

Post by hn_throwaway_99 » Sat, Dec 18, 2021, 10:21 PM UTC

a-dub wrote: post #131

hn_throwaway_99 wrote: post #109

Earlier quoted context omitted.

It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. The fundamental problem is that, pretty surprisingly, log4j was running the same parsing and logic on user-entered strings as they did format strings. That's essentially the root cause of all this - log4j shouldn't be attempting to parse this data at all. So man…

> It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the l…

So you never browse the web?

Re: Third High Severity CVE in Log4j Is Published

#156

Post by jethro_tell » Sat, Dec 18, 2021, 10:22 PM UTC

staticassertion wrote: post #128

jiggawatts wrote: post #116

Earlier quoted context omitted.

The source code is not what is deployed . There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. If it came from an external organisation, things are exponentially harder. Modern deployment systems are largely "one-way", with no way to trigger a full recompile from the deployment end of things. If you have a VM with "SomeRandomBinary.exe" runnin…

This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.

It shouldn't be hard for a dev to update a dependency which should trigger an auto build and roll your pipeline. Shouldn't be hard for an upstream vendor to patch and have that pulled to kick off a new build.

IDK where this idea that no one can know what's in a dependency tree is coming from but is not ops best practice for more than a decade.

Re: Third High Severity CVE in Log4j Is Published

#157

Post by jjav » Sat, Dec 18, 2021, 10:23 PM UTC

filmgirlcw wrote: post #100

alanfranz wrote: post #80

Earlier quoted context omitted.

Discussion is ok. Disrespect is not. What original sin? What fault? You’re basically saying that log4j developers lured you into temptation, otherwise you would have coded your own logging library, which, for sure, would have been better. I haven’t seen 1/100 of this hatred for Apple iMessage vuln that led to NSO zero-click exploits, and I don’t get why.

> I haven’t seen 1/100 of this hatred for Apple iMessage vuln that led to NSO zero-click exploits, and I don’t get why. I think there are a few reasons for this, and most of them aren’t based on logic, but emotion. First, as bad as the NSO zero-click exploits are, they aren’t things that developers were potentially injecting into their own projects. So there is an easier force to “blame” — Apple (for making the mista…

It's actually fairly similar to the Apple bug, in that it was also a library with unnecessarily complex functionality that wasn't needed for the use case but just came along for the ride and ended up exploitable.

Re: Third High Severity CVE in Log4j Is Published

#158

Post by BrandoElFollito » Sat, Dec 18, 2021, 10:24 PM UTC

I see plenty of comments about security teams that should be doing this or that.

I do not know about your security teams, but my security teams are now sitting 9 days straight trying to stop that shitshow. With teams complaining that they have to patch instead of doing Great Things.

After that these security teams will be back to invisible work and forgotten again. Until the next issue.

If your company has a truly different approach to security, tell it here - you may get really talented people knocking in because they are fed up with the security theater at their current job.

Re: Third High Severity CVE in Log4j Is Published

#159

Post by virtual_void » Sat, Dec 18, 2021, 10:31 PM UTC

def_true_false wrote: post #139

RHSeeger wrote: post #40

Earlier quoted context omitted.

Saying things like "I don't like this software because " is reasonable; it can be considered constructive criticism, especially if you include a way it could be done better. Heck, even just "I think it's too complicated to use, and the underlying code base needed to support that complexity lends itself to bugs that can be exploited" would be better. Saying things like "No amount of money is going to impart good taste…

If only being nice to people prevented security bugs, eh?

Are you proposing that being rude does?

Re: Third High Severity CVE in Log4j Is Published

#160

Post by jjav » Sat, Dec 18, 2021, 10:31 PM UTC

bob1029 wrote: post #16

klyrs wrote: post #7

Earlier quoted context omitted.

Having worked with security-minded institutions in the past, I've endured and participated in year(s)-long audits of three different open source software projects. The thing that amazes me is that nobody using this software ever did their due diligence. You literally get what you pay for. Kindly step on your own legos and be happy this didn't happen in early April.

> The thing that amazes me is that nobody using this software ever did their due diligence. How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind? The game theory and assumptions around a "logging" library probably led a lot of organizations to not even consider it a p…

> How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind?

Back a long time ago, companies were extremely wary of including any open source library (let alone thousands!) into their product. It took a very long time with audits, lawyers, etc to get a single library approved.

Yes, it was kind of a pain.

So the world has swung into the other extreme these days. Just pull in a couple thousand libraries from the internet, nobody knows what they even are or what's in them. All in the name of speed. So it has its benefits.

But the fundamental concerns of long ago are still there. Bringing in unreviewed third party code is a vector for vulnerabilities, supply chain attacks and all that joy.