Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Third High Severity CVE in Log4j Is Published

logging.apache.org

Post reply on HN
Print view View original

71–80 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#71

Post by 5e92cb50239222b »

dylan604 wrote: post #53
alanfranz wrote: post #10

Earlier quoted context omitted.

If you don’t use the code, you’re not vulnerable > who should get the blame? The users? If you leverage a ton of open source deps, shit is going to happen. You should not blame anyone. But if you must, yes: blame the users that choose such piss-poor software.

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…

Would it be any better if this library was a proprietary product, the vulnerability would have been discovered by NSA and exploited until the end of time?

Come to think of it, they wouldn't even have to search for any exploits. Just ask devs nicely to put the backdoor in and be done with it.

Re: Third High Severity CVE in Log4j Is Published

#72

Post by AtNightWeCode »

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…

It is not complicated. Structured or semi-structured logging is the only way to log things and still be compliant with all the demands.

A lot of these libs separate logging into layouts and parameters. If you log input parameters as layouts. You might break the logging. I have seen this at every company I worked with.

The only really surprising thing about log4j is the remote code execution.

Re: Third High Severity CVE in Log4j Is Published

#73

Post by tomohawk »

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…

It's worse than that.

When Java finally added a logging library, they added one that no-one had ever heard of before, and which had fundamental flaws. That's why no-one uses it. At the time, log4j existed and was in wide use, but was not represented on the committee.

The author of log4j eventually decided to go a different way and created slf4j / logback. This offering is compatible with log4j and considerably simpler in many ways.

Having not been in the Java world for many years, I was surprised log4j was still in widespread use. But maybe I shouldn't be surprised - whenever we have to interact with Java teams, we always have to tamp down on the tendency towards complexity.

Re: Third High Severity CVE in Log4j Is Published

#74

Post by hirako2000 »

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…

Very well explained. About log4j2, I think it came to exist because log4j fell far behind logback, and many veteran dev didn't like the inherent push for slf4j over logback. While logback can be used standalone, snobs would yell at you. And since figuring out how to config slf4j over it can easily be less than half a day of work, many simply drooped in log4j2 and told snobs to go away.

Note: In case someone is tempted to say that it is trivial to plug slf4j over logback, it is for greenfield work. Replacing an existing logging library, or the use of multiple logging libraries in favor of slf4j over one lib is a confusing matter, mostly because the error thrown at runtime are misleading.

Re: Third High Severity CVE in Log4j Is Published

#75

Post by itronitron »

jacquesc wrote: post #17
Hallucinaut wrote: post #15

Earlier quoted context omitted.

log4j2 has little to do with the log4j you claim turned you off 20 years ago and almost no one works directly to the logging library API rather than an slf4j facade.

Fair enough. But to me it was the smell of a toxic Java ecosystem, where people had to use crappy software even though they knew how bad it was. It took a simple problem and turned it into a clusterfuck of configuration and complexity.

In many ways it was a trailblazer for npm and the modern javascript 'ecosystem'

Re: Third High Severity CVE in Log4j Is Published

#76

Post by stefan_ »

ivan_gammel wrote: post #21
jacquesc wrote: post #17

Earlier quoted context omitted.

Fair enough. But to me it was the smell of a toxic Java ecosystem, where people had to use crappy software even though they knew how bad it was. It took a simple problem and turned it into a clusterfuck of configuration and complexity.

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…

Of course the ecosystem is toxic. Java is literally the only ecosystem in the world where people regularly run into classloader issues because of conflicting logging libraries. And when it happens, that is a smash the fucking computer moment for the momentous stupidity that lead to it.

Yes, it's free. No, the vast majority of users never actively opted into it. No, it's not disrespectful to suggest that a log library that interpolates parameters was never fit for purpose.

Re: Third High Severity CVE in Log4j Is Published

#77

Post by hotpotamus »

akeck wrote: post #52
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 read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…

I have a feeling if a company wrote a large enough check, they'd figure out how to cash it.

Re: Third High Severity CVE in Log4j Is Published

#79

Post by ricardobayes »

hotpotamus wrote: post #77
akeck wrote: post #52

Earlier quoted context omitted.

I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…

I have a feeling if a company wrote a large enough check, they'd figure out how to cash it.

Well, wrte it to whom? No legal structure is what the comment was partly about.

Re: Third High Severity CVE in Log4j Is Published

#80

Post by alanfranz »

dylan604 wrote: post #53
alanfranz wrote: post #10

Earlier quoted context omitted.

If you don’t use the code, you’re not vulnerable > who should get the blame? The users? If you leverage a ton of open source deps, shit is going to happen. You should not blame anyone. But if you must, yes: blame the users that choose such piss-poor software.

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…

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.

Post reply on HN