Third High Severity CVE in Log4j Is Published • Hacker News Board

Re: Third High Severity CVE in Log4j Is Published

#101

Post by nitrogen » Sat, Dec 18, 2021, 8:31 PM UTC

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…

With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update.

ELF binaries are just collections of another sort. You can scan for symbol names or assembled instructions common to a dependency, and you might be able to update with an LD_PRELOAD library that patches the symbol table.

Just look at what game modders have accomplished without access to source code.

Re: Third High Severity CVE in Log4j Is Published

#102

Post by darkr » Sat, Dec 18, 2021, 8:33 PM UTC

UncleMeat wrote: post #93

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…

Would more funding have actually uncovered this?

Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then it might well have done

Re: Third High Severity CVE in Log4j Is Published

#103

Post by solididiot » Sat, Dec 18, 2021, 8:38 PM UTC

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…

[dead]

Re: Third High Severity CVE in Log4j Is Published

#104

Post by brabel » Sat, Dec 18, 2021, 8:39 PM UTC

ashtonkem wrote: post #34

dreyfan wrote: post #27

I’m enjoying the Apache Software Exploit Advent Calendar

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?

Re: Third High Severity CVE in Log4j Is Published

#105

Post by junon » Sat, Dec 18, 2021, 8:41 PM UTC

nitrogen wrote: post #101

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…

With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. ELF binaries are just collections of another sort. You can scan for symbol names or assembled instructions common to a dependency, and you might be able to update with an LD_PRELOAD library that patches the symbol table. Just look at what game modders have accomplished wit…

This isn't how the real world works. Symbol patching is only effective if there's a symbol for it, which is often not the case (and probably wouldn't be the case here) if the binary has been stripped[0].

> Just look at what game modders have accomplished without access to source code.

Game modding is usually done on Windows given the target market (up until recently of course) and thus usually means Windows PE's, which do not have debug symbols attached - ever. Windows debug symbol databases are emitted as PDB files and are almost always omitted from game releases.

This means modding has to do a sigscan[1] in most cases in order to find something interesting - especially in the case of ASLR[2]. Then whatever modding framework (or hack) can set itself up and hook into the game.

These techniques are NOT what we should be encouraging, and are certainly not common, even for vulnerability mitigation. Re-compilation and re-deployment should be the defacto mode of operation in production, especially for systems that have sensitive information. Relying on bin-patching is not something many security specialists would regard as a "good" mitigation.

[0] https://en.wikipedia.org/wiki/Strip_%28Unix%29

[1] https://wiki.alliedmods.net/Signature_Scanning

[2] https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

Re: Third High Severity CVE in Log4j Is Published

#106

Post by aborsy » Sat, Dec 18, 2021, 8:41 PM UTC

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.

Re: Third High Severity CVE in Log4j Is Published

#107

Post by brabel » Sat, Dec 18, 2021, 8:42 PM UTC

MikusR wrote: post #20

They should open source it so the community can improve and fix bugs.

I thought the reason for the bugs was that they are not getting paid to maintain this library?! /s

Re: Third High Severity CVE in Log4j Is Published

#108

Post by jrochkind1 » Sat, Dec 18, 2021, 8:43 PM UTC

xigency wrote: post #29

More evidence that user provided data shouldn’t be logged at all.

It is pretty valuable to my debugging and general observability to log the URLs requested (including query component), which is user-provided data. I'm not saying I couldn't maintain my app operations without logging URI's including query strings... but it would definitely be more challenging.

Then there's the user-agent header, which also can be pretty valuable to debugging and other operations. Although this one is easier not to log.

In my current logs, I'm seeing attempts to compromise log4j vulnerability in both URL query string and user-agent. (Which of course I would not know about if I weren't logging them). This particular application has no Java involved, so is not vulnerable.

Re: Third High Severity CVE in Log4j Is Published

#109

Post by hn_throwaway_99 » Sat, Dec 18, 2021, 8:43 PM UTC

xigency wrote: post #29

More evidence that user provided data shouldn’t be logged at all.

It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println.

The fundamental problem is that, pretty surprisingly, log4j was running the same parsing and logic on user-entered strings as they did format strings. That's essentially the root cause of all this - log4j shouldn't be attempting to parse this data at all.

So many severe vulnerabilities are due to the complexities of parsing potentially malicious user input - just look at all the severe iMessage bugs. While many other apps do have a fundamental requirement to parse this input, there is no reason a logging library needs to do it.

Re: Third High Severity CVE in Log4j Is Published

#110

Post by kbenson » Sat, Dec 18, 2021, 8:43 PM UTC

jacquesc wrote: post #28

ivan_gammel wrote: post #21

Earlier quoted context omitted.

Java ecosystem is rich and much more developed than anything else. There are plenty of better solutions on the market, both open source and commercial. There exist alternatives to log4j for a while, e.g. logback, which is the default option for Spring Boot applications - there was absolutely no need to use log4j2. It was always a free choice. It is worth mentioning, that any even very basic solution always has a poss…

Why can't we point out that the "default" choice for most java shops is one that is massively overcomplicated, a nightmare to use, and subject to security disasters like we are seeing? This wasn't "unknowable". Using overly complicated, poorly designed software is a direct cause. Why should I show respect for software I hate using and that causes problems for the entire tech community? I appreciate that they built it…

> Why should I show respect for software I hate using and that causes problems for the entire tech community?

You aren't expected to. You're expected to show respect for the medium with which you are expressing those thoughts (HN), and the other people you are communicating with on that medium, by keeping the discussion civil and doing your part to keep it from devolving I to a flame-fest.

Almost nobody cares that you have and express dislike for this software. They care that you're doing it in a way which encourages additional discourse which isn't useful and wastes everyone's time.

At extremes it's the difference between staying you think a person is immoral or untruthful with reasons and calling someone an asshole. One of those is easier to have an actual discussion over than the other.