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

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

301–310 of 531 posts

Re: Log4j RCE Found

#301

Post by mkleczek »

vips7L wrote: post #282
mkleczek wrote: post #214

This is actually worse than log4j. Any code accessing JNDI using URIs from external data is vulnerable. Script injection (aka XSS) at its finest. Looks like a good use case for running under SecurityManager with a restrictive policy. Maybe it is time to reconsider JEP 411?

In practice I’ve never met anyone who actually uses The Security Manager. So it might have been able to stop this with the proper configuration but I doubt anyone would have configured it to do so.

And this is the root problem as that's equivalent to running software as root.

Re: Log4j RCE Found

#302

Post by layer8 »

niea_11 wrote: post #283
vincnetas wrote: post #266

Earlier quoted context omitted.

JNDI lookup in it self is not a problem, problem is that user input is not sanitised and can include templates which can have JNDI lookup in them. I would expect user input with {} template symbols to be escaped and not evaluated.

The method responsible for variable substitution is here [1]. There are other lookup mechanisms, (didn't check them all) but they only retrieve environment/static values (this one [2] for example retrieves kubernetes attributes). I think the jndi one is the only one that load and execute code. Edit : I think my understanding of the docs is incorrect so ignore the next paragraph From the documentation [3], I have the…

> I agree that the input should be sanitized but only if the formatting behavior is a bug and was not intentional.

Non-pattern arguments should not do any substitution, because otherwise developers have to jump through hoops to output strings verbatim. You don’t want "Invalid identifier: '${}'" to be turned into "Invalid identifier: ''" when the actual invalid identifier (e.g. from user input) was the "${…}" syntax. I’m surprised that log4j behaves that way still after two decades.

Re: Log4j RCE Found

#303

Post by jallen_dot_dev »

immibis wrote: post #230
lgrapenthin wrote: post #221

Its just incredible how bloated Log4J is. You'd think a logging library would be rather lightweight, straightforward to configure, no? No, it is one of those efforts that suffer from their underlying problem being so well understood that, apparently, everybody working on it feels compelled to "enrich" it with more options, config layers, adapters, extensions.

Well yes, when you have a project that does 99% of what you need, you add the other 1% to the project instead of starting a whole new project. This is just how all software evolves.

Or you separately implement this feature that only you need. Instead of asking for it to be supported out-of-the-box by this very popular library where it'll operate unbeknownst to everyone else.

Re: Log4j RCE Found

#304

Post by jffry »

philh wrote: post #297
jffry wrote: post #288

Earlier quoted context omitted.

I'm not Requestbin's creator so I don't know. A simple nslookup or curl does work for me, with my system's DNS servers set to Cloudflare (1.1.1.1) or Google (8.8.8.8) It looks like Vodafone (I assume this is your ISP) DNS servers aren't properly resolving the name for some reason. You could try bypassing it with dig, and directly ask a different DNS server to resolve it: dig @1.1.1.1 A whatever.a54c4d391bad1b48ebc3.d…

Thanks! Yeah, `dig` with no DNS gives me a SERVFAIL but `dig @1.1.1.1` works. My ISP isn't Vodafone directly (I take it you think that because 83.146.21.6 belongs to them?) but might be a Vodafone reseller or something.

Yeah, I assumed since you were querying their DNS that you were a client, but makes sense it might be repackaged to other ISPs.

Re: Log4j RCE Found

#305

Post by ironmagma »

michaelt wrote: post #242
kelnos wrote: post #187

On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should n…

> A logging framework's job is to ship strings to stdout or files or something. I've seen people (including here on HN) dismiss libraries as "abandoned" when they went a year without a release. The software industry will never get bug-free, feature-complete software so long as we're selecting for the opposite.

Code is alive and there’s typically always something to do: adding tests, removing bugs, or simply paying back technical debt. If you go a full year without any releasable changes, chances are the project has been abandoned.

Re: Log4j RCE Found

#306

Post by svick »

michaelt wrote: post #242
kelnos wrote: post #187

On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should n…

> A logging framework's job is to ship strings to stdout or files or something. I've seen people (including here on HN) dismiss libraries as "abandoned" when they went a year without a release. The software industry will never get bug-free, feature-complete software so long as we're selecting for the opposite.

How do you differentiate between "actually abandoned and probably dangerous" and "actively maintained, but updated only very rarely, because there's nothing left to do"?

Re: Log4j RCE Found

#307

Post by whizzter »

JanecekPetr wrote: post #200
kelnos wrote: post #187

On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should n…

No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.

Even if 2.x is the main culprit right now some one twitter started testing and it seems that 1.x might be exploitable as well.

Re: Log4j RCE Found

#309

Post by jameshart »

jhugo wrote: post #289
Pxtl wrote: post #285

Earlier quoted context omitted.

If "debug.log(stuffIGotFromPeer)" is dangerous, then the problem is with debug.log and not my code. Safe logging is not too high of a bar.

The point is that the first argument is the format string. debug.log("{}", stuffIGotFromPeer) should generally be safe (this bug is an example of when it isn't, though)

The fact that the first argument is interpreted as a format string even when you aren't supplying format arguments is a violation of 'principle of least surprise'. The availability of format parameters that can access environment data - let alone remotely loaded code - is a feature most people won't discover unless they go looking for it.

Re: Log4j RCE Found

#310

Post by Spivak »

ninkendo wrote: post #245
dikei wrote: post #215

Earlier quoted context omitted.

I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.

Eliding the string interpolation doesn’t necessarily have to be a feature of the logging library, the language itself can have affordances for this. For example in swift, log.debug("my name is \(expensiveCalculate(name))") doesn’t have to evaluate “expensiveCalculate(name)” unless the logger actually opts to instantiate the string (which it can skip if say, debug logging is disabled.) This is because Swift’s string i…

While nice this feature doesn't really exist in other programming languages that don't involve the caller unergonomically wrapping the parameter to defer evaluation.
Post reply on HN