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

261–270 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#261

Post by rini17 »

yjftsjthsd-h wrote: post #244
Too wrote: post #240

Earlier quoted context omitted.

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.

Joke's on you: Then any nontrivial project would end up depending on half of them, actually increasing attack surface.

Re: Third High Severity CVE in Log4j Is Published

#262

Post by Macha »

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…

> If you think Log4j is bad, wait until Rust gets popular and has something similar happens with a commonly used crate. How would you scan for a vulnerability in compiled code that doesn't even have separate module files?

Our software scans take 3 forms:

1. Searching for file names

2. Running test exploits that have a payload that just logs the vulnerability with a central monitoring system

3. Dependency resolution and checks against a DB (our solution _already_ supports Cargo.lock files.

Rust (and Go, C++, etc.) only prevent option 1. Thanks to bundlers it also can miss it in JS, or shaded fatjars it can also fail kn Java too. So it's not a new challenge

Re: Third High Severity CVE in Log4j Is Published

#263

Post by junon »

derefr wrote: post #213
junon wrote: post #171

Earlier quoted context omitted.

> Library .so files are not harder to scan than jar files. Of course they are. You can trivially reverse engineer Java bytecode back to Java, with almost everything except generic annotations due to erasure, and a few other small things. Tools have been around for ages that do this[0], and while they're not perfect, they can re-generate nearly perfectly compilable source code. .so files are ELF files, which means whi…

> This means you need to convert machine code (assembly) back to a higher level language ...why? You don't need code to be in an HLL representation in order to patch it. Where by "patching" I mean "automatic insertion of a JMP into the subroutine prologue, that branches to your replacement code." You don't even need to write any assembly in order to do that, either; you can write your replacement subroutine in C or w…

You don't need to, you're right. But people aren't going to be writing very complex mitigations by reverse engineering the bytecode generated by a compiler, especially for OSS. There are many compilers, many optimizations, and some of them can even produce non-deterministic outputs (not common but it can happen). The amount of patching for an internal subroutine, which is probably what would have resulted here, would have been completely practically infeasible.

Re: Third High Severity CVE in Log4j Is Published

#264

Post by fulafel »

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…

You can, and people do, scan native binaries for these things. It's called SCA (software composition analysis).

Re: Third High Severity CVE in Log4j Is Published

#265

Post by ChuckNorris89 »

aidenn0 wrote: post #185
staticassertion wrote: post #150

Earlier quoted context omitted.

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.

Doing it right sometimes pays off in the long run, but cutting corners always pays off now.

Exactly. Managers and execs love pointing out the cost savings they made this year or this quarter. By the time the chicks start to hatch "in the long run", they most likely would have already moved to another enterprise so someone else has to clean up their mess. And by clean up, I mean repeat exactly the same mistakes since nobody promotes you for implementing stuff that might show its benefits in the long run.

Re: Third High Severity CVE in Log4j Is Published

#266

Post by junon »

I maintain `debug` for Node.js and the Log4J devs are living my worst nightmare when it comes to that library. It's used just about everywhere and any sort of zero-day would have far reaching implications.

Hugs for all of you. This can't be fun.

Re: Third High Severity CVE in Log4j Is Published

#268

Post by gonzo41 »

yjftsjthsd-h wrote: post #244
Too wrote: post #240

Earlier quoted context omitted.

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.

I bet they'd all compete on features and probably implement the same exploit trying to maintain market share.

Logging as it's understood today should ship with most STD libraries. Things like logback an log4j really should just eventually be rolled into the std.

Re: Third High Severity CVE in Log4j Is Published

#269

Post by tormeh »

Too wrote: post #236
lazide wrote: post #232

Earlier quoted context omitted.

Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.

Lesson learned. Never buy closed source. Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it. Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.

If it's a 20 year old closed source application, there probably aren't any exploits in the wild. You can bet there are exploits for log4j.

Re: Third High Severity CVE in Log4j Is Published

#270

Post by tekknik »

l5ymep wrote: post #115
kzrdude wrote: post #24

Earlier quoted context omitted.

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.

Let’s not even get legal involved…
Post reply on HN