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

131–140 of 531 posts

Re: Log4j RCE Found

#131

Post by asddubs »

shepherdjerred wrote: post #101
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…

I disagree strongly with this. You're better off learning the de-facto libraries of your language. Your employer, or any production application you're going to work on is probably going to use one of these libraries. I learned the most common Java libraries when writing personal projects -- Lombok, log4j, Guava, Gson, Jackson, Netty, etc. I had a significantly gentler learning curve at my first job. We used these com…

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

Re: Log4j RCE Found

#132

Post by throwaway81523 »

usrusr wrote: post #37
throwaway81523 wrote: post #18

The twitter thread says something about serialized objects containing malicious code. I didn't realize Java had that. Can someone explain in more detail?

Java deserialization won't directly pull executable code from incoming bytes, but without deliberate countermeasures the deserialization runtime will happily try to create new instances of any class visible in the classpath configuration of the VM if the incoming bytes ask nicely. And many of the classes that might be present come with static code that will run once before the first class instance is created, setting…

Ah thanks, that sounds like pickling in Python. It took forever for them to understand that unpickling untrested data was a security hole.

Re: Log4j RCE Found

#133

Post by bullen »

creatonez wrote: post #127

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…

So is this fixed in 1.18?

Re: Log4j RCE Found

#135

Post by Merad »

keyle wrote: post #95
testplzignore wrote: post #20

I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?

So if you have a null pointer exception or something similar in production, you want to send that information to a remote host or alert system to be looked at urgently.

Encoding that in the log message itself still seems a bit crazy. I’m not familiar with log4j, but the .Net logging libraries I do know (NLog and Serilog) completely separate writing log events from processing (writing, sending, whatever) the events.

Re: Log4j RCE Found

#136

Post by tmd83 »

Thorrez wrote: post #126
makeitdouble wrote: post #122

Earlier quoted context omitted.

This is the obvious solution now. I think 20 years ago it would have been slammed as overkill to have a separate process just to send logs. Even now actually, there is a flurry of libs/gems to send events/logs/analytics to a remote server (Datadog, NewRelic, Slack…)from the application itself. It’s usually not directly coupled with the logger, but it’s not far.

Putting a feature in a logger to send logs remote is one thing. Putting a special syntax into the log message itself that gets parsed to decide where to send it is much weirder.

Exactly and this being enabled by default seems specially more unusual. I can understand config being parseable even though log configurer directly pulling a remote config is a stretch specially by default. But I don't think it's unlikely that people would by default assume that their log message would be parsed that way and as someone said it even works if that's used as a user input using {} instead of +.

Re: Log4j RCE Found

#137

Post by joedj »

shawnz wrote: post #93
ianlevesque wrote: post #46

Earlier quoted context omitted.

The method that they're exploiting is akin to printf("whoops this is a format string"). The right way to handle user input in one of these is log.error("here's my user-provided input: {}", userInput) rather than log.error(userInput)

What if you are using SLF4J as a front-end to log4j, does it escape these special strings before passing them to the logging system?

No.

Re: Log4j RCE Found

#138

Post by cjensen »

bullen wrote: post #133
creatonez wrote: post #127

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…

So is this fixed in 1.18?

It's in the 1.18.1 release candidate 3 which is scheduled to be fully released tomorrow.

Re: Log4j RCE Found

#139

Post by creatonez »

bullen wrote: post #133
creatonez wrote: post #127

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…

So is this fixed in 1.18?

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

Re: Log4j RCE Found

#140

Post by fnord77 »

always always always keep use of 3rd party java libraries to a minimum. While not necessarily useful in this case, I often see answers on stackoverflow saying "oh just use this apache commons or guava library" when there's a perfectly sound and easy way of just doing it in java. Makes me want to scream
Post reply on HN