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

371–380 of 531 posts

Re: Log4j RCE Found

#371

Post by tetha »

ginko wrote: post #193
creatonez wrote: post #139

Earlier quoted context omitted.

The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144

This will be a pain for MC speedrunning where older versions are still quite popular AFAIK.

Wouldn't this be a breakthrough for the any% glitched category? You could just load + inject a class that makes you win instantly with only one chat message! speedstrat ftw. :)

Re: Log4j RCE Found

#372

Post by scottlamb »

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.

The behavior is fundamentally wrong as explained by layer8's comment and in the blog post jcheng linked. Apparently it was intentional, and to me that's a million times worse than if it were a bug that could just be fixed.

log4j is unsuitable for use in a way that many many people are suddenly discovering today. The log4j developers need to rethink this, and even if they do, log4j's users should still strongly consider switching to something else. Otherwise they need to audit the whole codebase for other surprising, broken, insecure design decisions not only in its present state but also on each update. I don't see how it's possible to trust the log4j developers' design sensibilities after this.

Re: Log4j RCE Found

#373

Post by johnthuss »

log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.

Re: Log4j RCE Found

#375

Post by rank0 »

I’m amazed at the reaction here. Lots of comments ITT about how this library is horrible and logging should be a solved problem from a security perspective. Similar commentary was here recently regarding some unsafe docker default.

Developers always want abstractions to make programming easier, but they never consider the cost of using those abstractions. It’s so convenient to place all the burden on library authors but you’re the one logging client supplied input in the first place!

Put a regex whitelist on your inputs wherever there’s a trust boundary. How come devs should never have to consider security but FOSS package maintainers do?

Re: Log4j RCE Found

#376

Post by scottlamb »

throw_nbvc1234 wrote: post #87
BeefWellington wrote: post #25

Earlier quoted context omitted.

> I don't get what the point of this feature even is. This is basically the response to every type of vulnerability that is based on some spec nobody's read. Same deal with XML entity parsing. Why should it make web requests, FTP requests, etc.? At some point someone had it as a requirement and everyone else gets to live with it.

Which is why they removed the functionality in the latest version (per comments below) right?

There are two bizarre design decisions that combined into this stunning security vulnerability: the automatic trust-the-world code execution (on by default) and the recursive parameter expansion (always on). They flipped the default on the former. They haven't done anything about the latter, AFAIK. I wonder if they will.

Re: Log4j RCE Found

#377

Post by coredog64 »

dijit wrote: post #189
vbezhenar wrote: post #143

Earlier quoted context omitted.

IMO enterprise logging solution should write logs to file and rotate files. The rest should be done by a separate services like Loki or Logstash.

Arguably log rotation should be handled outside of the application with logrotate or filebeat.

Please not filebeat. For a few months I had this recurring problem where an app was logging way too much stuff. Filebeat dutifully accepted it and then created ghost files as a buffer which then filled up the disk and crashed the app.

Depending on the velocity at which the log barf was being produced, we sometimes had a short window in which we could manually (!) log in via SSH (!) and restart filebeat to force it to close the open file handles at the cost of losing everything being buffered locally (!).

Re: Log4j RCE Found

#378

Post by coredog64 »

staticassertion wrote: post #358
shepherdjerred wrote: post #147

Earlier quoted context omitted.

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'.

Java since 5 has included it’s own logging class. It doesn’t have as many features as log4j, but it also doesn’t load classes via JNDI.

Re: Log4j RCE Found

#379

Post by mtnygard »

immibis wrote: post #232
spuz wrote: post #36

Earlier quoted context omitted.

What benign purpose does this feature serve and why does it have to be implemented by parsing the input string? Does the input string get modified before being written into the log? I'll ask again because the information presented so far both in this thread on GitHub and on Twitter has been very lacking: is it necessary to return the input string back to the attacker in the response to their request in order for them…

To my knowledge JNDI is a monitoring interface allowing you to get various system values like the number of threads, heap size, process ID, etc. Somehow it's capable of being connected to LDAP. It sounds like a classic X-to-Y-to-Z problem. Someone connected X to Y thinking Y was pretty safe even with untrusted input, not knowing it would ever proxy to Z (probably, everything you can do with JNDI on a local machine is…

Too many acronyms. :-)

JNDI was the "Java Naming and Directory Interface", part of the suite of CORBA-like Java-only distributed object tooling.

My guess is that the "lookups" feature in log4j assumed that all URL protocols were "http:" or "https:" and didn't account for either the full set of built-in protocol handlers or the fact that an application can register additional protocol handlers.

Re: Log4j RCE Found

#380

Post by gkop »

spullara wrote: post #209
lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

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

Would you be ok with logging also checking the contents of what is passed in for sensitive data that should not be logged? (I do this and am curious if there’s a better pattern, to provide defense in depth against mistakenly logging eg secrets)
Post reply on HN