Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

231–240 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#231

Post by est »

thomond wrote: post #176
nyanpasu64 wrote: post #43

> Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default. I think this should've happened from the beginning.

It really re-enforces the idea of sane defaults. How many end users of a logging framework would even need JNDI functionality?

> How many end users of a logging framework would even need JNDI functionality

Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?

Re: Log4Shell update: second Log4j vulnerability published

#232

Post by qalmakka »

eMGm4D0zgUAVXc7 wrote: post #178
runeks wrote: post #170

Earlier quoted context omitted.

Agreed. Loading and running arbitrary Java byte code should not be possible from user code. Only the runtime system should have this ability.

How do you want to write software which supports plugins then? Force the user to restart everything if they need a plugin? Or do you want to force developers to only ever write monolithic software now?

It's simple, you simply implement some sort of code signing feature, or you only let people run arbitrary code in a sandbox or some sort of similarly limited environment. Letting people load code from a remote source into the same address space of a running program containing potentially sensitive data is intrinsically bad.

In fairness, Java has had capabilities to only let signed code run since its early days (it was fundamental for stuff like Applets or RMI), but like the rest of Java the whole specification is over engineered and quite complicate so nobody bothers with it. There are just too many old features lying around in the JRE that should be off by default. Like they shouldn't be possible to use unless you explicitly configure your environment to enable them. 99.999% of apps do not need and will never care about JNDI, and having it just lying around doing nothing just pointlessly increases the surface attack of your application for no good reason.

Re: Log4Shell update: second Log4j vulnerability published

#233

Post by jacquesm »

dylan604 wrote: post #226
toyg wrote: post #210

Earlier quoted context omitted.

I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right? (yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...) (I'm not condoning this, just saying that it can look sensible…

No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up…

Even for a honeypot?

Re: Log4Shell update: second Log4j vulnerability published

#234

Post by qalmakka »

eternalban wrote: post #212
qalmakka wrote: post #162

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

The "poor idea" in the 90s was that developers were going to read specifications. Sun Micro specially suffered from this. Thus the "clusterfuck" of JRE, for example, offered something called a Security Manager, but it was "insane" to think commodity IT developers would use it ("wat's dat!?")

The fact that people don't read or use your specifications should ring a bell in someone's ears. I shouldn't have to care about the Security Manager unless I'm writing an app that might do stuff that covers its use cases. It makes no sense that JNDI is usable and loadable by Minecraft, it's just a dangerous API.

Re: Log4Shell update: second Log4j vulnerability published

#235

Post by justin_oaks »

sporkland wrote: post #171
freeqaz wrote: post #140

Earlier quoted context omitted.

We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell) I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep! Good night, y'all. :) 0: https://www.lunasec.io/docs/blog/log4she…

I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary. Leading to more risk over time.

It may not make any sense, but how does it lead to more risk? If you add a Java dependency but nothing calls it, then you're not vulnerable.

Re: Log4Shell update: second Log4j vulnerability published

#236

Post by gunnarmorling »

freeqaz wrote: post #13

We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell. ${jndi:ldap://hotpatch.log4shell.com:1389/a} If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly. Source code is on GitHub here[0][1] if you want to host it yourself. (This work is based on Logout…

I'm sure they mean well, but I'd highly recommend to every user to be very careful about using services like this.

Do you know whether you can trust them? Is their operations mature enough for handling the attacks they are guaranteed to receive? After all, a system receiving requests by folks suspecting they are vulnerable, makes a highly attractive target itself. In fact, I wouldn't be surprised if we see services of this kind provided by malicious actors.

Really, people should just update, or only use offline tools for analysis and mitigation like [1] which they can audit and run locally.

[1] https://github.com/jerrinot/log4shell-ldap/

Re: Log4Shell update: second Log4j vulnerability published

#237

Post by GrizzlyMcGee »

sporkland wrote: post #171
freeqaz wrote: post #140

Earlier quoted context omitted.

We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell) I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep! Good night, y'all. :) 0: https://www.lunasec.io/docs/blog/log4she…

I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary. Leading to more risk over time.

It sounds better to say "we are patched for the vulnerability" instead of "the vulnerability does not affect us." The ladder leaves a level of uncertainty. Not saying I agree with this methodology.

Re: Log4Shell update: second Log4j vulnerability published

#238

Post by hamburglar »

jatone wrote: post #215
shakna wrote: post #169

Earlier quoted context omitted.

In an org that named their servers after planets, we turned off "Mars" (which was actually completely and utterly undocumented) and discovered it was the bridge between the intranet and the internet. However, upon turning it back on... Nothing came up again. There were no logs to try and work out which processes needed to launch for it to do its job, causing several days of website downtime (not a simple website - do…

future reference: next time just firewall the network and see what blows up rofl.

A bit of network analysis to identify services that are being called before turning things off would probably be wise, too.
Post reply on HN