Live data from Hacker News

Log4j RCE Found

lunasec.io

351–360 of 531 posts

Re: Log4j RCE Found

#351

This exploit is quite severe on Minecraft Java Edition. Anyone can send a chat message which exploits everyone on the server and the server itself, because every chat message is logged. It's been quite a rollercoaster over the past few hours, working out the details of how to protect members of servers, and informing players (many of whom uses modded clients that don't receive the automatic Mojang patches) of how to…

> Anyone can send a chat message which exploits everyone on the server and the server itself, because every chat message is logged. ... Some of the major servers like 2b2t and Mineplex have shut down, and larger servers that haven't shut down yet are pure chaos right now. Why does this behavior remind me of the old "dcc send start keylogger 0 0 0" exploit of IRC some fifteen years ago?

For context:

> DCC SEND STARTKEYLOGGER 0 0 0 is a way to make half of the people in an irc channel disconnect. This originated when a virus used the phrase to start the key logger it came with. If you had Norton internet security, it would terminate the connection. Some older routers also crash when receiving a malformed DCC request, which DCC SEND STARTKEYLOGGER 0 0 0 is.

That's pretty wild, it was caused by hypervigilant security software apparently

Re: Log4j RCE Found

#352

Earlier quoted context omitted.

This is just stupid. Logging should not do any side effects except writing to the log.

I agree. It reminds me a lot of XXE attacks on XML. You wouldn't expect parsing an XML file to open arbitrary network connections, would you? The spec says an XML parser should do that. A lot of parsers used to have that feature turned on by default, although I think by now most folks have wised up.

For sure. Also related were all the deserialization attacks on various libraries that supported it in Java, Ruby and Python.

Re: Log4j RCE Found

#353

Earlier quoted context omitted.

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…

The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above. https://stackoverflow.com/a/42802636/270317

Confirming that this is correct: the {nolookups} option was added in v2.7 as a result of LOG4J2-905, so this mitigation is not available on versions prior to 2.7. Corroborating sources:

[4] https://issues.apache.org/jira/browse/LOG4J2-905

[5] https://logging.apache.org/log4j/2.x/changes-report.html#a2....

Checking on the viability of the classloading-based mitigations now across the versions. It seems that LOG4J-1051 was raised [6] to make the class instantiator more tolerant of missing classes, and the resulting changes were released in v2.4 and v2.7. Will check how earlier versions behave in this case.

[6] https://issues.apache.org/jira/browse/LOG4J2-1051

Re: Log4j RCE Found

#354

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.

According to the article, Steam was directly affected by this vulnerability. But I'd guess that's a problem on their backend and not on the Steam client.

Re: Log4j RCE Found

#355
post #90
post #67

Earlier quoted context omitted.

Get yer pointin' finger ready: https://github.com/apache/logging-log4j2/blame/master/log4j-...

People should really have known better than to use (unexpected!) in-band signalling. Even 8 years ago.

I’m still arguing with people about using the built in url APIs instead of string concatenation.

A person is smart, but people are dumb.

Re: Log4j RCE Found

#356

Earlier quoted context omitted.

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…

The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above. https://stackoverflow.com/a/42802636/270317

[deleted]

Re: Log4j RCE Found

#357

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.

Maybe, but still this seems as vanity feature added because "It would be really convenient"... this wasn't something what was needed, but something what was added to make life of maybe 0.1% of users little bit easier. My guess is that most of users of Log4J2 don't even know that it is able to do such magic, and would be horrified knowing it. IMHO Log library should log, not do some magic stuff.

Re: Log4j RCE Found

#358

Earlier quoted context omitted.

Seems like you're disagreeing on the basis of personal development rather than whether it makes sense for any given project. I think at that point it depends on whether you're primarily coding to learn or to make software

By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?

Because it apparently is absurdly complicated for a task I can solve with 'println'.

Re: Log4j RCE Found

#359
post #339
post #324

A LSM in enforcing mode (such as SELinux or Tomoyo) on a Linux system would prevent this. I configure and run tomoyo on all my Internet facing servers. https://tomoyo.osdn.jp/

Or just a firewall rule to block outgoing connections. Basic security precautions prevent this attack against servers.

A firewall rule to block DNS requests? Or one to block LDAP requests?

Re: Log4j RCE Found

#360
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.

> when they went a year without a release.

Cause these libraries depend on other libraries that are probably extremely out of date at that point and have their own security vulnerabilities.

An example of a project that hasn't been dismissed as "abandoned", is https://github.com/patrickmn/go-cache because it explicitly doesnt have dependencies.

So yeah, if you have a semi-complex library, a year without a release is abandoned.

Post reply on HN