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

241–250 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#241

Post by kitd »

jiggawatts wrote: post #228
FridgeSeal wrote: post #191

Earlier quoted context omitted.

> 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. Do you not have this? Our docker images are tagged with the git hash they were built from, so at any point, for any of our envs, I can pull up the lock file of that build. Our deployment config also describes everything that is running the relevant…

This happened last week, for real with ${dayjob} customer. Put yourself in their shoes for a second. Imagine you are Mr SecOps guy, and you've just ran some sort of Log4j tool across literally three thousand servers . Of those, several hundred came back positive. Those included about a dozen flavours of Linux, a smattering of manually built(!) containers, and every version of Windows from 2008 R1 to 2022. Most of the…

So what you have now is literally just a string to a path, something like "D:\apps\foo\bar\baz\libs\stuff\thingie\log4j-core.jar" or the Linux equivalent.

Now what?

The remediation (until you can get an update from the vendor) is to remove the JndiLookup.class file from that jar. It's been fairly well publicised, as has the way to do it.

Re: Third High Severity CVE in Log4j Is Published

#242

Post by yjftsjthsd-h »

rockwotj wrote: post #217
FridgeSeal wrote: post #191

Earlier quoted context omitted.

> 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. Do you not have this? Our docker images are tagged with the git hash they were built from, so at any point, for any of our envs, I can pull up the lock file of that build. Our deployment config also describes everything that is running the relevant…

Yeah our org does the same thing and I'd say this is the gold standard (or at least mine) but sadly I'm assuming most companies don't do this, not everyone runs on docker nor has a build pipeline like this.

Sure, but everyone should be able to have their built process embed that info into build artifacts, whether it's by passing GCC a DEFINE flag that ends up in --version output, passing nasm a data structure embedded at X bytes into the binary, a version.txt in the output zip, an autogenerated comment inlined in each HTML/JS/CSS file, whatever... somehow, you can embed build info.

Re: Third High Severity CVE in Log4j Is Published

#243

Post by yjftsjthsd-h »

Spooky23 wrote: post #200
Perseids wrote: post #148

Earlier quoted context omitted.

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…

ROFL. Ok, after putting the unicorns herd to bed, an event happens and congratulations, you now own a license to PeopleSoft v.whatever source code. Oh yeah, you also got the management platform for your network provider too. Now what?

It's called code escrow and it's a real thing even if it's news to you. Although yes, it's usually an insurance plan you want to never ever need because using it will suck.

Re: Third High Severity CVE in Log4j Is Published

#244

Post by yjftsjthsd-h »

Too wrote: post #240
nlitened wrote: post #124

Earlier quoted context omitted.

Fund a new fork

Just leads to the xkcd “there are now 14 competing standards.” Honestly the biggest problem of package managers is finding a reputable package that one can trust. The best one can do to aid this situation is reviewing, vetting and warning of which packages that can be trusted and not. Automatic scanners to find code smells and vulnerabilities. “Security rating: 2/10, This package seems to use JNDI loading, are you su…

Humor me: if log4j had 13 (independently developed) competitors, wouldn't the impact of this be much lower, because many consumers would use different libraries? Like genetic diversity as a hedge against disease.

Re: Third High Severity CVE in Log4j Is Published

#245

Post by yjftsjthsd-h »

lazide wrote: post #234
themerone wrote: post #224

Earlier quoted context omitted.

I am a developer in the midwest, and maybe if you hadn't completely missed my poin you wouldn't be such a jerk. Nebraska is a reference to an XKCD Comic ( https://xkcd.com/2347/ ). The idea is that there are nameless people all over the world contributing to critical open source infrastructure. Back to the point. Running Google Maps on one of my low traffic sites, would generate at most, several dollars a month in ch…

How does your company handle coffee? Surely there is SOME mechanism for small incidental charges, or how could your company even exist?

Coffee company sends a monthly invoice.

Re: Third High Severity CVE in Log4j Is Published

#246

Post by yjftsjthsd-h »

symlinkk wrote: post #89
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…

Giving something away for free and then turning around and guilting people into paying for it is wrong.

Using something for free and expecting support is hilarious.

Re: Third High Severity CVE in Log4j Is Published

#247

Post by yjftsjthsd-h »

a-dub wrote: post #184
a-dub wrote: post #172

Earlier quoted context omitted.

sure. i don't think i'm articulating my real point well enough. web browsers and all of their components get audited. because they process potentially malicious data as their core function, they see A LOT of attention in terms of hardening. the point that i'm trying to make is: the amount of software that doesn't immediately and apparently touch potentially malicious data is absolutely enormous and the number of path…

sort of raises an interesting question. rust has memory safety, but it's still possible to write code that "isn't up to code." i wonder if maybe rust+1 will be the first language/environment/ecosystem that has application development security principles built in. that would mean, like, not just taking the compiler forward in terms of memory safety, but also codifying a set of principles, enforcing those that can be s…

Up until "singular library archive" I would say that exists today in the form of Ada and formal methods (and both in the form of SPARK)

Re: Third High Severity CVE in Log4j Is Published

#248

Post by jiggawatts »

kitd wrote: post #241
jiggawatts wrote: post #228

Earlier quoted context omitted.

This happened last week, for real with ${dayjob} customer. Put yourself in their shoes for a second. Imagine you are Mr SecOps guy, and you've just ran some sort of Log4j tool across literally three thousand servers . Of those, several hundred came back positive. Those included about a dozen flavours of Linux, a smattering of manually built(!) containers, and every version of Windows from 2008 R1 to 2022. Most of the…

So what you have now is literally just a string to a path, something like "D:\apps\foo\bar\baz\libs\stuff\thingie\log4j-core.jar" or the Linux equivalent. Now what? The remediation (until you can get an update from the vendor) is to remove the JndiLookup.class file from that jar. It's been fairly well publicised, as has the way to do it.

That provides incomplete protection even for this Log4j vulnerability, and similarly trivial "self help patching" may not be available for future vulnerabilities.

Re: Third High Severity CVE in Log4j Is Published

#249

Post by jiggawatts »

staticassertion wrote: post #239
lazide wrote: post #233

Earlier quoted context omitted.

Hope you’ve got a pretty sweet support contract or you’re going to be waiting awhile. Depending on the product, maybe forever.

My point is that patching third party binaries is generally not something companies take responsibility for. They wait for vendors to patch the binaries and ship them.

> generally not something companies take responsibility for

I have some bad news for you: viruses and hackers don't care about your support contracts and the delays they cause.

Actually, I tell a lie: the hackers love them.

Re: Third High Severity CVE in Log4j Is Published

#250

Post by yjftsjthsd-h »

tomohawk wrote: post #73
scrame wrote: post #59

Earlier quoted context omitted.

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

> Having not been in the Java world for many years, I was surprised log4j was still in widespread use.

It's Java; the ecosystem is, politely, rather conservative and slow moving.

Post reply on HN