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

181–190 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#181

Post by junon »

ncmncm wrote: post #176
junon wrote: post #174

Earlier quoted context omitted.

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.

I addressed the point about symbol tables, and that's assuming the vulnerable code was pulled in via an external dependency or exported directly (flat function/subroutine) from an .SO.

That also assumes that the binary wasn't linked statically - in which case, there are no external symbols to even look for.

Lastly, please stop calling someone educating you "BS".

Re: Third High Severity CVE in Log4j Is Published

#182

Post by jacquesc »

kbenson wrote: post #110
jacquesc wrote: post #28

Earlier quoted context omitted.

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

You're right, it was a bad take based on an old, strangely emotional experience I remember. Apologies

Re: Third High Severity CVE in Log4j Is Published

#183

Post by ncmncm »

symlinkk wrote: post #89
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…

Giving something away for free and then turning around and guilting people into paying for it is wrong.

That seems to be an opinion. Opinions vary. Mine does.

Re: Third High Severity CVE in Log4j Is Published

#184

Post by a-dub »

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

Earlier quoted context omitted.

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

sort of raises an interesting question. rust has memory safety, but it's still possible to write code that "isn't up to code." i wonder if maybe rust+1 will be the first language/environment/ecosystem that has application development security principles built in. that would mean, like, not just taking the compiler forward in terms of memory safety, but also codifying a set of principles, enforcing those that can be statically checked in the compiler with the compiler, and aggressive curation for a singular library archive (similar to how some internet library archives require unit tests or style, etc).

Re: Third High Severity CVE in Log4j Is Published

#185

Post by aidenn0 »

staticassertion wrote: post #150
twunde wrote: post #145

Earlier quoted context omitted.

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or n…

Yes, some organizations have so much technical debt that any security work is going to take extraordinarily large amounts of work. That's a bummer, but I suspect many on HN can in fact build software that isn't total garbage.

Doing it right sometimes pays off in the long run, but cutting corners always pays off now.

Re: Third High Severity CVE in Log4j Is Published

#186

Post by ncmncm »

layer8 wrote: post #146
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.

They are generally high quality and implemented by cryptographers. Parts of the implementations are certified by NIST. Log4j is not part of the JDK and is an open source project with only few regular contributors. There is really no reason to infer any correlation to other parts of the Java ecosystem.

"Certified by NIST" absolves people of responsibility without actually indicating any property of the code certified.

Re: Third High Severity CVE in Log4j Is Published

#187

Post by vmception »

diob wrote: post #99
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…

So happy to see this as the top comment. We need way more positivity in tech.

I thought it was satire, but I guess that says more about me

Re: Third High Severity CVE in Log4j Is Published

#188

Post by ncmncm »

junon wrote: post #181
ncmncm wrote: post #176

Earlier quoted context omitted.

You do not need internal symbols. All the public entry points are spelled out exactly by name, and all the external symbol dependencies.

I addressed the point about symbol tables, and that's assuming the vulnerable code was pulled in via an external dependency or exported directly (flat function/subroutine) from an .SO. That also assumes that the binary wasn't linked statically - in which case, there are no external symbols to even look for. Lastly, please stop calling someone educating you "BS".

You instead wholly failed to address the point about symbol tables.

Re: Third High Severity CVE in Log4j Is Published

#189

Post by pclmulqdq »

jeffbee wrote: post #22
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…

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.

The unfortunate thing about scratch rewrites is that they are not a good business. Open Source has conditioned people to think that libraries should be free. It's not clear to me that the alternative where libraries are obscenely expensive (like in the hardware world, where a hash table is a $100k investment) is any better. Nobody has ever built a successful company charging between $0 and $10,000 for a library. That is just how people see things, and unfortunately it is extremely hard to change.

Re: Third High Severity CVE in Log4j Is Published

#190

Post by junon »

ncmncm wrote: post #188
junon wrote: post #181

Earlier quoted context omitted.

I addressed the point about symbol tables, and that's assuming the vulnerable code was pulled in via an external dependency or exported directly (flat function/subroutine) from an .SO. That also assumes that the binary wasn't linked statically - in which case, there are no external symbols to even look for. Lastly, please stop calling someone educating you "BS".

You instead wholly failed to address the point about symbol tables.

Symbol table patching doesn't do anything if the functionality is internal... Do you know how programs are linked?
Post reply on HN