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

111–120 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#111

Post by themerone »

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…

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.

Re: Third High Severity CVE in Log4j Is Published

#114

Post by [deleted] »

brabel wrote: post #104
ashtonkem wrote: post #34

Earlier quoted context omitted.

I am not. Although one of my direct's decisions to setup a parent pom to manage versions across all our apps is paying back dividends this week.

You still need to update the parent POM version in all sub-modules. Or do you use version ranges or something like that for the parent POM?

[deleted]

Re: Third High Severity CVE in Log4j Is Published

#115

Post by l5ymep »

kzrdude wrote: post #24
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…

Maybe we should tell them to engage with open source, not "support it". Companies should look for a way to spend work hours on open source, not finding someone to send money.

Convincing project managers to tackle tech debt is hard enough. Contributing to open source won't even reach the middle ear unfortunately.

Re: Third High Severity CVE in Log4j Is Published

#116

Post by jiggawatts »

c-cube wrote: post #96
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…

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" running on it that has a vulnerability in it, you don't have many options.

IMHO, typical IT as done in the wild suffers from this write-once attitude, where the chain of provenance is too easily broken.

Companies like Google have a very non-typical setup that can be copied only by very small orgs like startups. Typical enterprises look nothing like a startup or a FAANG.

Re: Third High Severity CVE in Log4j Is Published

#117

Post by TedDoesntTalk »

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…

> I'm saying that the original devs are criminals

That’s an unbelievable stretch. I wonder how your mind works.

Re: Third High Severity CVE in Log4j Is Published

#118

Post by TedDoesntTalk »

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…

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.

Re: Third High Severity CVE in Log4j Is Published

#119

Post by marcus0x62 »

hirako2000 wrote: post #69
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.)

Each enterprise doesn't only use this common library, it uses a few more hundreds. If the point of pulling libraries is to save tremendous time in not having to write them, I can assure you managers aren't keen in wasting their gains in looking deeply into what's inside. Spotting the flaws, even with careful reviewing is still unlikely to happen, and would benefit the community at wide over their selfish interests.En…

Not only are they not interested in spending time auditing code, your typical enterprise lacks the skillset to do so effectively. They couldn't do it if they wanted to, short of contracting it out.

Re: Third High Severity CVE in Log4j Is Published

#120

Post by laumars »

alanfranz wrote: post #3
efitz wrote: post #2

On behalf of all information security people everywhere, I want to thank Apache for all the wonderful Christmas presents this year. I hope you step on a Lego.

This attitude should stop. They're volunteers. It's open source. Users are required to use such piece of software at their own will and risk. Log4j didn't ever get a single penny from most (all?) of their users, and now they should take all the blame. Why? The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result. Why didn't anybody else ste…

> The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result.

Even with proper disclosure, patching can be harder than it seems at face value. Take shellshock (the bash RCE from 2014) for example, the first patch was released a week after discovery and publication happened after the patch was released. Yet there were still a flurry of further CVEs found and further emergency patches required as a result.

The problem is once a major vulnerability is discovered, you then have a the worldwide attention focused on that specific vulnerability looking for other ways to break it. So it’s not really a surprise that you find multiple CVEs for most major vulnerabilities.

Post reply on HN