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

171–180 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#171

Post by junon »

ncmncm wrote: post #167
junon wrote: post #105

Earlier quoted context omitted.

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, whi…

The original claims are garden-variety BS. Library .so files are not harder to scan than jar files. They just need different tools, which everyone has. And Java systems are not easier to patch than others.

> 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 while they have sections, those sections don't typically reveal much about the internals of the code. This means you need to convert machine code (assembly) back to a higher level language - which is not a trivial transformation. There are tools that do do this (e.g. hexrays[1]) but they are far from perfect, especially for optimized machine code.

Java systems are very, very easy to crack, RE and patch. There are virtually no protections. JAR injection is still a valid means of patching a Java application. No, manifest files and integrity checks are not a security measure but an error detection measure, and are trivially bypassed.

If you asked me to choose between patching this vulnerability in a .JAR vs a .SO, I would choose the .JAR any day of the week.

[0] http://java-decompiler.github.io/

[1] https://hex-rays.com/

Re: Third High Severity CVE in Log4j Is Published

#172

Post by a-dub »

hn_throwaway_99 wrote: post #155
a-dub wrote: post #131

Earlier quoted context omitted.

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

So you never browse the web?

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 paths that data can take to touch that software is even more enormous. yes, one can put forth good principles for "building codes" for software and yes, one should... but there's an awful lot of software out there that is not up to code (where the craft is so young that the idea of a code isn't even close to being finalized) and it won't be for a very long time.

that being the actual on the ground situation, what is one simple thing that individual developers can do to help prevent catastrophes? always sanitize inputs. moreover, it's much easier to find and audit every place where data is accepted from untrusted sources than it is to find every place where data may be parsed.

Re: Third High Severity CVE in Log4j Is Published

#173

Post by ncmncm »

junon wrote: post #171
ncmncm wrote: post #167

Earlier quoted context omitted.

The original claims are garden-variety BS. Library .so files are not harder to scan than jar files. They just need different tools, which everyone has. And Java systems are not easier to patch than others.

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

You do not need to decompile any code to scan a .so for symbols used.

So, more advocacy BS.

Re: Third High Severity CVE in Log4j Is Published

#174

Post by junon »

ncmncm wrote: post #173
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…

You do not need to decompile any code to scan a .so for symbols used. So, more advocacy BS.

Please re-read my original comment. If the binary is stripped, no internal symbols would have been visible or even present in the file to be scanned. The jumps between subroutines happen directly, without a symbol jump table (because a jump table adds runtime overhead and is largely unnecessary, especially in statically linked executables).

Re: Third High Severity CVE in Log4j Is Published

#175

Post by xyproto »

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 make dynamically linked executables with both Go and Rust. The compilers have no blame in this.

Re: Third High Severity CVE in Log4j Is Published

#176

Post by ncmncm »

junon wrote: post #174
ncmncm wrote: post #173

Earlier quoted context omitted.

You do not need to decompile any code to scan a .so for symbols used. So, more advocacy BS.

Please re-read my original comment. If the binary is stripped, no internal symbols would have been visible or even present in the file to be scanned. The jumps between subroutines happen directly, without a symbol jump table (because a jump table adds runtime overhead and is largely unnecessary, especially in statically linked executables).

You do not need internal symbols.

All the public entry points are spelled out exactly by name, and all the external symbol dependencies.

Re: Third High Severity CVE in Log4j Is Published

#179

Post by marcosdumay »

pimlottc wrote: post #92
peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

It’s worth noting that log4j does a lot more than, say, JavaScript’s console.log function. It’s dynamically configurable, supports a wide range of output formats and destinations, easily filterable, and highly optimized to reduce performance impact (in part through delayed evaluation and multi-threading). Rolling your own logging library to reimplement it is not trivial, even if you ignore the more esoteric output fo…

Yeah, doing so much more is a bug, not a feature.

> It’s dynamically configurable

It's a logging library. You don't reconfigure logging, you just make another logger and use it. And by the way, you take the configurations from your global configuration system, "dynamic configurable" is a feature of the configuration system, not of the logging.

> supports a wide range of output formats and destinations

Yeah, like network aware templates. (But the destinations are a feature, multiple destinations are one of the few things a logging library should support.)

Despite what people claim, the Java culture of loving complexity never did go away.

Re: Third High Severity CVE in Log4j Is Published

#180

Post by spockz »

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…

Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)
Post reply on HN