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

131–140 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#131

Post by a-dub »

hn_throwaway_99 wrote: post #109
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 man…

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

yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the logging library should not be attempting to parse the log strings, but think about all the other millions of lines of code that could potentially try to parse that data as well. patch log4j one day and the next you find a bug in some colorizer javascript library or in the sixel support for the terminal emulator. people add parsing everywhere.

i think ideally that all user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging.

Re: Third High Severity CVE in Log4j Is Published

#132

Post by bobbyi »

nlitened wrote: post #124
dwaite wrote: post #84

Earlier quoted context omitted.

How do I fund ripping out bad ideas from existing open source software? Log4j2 partially exists because of pushback on adding features to v1

Fund a new fork

Why not logback instead? It's existed for more than 10 years and its stated goal is "picking up where log4j 1.x leaves off"

http://logback.qos.ch/

Re: Third High Severity CVE in Log4j Is Published

#133

Post by staticassertion »

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

Code auditing is extremely expensive. I recently did some napkin math and my estimate is that for our relatively small project (a company of ~10) it would cost between 2 and 12 million dollars to have our rust dependencies audited, with Rust making up ~60% of our codebase.

And that's a point in time audit. To maintain that value we'd have to redo the audit periodically.

It's just not gonna happen.

Re: Third High Severity CVE in Log4j Is Published

#134

Post by staticassertion »

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.

I don't know anything about it but I will say that people tend to audit crypto libraries and tend not to audit logging libraries.

Re: Third High Severity CVE in Log4j Is Published

#136

Post by yawaramin »

jiggawatts wrote: post #116
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?

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" runnin…

Go 1.18 onwards will solve this problem: https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersi...

> The go command now embeds version control information in binaries including the currently checked-out revision and a flag indicating whether edited or untracked files are present.... Additionally, the go command embeds information about the build including build and tool tags (set with -tags), compiler, assembler, and linker flags (like -gcflags), whether cgo was enabled, and if it was, the values of the cgo environment variables (like CGO_CFLAGS).

Re: Third High Severity CVE in Log4j Is Published

#137

Post by yawaramin »

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?

Would less funding have uncovered it?

Re: Third High Severity CVE in Log4j Is Published

#138

Post by TedDoesntTalk »

klyrs wrote: post #122
TedDoesntTalk wrote: post #118

Earlier quoted context omitted.

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.

I'd agree if this was the first CVE. But that got some attention to log4j, which quickly exposed two more CVEs. There's no such thing as perfect, but these problems almost certainly would have been caught by a competent security audit.

Has any of your software been through a security audit? Mine has. It’s 99.9% OWASP coverage with some automated fuzzing with almost no imagination applied by the auditors. You’re assigning far too much ability to auditors.

Re: Third High Severity CVE in Log4j Is Published

#139

Post by def_true_false »

RHSeeger wrote: post #40
jeffbee wrote: post #22

Earlier quoted context omitted.

I'm baffled by these claims that we should compensate the authors and maintainers of what has been conclusively shown to be software too dangerous to exist. It has the same problem as calls to pay the maintainers of openssl. No amount of money is going to impart good taste and best practices onto these projects. The uncomfortable truth is these libraries need scratch rewrites with better authors.

Saying things like "I don't like this software because " is reasonable; it can be considered constructive criticism, especially if you include a way it could be done better. Heck, even just "I think it's too complicated to use, and the underlying code base needed to support that complexity lends itself to bugs that can be exploited" would be better. Saying things like "No amount of money is going to impart good taste…

If only being nice to people prevented security bugs, eh?

Re: Third High Severity CVE in Log4j Is Published

#140

Post by klyrs »

TedDoesntTalk wrote: post #138
klyrs wrote: post #122

Earlier quoted context omitted.

I'd agree if this was the first CVE. But that got some attention to log4j, which quickly exposed two more CVEs. There's no such thing as perfect, but these problems almost certainly would have been caught by a competent security audit.

Has any of your software been through a security audit? Mine has. It’s 99.9% OWASP coverage with some automated fuzzing with almost no imagination applied by the auditors. You’re assigning far too much ability to auditors.

Upthread, I mentioned that I've been party to it three times. And yes, auditor skill and methods vary.
Post reply on HN