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

211–220 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#211

Post by rukuu001 »

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

I did this years ago with an open-source and reasonably popular non-Apache library. The results were so horrifying my boss quickly concluded such audits were outside our responsibility and the time I spent on the audit was written off.

It was especially difficult for us because we’d shipped so much code that used the library, and replacing the library was unthinkable.

Re: Third High Severity CVE in Log4j Is Published

#212

Post by ncmncm »

junon wrote: post #203
ncmncm wrote: post #199

Earlier quoted context omitted.

Do you? Have you, e.g., written a linker? Educating is an entirely different process than you are engaged in.

I've written an operating system.

In Java? Maybe better go do that, then. You are doing this poorly.

Re: Third High Severity CVE in Log4j Is Published

#213

Post by derefr »

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…

> 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 whatever. The replacement subroutine just needs to codegen as a C-ABI subroutine with the same register preconditions/postconditions as the subroutine it's replacing.

Re: Third High Severity CVE in Log4j Is Published

#214

Post by derefr »

yawaramin wrote: post #136
jiggawatts wrote: post #116

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. 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, assemble…

On Windows, the Microsoft compilers and linkers have inserted such toolchain/library version metadata into PE executables for decades now (the "RICH" header — https://bytepointer.com/articles/the_microsoft_rich_header.h...).

At the time that Microsoft started doing it, paranoiacs thought it was some kind of anti-piracy software fingerprinting mechanism, embedding the compiling computer's MAC address or something. But really, it serves exactly the same purpose that Golang's effort does here: to let you map compiled-artifact back to inputs.

Re: Third High Severity CVE in Log4j Is Published

#215

Post by ashtonkem »

marcosdumay wrote: post #179
pimlottc wrote: post #92

Earlier quoted context omitted.

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

> It's a logging library. You don't reconfigure logging, you just make another logger and use it.

Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). Extremely helpful for incident debugging.

Now we can have an interesting discussion about whether that capability is worth the complexity, but that’s a very different discussion than unilaterally declaring that other people’s use cases just don’t exist.

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

Do you develop in Java? Because I do, and your takes don’t match my daily experience one bit. My experience going from Spring 3 to Spring Boot 2 is in fact one of reducing complexity (goodbye XML bean configuration!) and to more “it just works” situations than before.

Re: Third High Severity CVE in Log4j Is Published

#216

Post by macinjosh »

themerone wrote: post #111
akeck wrote: post #52

Earlier quoted context omitted.

I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…

My Fortune 500 company has to pay a third party to pay for Google Maps, because we can't pay a supplier with a credit card. If we can't find a way to pay Google, there is no hope for some random developer in Nebraska.

Just because a dev lives in the Midwest doesn’t mean they’re idiots compared to coastal elites. The hate/mockery/minimizing of anyone not from a major coastal city is really gross. Screw you.

Re: Third High Severity CVE in Log4j Is Published

#217

Post by rockwotj »

FridgeSeal wrote: post #191
jiggawatts wrote: post #116

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

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

Re: Third High Severity CVE in Log4j Is Published

#218

Post by bigiain »

jethro_tell wrote: post #156
staticassertion wrote: post #128

Earlier quoted context omitted.

This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.

It shouldn't be hard for a dev to update a dependency which should trigger an auto build and roll your pipeline. Shouldn't be hard for an upstream vendor to patch and have that pulled to kick off a new build. IDK where this idea that no one can know what's in a dependency tree is coming from but is not ops best practice for more than a decade.

> IDK where this idea that no one can know what's in a dependency tree is coming from

I’d guess people running commercial non source available binaries in production. And outside startups and unicorns, that’s almost everybody.

How do you find the dependancy tree for your on prem Oracle db, or your self hosted Atlassion stuff, or your non cloud ServiceNow or PeopleSoft stuff, or your Huawei network management stuff, or or or…

And what can you do for any of your cloud hosted saas stuff, beyond telling legal “I dunno, their website hasn’t said whether they’re vulnerable to exploit de jour yet”?

Re: Third High Severity CVE in Log4j Is Published

#219

Post by staticassertion »

bigiain wrote: post #218
jethro_tell wrote: post #156

Earlier quoted context omitted.

It shouldn't be hard for a dev to update a dependency which should trigger an auto build and roll your pipeline. Shouldn't be hard for an upstream vendor to patch and have that pulled to kick off a new build. IDK where this idea that no one can know what's in a dependency tree is coming from but is not ops best practice for more than a decade.

> IDK where this idea that no one can know what's in a dependency tree is coming from I’d guess people running commercial non source available binaries in production. And outside startups and unicorns, that’s almost everybody. How do you find the dependancy tree for your on prem Oracle db, or your self hosted Atlassion stuff, or your non cloud ServiceNow or PeopleSoft stuff, or your Huawei network management stuff, o…

Presumably you would go ask Oracle, and then patch it when they provide a patch.

Re: Third High Severity CVE in Log4j Is Published

#220

Post by watersb »

Perseids wrote: post #161
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…

> We have Sun's forward-thinking and the enterprise-friendliness of the Java ecosystem to thank for that. I find it quite ironic to praise the forward-thinking of the company that has been instrumental to bring us into this mess via their vision of loading dependencies at runtime from an online repository. Sun imagined that the code and its configuration does not have to worry about how to fulfill its dependencies, b…

I'm writing this from memory, with checking any sources. IIRC:

Designs like JNDI were widespread in the IT software industry at the time.

The academic prototype for all this was CORBA, the Common Object Request Broker Architecture. An object-oriented was to transmit data between systems running on separate processes, CPUs, remote servers.

CORBA was a next-gen RPC (Remote Procedure Call) framework, the data format on the wire closely follows the format for C structs using Sun-RPC, but was way better because these CORBA things were discoverable and described at run-time, rather than compile-time libraries.

That's right: RPC was initially a Sun UNIX thing.

Microsoft needed a way to do this, so they had COM, the Component Object Model, for run-time discovery and linking (late binding).. Microsoft got COM to reach across network connections, "DCOM", for Distributed systems.

Meanwhile, corporate IT was still pulling text out of databases and shoving it into C structs. It sucked.

Microsoft's object model was better, and Java was better than better, because you didn't have to license it to use it. Well, you did; it was like an MIT License.

Reason why IBM writes huge Java systems. And why Oracle owns Java. For some value of ownership.

Yay objects!

Post reply on HN