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

161–170 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#161

Post by Perseids »

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…

> 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, but instead JNDI [1] could magically fetch the appropriate objects from wherever, don't worry.

I'd say I would even find it ironic to praise the Java ecosystem, which, due to its excessive over-engineering, has produced best practice frameworks where fully documented behavior has the latent potential to just be catastrophically exploitable by accident, as nobody is able to reasonably understand how all of it plays together. I have a hard time to imagine how you could enable loading of external code in Rust or Go by accident using run-of-the-mill logging frameworks.

[1] https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Inte...

Re: Third High Severity CVE in Log4j Is Published

#162

Post by johnisgood »

ahtihn wrote: post #154
johnisgood wrote: post #36

Earlier quoted context omitted.

Whenever I write C, the goal is to have no or very few dependencies. When I see projects written in C, one of the features is that it has no dependencies. This is a good thing. I do not know why we are steering away from this.

Dependency management in C is absolutely awful, that's why "no dependencies" is a "feature"

I have a different experience. I use my Linux distribution's (Arch Linux) package manager.

Re: Third High Severity CVE in Log4j Is Published

#163

Post by nefitty »

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…

My list of languages to practice were Scala and Rust. Maybe I'll do Scala and Go considering this single point.

Re: Third High Severity CVE in Log4j Is Published

#164

Post by yawaramin »

dylan604 wrote: post #31
grafs50 wrote: post #11

Earlier quoted context omitted.

I don't understand what the problem is if you don't use the code. Why does it matter to you if it gets fixed?

I use services that do use that code though, so I am affected when it goes down

Then you should blame the people who provide those services for going down. Not the open source libraries that they chose to use.

Re: Third High Severity CVE in Log4j Is Published

#165

Post by ncmncm »

The most reliable place to find new bugs and security holes is next to others you just found out about.

Bugs come in bunches. If you have fixed just one or two, more lurk right there. And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.

Re: Third High Severity CVE in Log4j Is Published

#166

Post by xxgreg »

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…

There's also ongoing work to build a dependency vulnerability database. This is proposed to be surfaced via a built in `go audit` command.

https://go.googlesource.com/proposal/+/master/design/draft-v...

Re: Third High Severity CVE in Log4j Is Published

#167

Post by ncmncm »

junon wrote: post #105
nitrogen wrote: post #101

Earlier quoted context omitted.

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

Re: Third High Severity CVE in Log4j Is Published

#168

Post by staticassertion »

querulous wrote: post #143
staticassertion wrote: post #126

Earlier quoted context omitted.

I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But there's no patch. What are you doing about it? With log4j you have a brutal combination of: 1. RCE 2. Exposure RCE happens frequently but often attackers don't have an easy time getting to the exploitable code. With log4j it's trivial - every app can be owned. But…

it's definitely time for a language with a capabilities based security model that allows scope to the function/method level, at minimum not just for security either. i can't count the number of times i've traced a performance problem or bug to a piece of code that was doing some io when it didn't need to

Agreed. In a capabilities system you'd see that, for some reason, your logger requires all sorts of absurd capabilities for no reason.

Re: Third High Severity CVE in Log4j Is Published

#169

Post by [deleted] »

junon wrote: post #105
nitrogen wrote: post #101

Earlier quoted context omitted.

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

[deleted]

Re: Third High Severity CVE in Log4j Is Published

#170

Post by ncmncm »

nefitty wrote: post #163
yawaramin wrote: post #136

Earlier quoted context omitted.

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…

My list of languages to practice were Scala and Rust. Maybe I'll do Scala and Go considering this single point.

In other words, you are not actually interested in programming.
Post reply on HN