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

181–190 of 531 posts

Re: Log4j RCE Found

#181

Post by brabel »

erk__ wrote: post #176
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.

According to a comment here it does https://news.ycombinator.com/item?id=29506397

Confirmed myself here... yes, it does :(

Re: Log4j RCE Found

#182

Post by chii »

tcoff91 wrote: post #150
chii wrote: post #29

Earlier quoted context omitted.

Java has the ability to serialize a class, send it over the network, and deserialize it back into a usable class. This mechanism is quite flexible, and allows the class itself to control some aspect of it's own serialization (such as code to run post-serialization, as a form of initialiation, somewhat similar to a constructor). So if you load a class from an unknown source (such as this exploit's example), you are ba…

This is such a massive footgun wow...

it's not any different from eval() tbh - the onus is on the programmer to not trust input. The problem is when libraries do unexpected things, like the log4j RCE.

Re: Log4j RCE Found

#183

Post by danmur »

brabel wrote: post #175
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…

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.

That's very surprising.

Re: Log4j RCE Found

#184

Post by jsiepkes »

What adds to the confusion is that log4j2 rebrands itself as log4j. For example the Log4j2 artifact name is: `org.apache.logging.log4j:log4j-api` but it is actually Log4j2, not the original Log4j.

There is plenty of stuff out there that still uses Log4j 1.7, 1.8, etc. I assume this is all about Log4j2? And not about the original Log4j? Or is the original Log4j also affected?

Re: Log4j RCE Found

#185

Post by spc476 »

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.

syslog() has been around for a lot longer than 20 years, and that's a function that logs to a separate process. What's so bad about syslog that people need to invent new logging systems?

Re: Log4j RCE Found

#186

Post by dijit »

arpa wrote: post #171
shepherdjerred wrote: post #124

Earlier quoted context omitted.

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

I've been on Linux since 2000s and still maintain the view that real men log in as root on tty1. It's ironman mode, and pure joy of *nix as it was meant to be experienced. You filthy casual. /s

UNIX was designed as a multi-user system. So the joy of UNIX is using many users on one machine.

Which, incidentally, is the most pleasurable way of experiencing UNIX and UNIX-likes. (Shellboxen)

Re: Log4j RCE Found

#187

Post by kelnos »

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 not be this complicated, flexible, whatever you want to call it. The idea that a logging framework (!) could even have an RCE makes me want to scream... the feature set that leads us to that even being possible just weeps "overengineered".

Re: Log4j RCE Found

#188

Post by raesene9 »

jsiepkes wrote: post #184

What adds to the confusion is that log4j2 rebrands itself as log4j. For example the Log4j2 artifact name is: `org.apache.logging.log4j:log4j-api` but it is actually Log4j2, not the original Log4j. There is plenty of stuff out there that still uses Log4j 1.7, 1.8, etc. I assume this is all about Log4j2? And not about the original Log4j? Or is the original Log4j also affected?

There are indications (https://twitter.com/dlitchfield/status/1469199750452822017?s...) that log4j1 can be affected too...

Re: Log4j RCE Found

#189

Post by dijit »

vbezhenar wrote: post #143
nostoc wrote: post #85

Earlier quoted context omitted.

> 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…

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.

Re: Log4j RCE Found

#190

Post by znep »

Fabricio20 wrote: post #6
brasetvik wrote: post #5

Are there any mitigations in recent JVMs? I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload. See also: - https://github.com/tangxiaofeng7/apache-log4j-poc - https://github.com/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.

Yes, more specifically after Java 8u191 you need to flag the client with: -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=true While RCE is not possible without these flags, you will still get pingback, in minecraft's example, allowing you to get the IP of everyone connected.

While the specific exploit may not be possible in 8u191 and later, I am not convinced they are safe from all RCEs using this vulnerability. It does make it harder to exploit, and hit or miss depending on what is available in the classpath.

See https://www.veracode.com/blog/research/exploiting-jndi-injec...

Post reply on HN