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

121–130 of 531 posts

Re: Log4j RCE Found

#121

Post by keyle »

markburns wrote: post #117
keyle wrote: post #95

Earlier quoted context omitted.

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.

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?

Agreed. It's all nice to have. People want push.

You can eat your pizza slice whichever way you want.

Arguably this would be useful for critical events.

Re: Log4j RCE Found

#122

Post by makeitdouble »

markburns wrote: post #117
keyle wrote: post #95

Earlier quoted context omitted.

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.

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?

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.

Re: Log4j RCE Found

#124

Post by shepherdjerred »

TheDong wrote: post #116
hawk_ wrote: post #110

Earlier quoted context omitted.

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

> Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?

I did a lot when I younger and didn't realize that it was a bad practice.

Re: Log4j RCE Found

#125

Post by jcims »

Technically it's a format string vulnerability that causes a server-side request forgery that can be abused to execute code on the remote system.

I wonder of any bug bounties would give you a chain bonus for this one lol

Re: Log4j RCE Found

#126

Post by Thorrez »

makeitdouble wrote: post #122
markburns wrote: post #117

Earlier quoted context omitted.

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?

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.

Re: Log4j RCE Found

#127

Post by creatonez »

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 protect themselves. 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.

Re: Log4j RCE Found

#128

Post by ianlevesque »

natanbc wrote: post #99
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)

The RCE works with both ways, start nc (nc -lp 1234) and run this org.apache.logging.log4j.LogManager.getLogger("whatever").error("not safe {}", "${jndi:ldap://127.0.0.1:1234/abc}")

Well that’s just appalling.

Re: Log4j RCE Found

#129

Post by Thorrez »

BeefWellington wrote: post #38
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…

Best guess: Resolving some kind of entity name to a username for some weird auditing requirement few people have ever heard of. It's the kind of feature I've seen in some software in the past. That's just a guess though.

The question isn't about the purpose of the feature. The question is why it's implemented with string parsing.

In C, it's unsafe to do

    printf(string_variable);
because variable will get parsed as a format string. The way to solve the vulnerability is

    printf("%s", string_variable);
Is that the same in Java logging libraries? Is it well-known that the logged value will be parsed? What's the safe way to log a value in Java exactly, knowing that nothing will parse that value?

Re: Log4j RCE Found

#130

Post by mirashii »

hawk_ wrote: post #110
jrockway wrote: post #76

So a lot of people sound mad that the logging library is parsing the inputs, and maybe they should be, but the truly paranoid should also be aware that your terminal also parses every byte given to it (to find in-band signalling for colors, window titles, where the cursor should be, etc.). This means that if a malicious user can control log lines, they can also hide stuff if you're looking at the logs in a terminal.…

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

screen had a recent RCE of the sort. https://nvd.nist.gov/vuln/detail/CVE-2021-26937
Post reply on HN