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

Re: Third High Severity CVE in Log4j Is Published

#41

Post by samhw » Sat, Dec 18, 2021, 7:02 PM UTC

jacquesc wrote: post #28

ivan_gammel wrote: post #21

Earlier quoted context omitted.

Java ecosystem is rich and much more developed than anything else. There are plenty of better solutions on the market, both open source and commercial. There exist alternatives to log4j for a while, e.g. logback, which is the default option for Spring Boot applications - there was absolutely no need to use log4j2. It was always a free choice. It is worth mentioning, that any even very basic solution always has a poss…

Why can't we point out that the "default" choice for most java shops is one that is massively overcomplicated, a nightmare to use, and subject to security disasters like we are seeing? This wasn't "unknowable". Using overly complicated, poorly designed software is a direct cause. Why should I show respect for software I hate using and that causes problems for the entire tech community? I appreciate that they built it…

I'm not a Java developer, but I don't quite understand your complaint. You haven't used the library in question, you don't have any experience beyond the 'smell of the ecosystem' two decades ago, but you're opining at length on its 'poor design' and proneness to security disasters.

What knowledge do you have, about this library which you've never used, which qualifies you to say that it's especially prone to security vulnerabilities - other than hindsight bias?

Re: Third High Severity CVE in Log4j Is Published

#42

Post by jacquesm » Sat, Dec 18, 2021, 7:03 PM UTC

klyrs wrote: post #26

bob1029 wrote: post #16

Earlier quoted context omitted.

> 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…

I don't expect every user to audit code. But one of the audits I was privvy to was a part of the federal government and had really stringent requirements for the code that they run -- which, of course, includes tracking down all the dependencies, and, yes, is expensive. The fact that this extremely widely-used project never hit such an audit is a curiosity. And a bit of a tragedy of the commons -- many millions of do…

Indeed. Every Node.js/npm installation, ever.

Re: Third High Severity CVE in Log4j Is Published

#43

Post by intro-b » Sat, Dec 18, 2021, 7:03 PM UTC

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…

bc log4j isn't some random library people found on the street it's been used in industry forever lol

yea literally any library/dependency can introduce risk, including stuff coded internally for those purposes

Re: Third High Severity CVE in Log4j Is Published

#44

Post by ta988 » Sat, Dec 18, 2021, 7:04 PM UTC

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…

Problem comes when you have a lot of various parts that want to log. Lets say you have a message processing system getting messages from http and throwing that in a db and keeping counts on an external API. Now every module can use a log library and you, final user of the system can decide where the db log goes, where the http client debug message go, how much detail you want on any of these etc. So in the world of small applications and services, you can come up with a simple logging function. On large projects it is much more complicated.

Re: Third High Severity CVE in Log4j Is Published

#45

Post by intro-b » Sat, Dec 18, 2021, 7:04 PM UTC

jacquesc wrote: post #13

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…

Thanks to Log4J developers for turning me off to Java 20yrs ago due to their horrible API design and developer experience. Does not shock me that this security vulnerability happened, but it did shock me that so many people kept using this awful library. I thus enjoyed a development career (mostly) free from this kind of needless pain and suffering.

damn i checked ur profile and ur actually based respect

Re: Third High Severity CVE in Log4j Is Published

#46

Post by samhw » Sat, Dec 18, 2021, 7:04 PM UTC

jeffbee wrote: post #22

Kreotiko wrote: post #9

If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a…

I'm baffled by these claims that we should compensate the authors and maintainers of what has been conclusively shown to be software too dangerous to exist. It has the same problem as calls to pay the maintainers of openssl. No amount of money is going to impart good taste and best practices onto these projects. The uncomfortable truth is these libraries need scratch rewrites with better authors.

> The uncomfortable truth is these libraries need scratch rewrites with better authors.

If that's true, do you think that having money might possibly be helpful to that effort?

Re: Third High Severity CVE in Log4j Is Published

#47

Post by cnorthwood » Sat, Dec 18, 2021, 7:04 PM UTC

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…

because Log4J is also used by libraries. Which means you can configure the log level and capture logs from libraries and dependencies you use in a global configuration.

Re: Third High Severity CVE in Log4j Is Published

#48

Post by samhw » Sat, Dec 18, 2021, 7:06 PM UTC

natded wrote: post #12

Kreotiko wrote: post #9

If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a…

> educate their organisations on the importance of supporting open source solutions Githubs of the world could just gate downloads, pull requests etc. behind a payment to see what is the real valuation of open source software; I imagine it'd mostly settle around $0 excluding couple of big projects.

Up until the semicolon, this was actually a decent point. I can see a future for high-quality open-source software hosted on an 'app store' which requires a small payment for use - or for commercial use, perhaps.

Re: Third High Severity CVE in Log4j Is Published

#49

Post by doikor » Sat, Dec 18, 2021, 7:07 PM UTC

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…

Main thing is being able to share the logging stuff between libraries so something like slf4j and then various actual implementations of that facade (which log4j is one of) in jvm land.

There is also lots of stuff you might want a logging library to do that while not very hard would be annoying to do yourself for every project like log file rotation, switching log level while the application is running, optimizations (like in c/c++/rust you might compile for INFO level and drop all the DEBUG and TRACE level logging from the binary), different log levels for different parts of the app (including dependencies), etc

Re: Third High Severity CVE in Log4j Is Published

#50

Post by doikor » Sat, Dec 18, 2021, 7:07 PM UTC

cnorthwood wrote: post #47

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…

because Log4J is also used by libraries. Which means you can configure the log level and capture logs from libraries and dependencies you use in a global configuration.

You really shouldn't use log4j in libraries. Instead use slf4j in a library and log4j (or whatever implementation for the facade you prefer) in the application using the library.