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

141–150 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#141

Post by layer8 »

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.)

Dealing with the current vulnerabilities is very likely cheaper than auditing each and every dependency with the thoroughness needed to actually catch those vulnerabilities. Also, nobody within the by affected enterprises gets blamed for those external vulnerabilities, nor are the enterprises liable for preventing them, so there is little incentive to prevent them proactively.

Re: Third High Severity CVE in Log4j Is Published

#142

Post by dylan604 »

alanfranz wrote: post #80
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…

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.

Disrespect for calling a spade a spade? Where have we found ourselves?

No, I would never use a logging library, so there was no luring. If you want to call those that did use it lured, then you're already coming at it that the original software devs were coniving.

Re: Third High Severity CVE in Log4j Is Published

#143

Post by querulous »

staticassertion wrote: post #126
jiggawatts wrote: post #88

Earlier quoted context omitted.

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…

it's definitely time for a language with a capabilities based security model that allows scope to the function/method level, at minimum

not just for security either. i can't count the number of times i've traced a performance problem or bug to a piece of code that was doing some io when it didn't need to

Re: Third High Severity CVE in Log4j Is Published

#144

Post by ytdytvhxgydvhh »

themerone wrote: post #111
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…

My Fortune 500 company has to pay a third party to pay for Google Maps, because we can't pay a supplier with a credit card. If we can't find a way to pay Google, there is no hope for some random developer in Nebraska.

That feels backwards. Little shops are flexible and can probably do what needs to be done. Lumbering behemoths have (too many) rules and restrict themselves (often) unnecessarily.

Re: Third High Severity CVE in Log4j Is Published

#145

Post by twunde »

staticassertion wrote: post #126
jiggawatts wrote: post #88

Earlier quoted context omitted.

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…

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or not at all. Documentation if it ever existed is likely lost. What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises

Re: Third High Severity CVE in Log4j Is Published

#146

Post by layer8 »

aborsy wrote: post #106

Does anyone know about the quality of crypto implementations in Java Cryptographic Extension (JCE), the standard crypto library in Java? We use a product that uses JCE. The log4j vulnerabilities worry me about the security of software in Java ecosystem in general.

They are generally high quality and implemented by cryptographers. Parts of the implementations are certified by NIST.

Log4j is not part of the JDK and is an open source project with only few regular contributors. There is really no reason to infer any correlation to other parts of the Java ecosystem.

Re: Third High Severity CVE in Log4j Is Published

#147

Post by ahtihn »

samhw wrote: post #48
natded wrote: post #12

Earlier quoted context omitted.

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

And how are you going to prevent someone from just hosting a mirror for free?

Re: Third High Severity CVE in Log4j Is Published

#148

Post by Perseids »

tatersolid wrote: post #97
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?

In commercial software the customers don’t have the source files…

Well, we're in a thread that started with

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

If there is the possibility to plan ahead from a sufficiently strong bargaining position, you will not end up in the situation you described. The seller should either continue to support it with a good SLA, or you get the source code with a turn-key build system if the seller discontinues its support. Or you switch out the software if the SLA ends. Should you not be able to agree on such terms, I don't think you would have enough influence to tell the seller to write their software in such a way that dependencies are easy to hotfix/upgrade.

Re: Third High Severity CVE in Log4j Is Published

#150

Post by staticassertion »

twunde wrote: post #145
staticassertion wrote: post #126

Earlier quoted context omitted.

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…

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or n…

Yes, some organizations have so much technical debt that any security work is going to take extraordinarily large amounts of work.

That's a bummer, but I suspect many on HN can in fact build software that isn't total garbage.

Post reply on HN