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

261–270 of 531 posts

Re: Log4j RCE Found

#261

Post by acdha »

dikei wrote: post #215
spullara wrote: post #209

Earlier quoted context omitted.

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

I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.

I think you’re right but also showing where a more secure design could solve it just like we’ve seen for SQL injection. The problem is that the first parameter can either be a format string or data.

If the signature was different so it only used instances of a FormatString class to get dynamic behavior, this problem would be avoided, but I’m sure a lot of people would complain about the extra typing.

What’d be really cool would be if Java supported something like this Rust lifetime hack to let that be implicit where you could disable dynamic functionality for strings created after startup.

https://polyfloyd.net/post/compile-time-prevention-of-sql-in...

Re: Log4j RCE Found

#262

Post by acdha »

sensiblesec wrote: post #259

EDIT: was not clear to me that Lumio has done only the writeup and not the original researchers finding the vulneraility mea culpa Lunasec, you're doing god's work! Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone g…

This was fixed and discussed on GitHub a week ago, so the cat was somewhat out of the proverbial bag.

I would not blame the people who wrote easier to understand blog posts which are going to need circulation to half of the enterprise IT code mills in the world, and note that dang changed this post’s URL from the GitHub issue which is harder to understand.

Re: Log4j RCE Found

#263

Post by sensiblesec »

Jolter wrote: post #260
sensiblesec wrote: post #259

EDIT: was not clear to me that Lumio has done only the writeup and not the original researchers finding the vulneraility mea culpa Lunasec, you're doing god's work! Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone g…

It'd be a bit hard to keep this exploit a secret once the patch was on Github.

While that is definitely a good theoretical argument but in practice it seem to be the case that most of the (non 0day) vulnerabilities that get exploited in the wild are the ones that have solid public exploits, and it does also seem to have effect on how fast it starts to be exploited.

Even if that was true, knowing that a number of large projects are using this lib I'm not sure if it is unreasonable to ask to at least make an attempt to reach out so they can asses their exposure.

Re: Log4j RCE Found

#264

Post by sensiblesec »

acdha wrote: post #262
sensiblesec wrote: post #259

EDIT: was not clear to me that Lumio has done only the writeup and not the original researchers finding the vulneraility mea culpa Lunasec, you're doing god's work! Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone g…

This was fixed and discussed on GitHub a week ago, so the cat was somewhat out of the proverbial bag. I would not blame the people who wrote easier to understand blog posts which are going to need circulation to half of the enterprise IT code mills in the world, and note that dang changed this post’s URL from the GitHub issue which is harder to understand.

That's fair my misunderstanding in that case I'm questioning the people publishing the PoC

Re: Log4j RCE Found

#266

Post by vincnetas »

niea_11 wrote: post #208
vincnetas wrote: post #199

Earlier quoted context omitted.

wow it's like SQL injection but even when using user input as parameter it does not get sanitised. Really curious what was motivation for such behaviour.

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.

Re: Log4j RCE Found

#267

Post by ninkendo »

cozzyd wrote: post #154
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…

I thought you just rely on rsyslog or journald for this stuff...

Right?

Logs are streams, not files. To a first approximation, you should just log to standard out, and let another system take care of sending your output to either a file (with rotation) or logstash, or syslog, or a whatever else is appropriate. To a second approximation (if you’re already using stdout for something else), the thing you’re logging to should still be a file descriptor, but not a file per se. (perhaps a local socket to a logging system like syslog.)

I don’t need everything on my system that logs, to invent its own log output directory, and implement its own log rotation. That’s how you get a mishmash of different places where logs end up living, and they become very difficult to collate or compare, etc.

Re: Log4j RCE Found

#268

Post by tetha »

wielebny wrote: post #145

This is exploitable in applications that use Elastic Stack with logstash as a log processor. I've just been able to reproduce it in an Magento ecommerce with payload inserted into payments details.

This why it is utmost critical to deploy the mitigating fixes to the core log aggregations first. Elasticsearch, Logstash, Graylog probably too. The vector here is even more annoying, you can think of something like:

Unrelated app writes stuff to a logfile. This get's shipped to logstash. The log message was crafted in a way to break the logstash pipeline with an exception (invalid json, grok errors or something)... which get's written to the log of logstash, including parts of the original message.

Or, you can trigger indexing errors in elasticsearch by forcing individual keys in events to have conflicting types (send "banana: 42" first, making it an int, and then send "banana: '42'", making it a string). This can cause ES to dump the field name, and sometimes a value if I recall right, to it's own log.

In both cases, this could potentially compromise a vulnerable log aggregation behind an unaffected service.

Re: Log4j RCE Found

#269

Post by christophilus »

cozzyd wrote: post #154
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…

I thought you just rely on rsyslog or journald for this stuff...

You do. None of the logging libraries I’ve used in the past 5 years even have log rotation as a feature, from what I can tell.

Re: Log4j RCE Found

#270

Post by chrisjc »

vincnetas wrote: post #199
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.

wow it's like SQL injection but even when using user input as parameter it does not get sanitised. Really curious what was motivation for such behaviour.

Yup, log injection is something that I've been hearing a lot about recently, but I really only thought about it being able to affect systems that consume the logs. This approach is pretty ingenious.
Post reply on HN