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

281–290 of 531 posts

Re: Log4j RCE Found

#281

Post by Nursie »

nostoc wrote: post #85
jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

> just a wrapper around printf which adds a timestamp and a log-level That's a pretty naive view of what's needed in an enterprise logging solution. logging to files, separate logging, remote logging, log rotation, logging 3rd party code... Of course if you're simply sending lines to the terminal in a simple program you don't need log4j. But once you scale, you'd be spending 3 weeks implementing what you get for free…

> Of course if you're simply sending lines to the terminal in a simple program you don't need log4j

That's the issue though isn't it, a lot of people don't need those features, just the prettifying and formatting, levels selectable by classpath and basic bits. log4j is great at these things and has become the standard for these things as much as anything else.

And with a lot of stuff being done by microservices, serverless functions etc, you have other pieces that pick up the logs and do all the smart processing. Especially 'at scale'.

So a capable but simple logging library is probably a good option. Perhaps log4j could split.

Re: Log4j RCE Found

#282

Post by vips7L »

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.

Re: Log4j RCE Found

#283

Post by niea_11 »

vincnetas wrote: post #266
niea_11 wrote: post #208

Earlier quoted context omitted.

Here is the jira ticket that introduced the behaviour (jndi lookup) : https://issues.apache.org/jira/browse/LOG4J2-313

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 impression that these variables should be evaluated only when loading the pattern layout configuration. But in reality they are also evaluated when formatting the final log message (log.info(...)).

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

One possible explanation for the current situation, is that developers assumed that all lookup mechanism will retrieve only static values (env variables for example).

And then another dev introduced the jndi lookup which execute code, but no one noticed the impact on the already existing behavior (evaluation variable when formatting the final msg).

Edit

1: https://github.com/apache/logging-log4j2/blob/9df31f73b62ba2...

2: https://github.com/apache/logging-log4j2/blob/c2b07e37995004...

3: https://logging.apache.org/log4j/2.x/manual/lookups.html

Re: Log4j RCE Found

#284

Post by Nursie »

GrayShade wrote: post #273
kaba0 wrote: post #222

Earlier quoted context omitted.

How is Java uncannily good at those? Do you have other examples?

I'm not the grandparent, but there's been a slew of deserialization-related vulnerabilities in Java and .NET libraries where user input is used to instantiate arbitrary classes and invoke methods on them.

Lot of them in jackson in recent years, IIRC.

Re: Log4j RCE Found

#285

Post by Pxtl »

janekm wrote: post #272
brabel wrote: post #175

Earlier quoted context omitted.

These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.

Though of course "debug.log(stuffIGotFromPeer)" is also very common (and as you point out should always be avoided).

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.

Re: Log4j RCE Found

#287

Post by smolder »

maruhoi wrote: post #217

How might this affect me on Steam?

This is an odd question, but if you're saying you downloaded a java based game that suffers this RCE, I don't think Steam does a single thing to protect you.

Re: Log4j RCE Found

#288

Post by jffry »

philh wrote: post #195
jffry wrote: post #77

Earlier quoted context omitted.

Looks like https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in

I don't really know what's going on here, so to clarify... it gives "simple checking example" nslookup mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net but when I run that in my terminal I get the response ;; Got SERVFAIL reply from 83.146.21.6, trying next server Server: 212.158.248.6 Address: 212.158.248.6#53 ** server can't find mydatahere.a54c4d391bad1b48ebc3.d.requestbin.net: SERVFAIL And nothing shows up in "re…

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

Re: Log4j RCE Found

#289

Post by jhugo »

Pxtl wrote: post #285
janekm wrote: post #272

Earlier quoted context omitted.

Though of course "debug.log(stuffIGotFromPeer)" is also very common (and as you point out should always be avoided).

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)
Post reply on HN