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

121–130 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#121

Post by wyager »

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.

Do we? Or does "positivity" enable insecure software because there isn't enough social pressure against making dangerous engineering decisions?

Re: Third High Severity CVE in Log4j Is Published

#122

Post by klyrs »

TedDoesntTalk wrote: post #118
klyrs wrote: post #26

Earlier quoted context omitted.

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…

Even with an audit and 100% unit test coverage, and static code analysis, vulnerabilities slip through. Software is not perfect and you do not have a silver bullet.

I'd agree if this was the first CVE. But that got some attention to log4j, which quickly exposed two more CVEs. There's no such thing as perfect, but these problems almost certainly would have been caught by a competent security audit.

Re: Third High Severity CVE in Log4j Is Published

#123

Post by TedDoesntTalk »

pimlottc wrote: post #92
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’s worth noting that log4j does a lot more than, say, JavaScript’s console.log function. It’s dynamically configurable, supports a wide range of output formats and destinations, easily filterable, and highly optimized to reduce performance impact (in part through delayed evaluation and multi-threading). Rolling your own logging library to reimplement it is not trivial, even if you ignore the more esoteric output fo…

> wide range of output formats

Not to mention a wide range of destinations, too. Want to log to a database table? You’re covered. What about log messages to a chat server (xmpp, slack) or email but only fatal errors? You’re covered.

Now roll your own logging system that supports those destinations safely and get back to me to do pen testing. I bet we’ll find some vulns in your code.

Re: Third High Severity CVE in Log4j Is Published

#124

Post by nlitened »

dwaite wrote: post #84
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…

How do I fund ripping out bad ideas from existing open source software? Log4j2 partially exists because of pushback on adding features to v1

Fund a new fork

Re: Third High Severity CVE in Log4j Is Published

#125

Post by kafkaIncarnate »

5e92cb50239222b wrote: post #71
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…

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.

Who said anything about 'nicely'? Or 'ask'?

Re: Third High Severity CVE in Log4j Is Published

#126

Post by staticassertion »

jiggawatts wrote: post #88
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…

I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some myster…

I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But there's no patch.

What are you doing about it?

With log4j you have a brutal combination of:

1. RCE

2. Exposure

RCE happens frequently but often attackers don't have an easy time getting to the exploitable code. With log4j it's trivial - every app can be owned.

But here are some questions:

1. Why do those apps have the ability to make network requests?

2. For the apps that need to make those requests internally, why aren't those over mTLS?

3. For the apps that need to make them externally, why isn't that going through egress proxying?

4. Why are there credentials spewed all over your environment variables across your services? Are they short lived?

It's actually not super hard to have a worst-case scenario vulnerability like log4j be not that bad for your organization. A bit of hardening and even if something like this happens you're in a good position to wait, monitor, and patch.

Re: Third High Severity CVE in Log4j Is Published

#127

Post by watwut »

wyager wrote: post #121
diob wrote: post #99

Earlier quoted context omitted.

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

Do we? Or does "positivity" enable insecure software because there isn't enough social pressure against making dangerous engineering decisions?

Are you saying there would be more security issues if we thanked maintainers more?

Re: Third High Severity CVE in Log4j Is Published

#128

Post by staticassertion »

jiggawatts wrote: post #116
c-cube wrote: post #96

Earlier quoted context omitted.

If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?

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.

Re: Third High Severity CVE in Log4j Is Published

#129

Post by _ph_ »

nimrody wrote: post #66

It's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)

Thats the point. Giving back money for the libraries used might not fix anything and can be difficult in many cases. But the most and important way of "giving back" would be testing and review of the libraries used. If especially the large companies using this library had used some of the dev hours for testing and review, the bug should have been found early on.

Re: Third High Severity CVE in Log4j Is Published

#130

Post by staticassertion »

samhw wrote: post #46
jeffbee wrote: post #22

Earlier quoted context omitted.

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?

Honestly, absolutely not, and I think money would be harmful. Lots of software doesn't need a lot of work. It can be simple. When people get paid to solve problems there's an incentive to add more code, to add new domains, etc.

Use the standard java logger and move on, it's that easy.

Post reply on HN