Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j 2.15.0 – Previously suggested mitigations may not be enough

isc.sans.edu

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#71

Post by blueplanet200 »

tie_ wrote: post #43
archi42 wrote: post #26

In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper…

Please stop suggesting that SQL Injections are a sanitization problem. They are a problem of escaping in the application constructing the query, not a problem with whatever the user has typed in. The log4j vulnerability shares some common traits, but it's completely different at the core. It's not a problem of sanitization, and I'd argue it's not a problem of escaping either (though escaping could fix it). It's a pro…

> They are a problem of escaping in the application constructing the query

This is a form of sanitization.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#74

Post by tgflynn »

oasisbob wrote: post #64
tgflynn wrote: post #56

Earlier quoted context omitted.

Are you saying that log4j is also used for analyzing logs that have already been generated ? My understanding was that it was intended for use inside an application for generating log messages and processing them before they are sent out to a file or syslog.

I had the same thought. However, I think it's a more generic attack. If you can persist or inject the jdni strings, there's a chance they will be emitted by another component which analyzes the logs and has a log4j dependency elsewhere in the stack. I've heard people talk about this problem with analyzing windows event logs using Java-based software.

That's interesting. It seems a bit weird that a log analyzer would need to do additional logging, but maybe that's the case in larger systems. I wonder if using log4j as a tool for log analysis as opposed to generation might be a shadow use case of the library. You could have an app that parses log files, converts them to Event objects and then processes that event stream through log4j. I have no idea whether that would be terribly useful and is actually being done by anyone but I guess that's one scenario where these CVE's could cause delayed effects.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#75

Post by kzrdude »

guidedlight wrote: post #9

This vulnerability will likely turn out to follow the trajectory of the Meltdown and Spectre vulnerabilities from...(checks google)... 2018. I speculate will be a cluster of newly discovered vulnerabilities that follow a similar pattern, possibility across a number of familiar Java libraries.

What they have in common with spectre is that: Suddenly it was realized that the design was all wrong. What was thought of as a feature, was a giant vulnerability.

However, log4j seems to be adjusting their design rather quickly, so they should be out of it rather fast.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#76

Post by michaelt »

NtGuy25 wrote: post #60
archi42 wrote: post #26

In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper…

This is actually literally a problem call SSTI, which is REALLY common. It's better to use the correct term instead of SQL injection.

Maybe - but if you don't know what QWER is and I explain that "QWER is just like ASDF" but you don't know what ASDF is either, I haven't really clarified anything for you.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#77

Post by archi42 »

twic wrote: post #51
tie_ wrote: post #43

Earlier quoted context omitted.

Please stop suggesting that SQL Injections are a sanitization problem. They are a problem of escaping in the application constructing the query, not a problem with whatever the user has typed in. The log4j vulnerability shares some common traits, but it's completely different at the core. It's not a problem of sanitization, and I'd argue it's not a problem of escaping either (though escaping could fix it). It's a pro…

Part of the problem is (AIUI) that expansion of ${} type constructs is carried out after parameters are inserted into the log message's format string. I don't believe the use case requires that, i think it was just easier to implement. If that expansion was done on the format string, before parameters were inserted, this attack would not be possible. Injecting dodgy strings into log messages as archi42 suggests would…

Hah, linking to OWASP is a good point. I have now put some more thought into "how would I EXACTLY classify this, if I had to list it as a finding for a customer".

Now, I think format string is not entirely right, either. That's more related to `printf`, which splits code (the format string) and data (the varargs). But log4j actually mixes code and data into one string. In the OWASP frame work, I think the more generic variant of format string attacks would be https://owasp.org/www-community/attacks/Code_Injection (that's actually linked under "related" for the format string attacks).

OWASP lives mostly in the web world, but links to CWE-77 (Command Injection, https://cwe.mitre.org/data/definitions/77.html), which is pretty generic. And log4shell matches the description just nice: 1. Data from untrusted source: yes; 2. data is part of a string that's executed: interpreted, which I think qualifies as a yes; 3. the execution gives capabilities the attacker would not have other wise: oh yes!

So it's probably safe to claim that this could fall under CWE-77 (too bad CVEs rarely use CWEs).

Now, CWE-77 (Command Injection) is a child of "CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')" https://cwe.mitre.org/data/definitions/74.html. Which states "The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities." - that's probably why the both of us thought of the the two of these! :) And even if CWE-77 is to specialized (this could be argued) CWE-74 should be a good match, quoting CWE-74: "The software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component" [end quote].

Funnily, CWE-74 is a child of https://cwe.mitre.org/data/definitions/707.html - "Improper Neutralization". Which says neutralization can be done by (among others): "[...] transformation of the input/output to be "safe" using techniques such as filtering, encoding/decoding, escaping/unescaping, quoting/unquoting, or canonicalization [...]"

:) Thanks for triggering me on this.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#78

Post by freeqaz »

wing-_-nuts wrote: post #66
anyonecancode wrote: post #57

Earlier quoted context omitted.

Yup. Here's a concrete example -- my team owns a couple of java services. They're spring boot with slf4j as our logging wrapper, using the default logging implementation of logback -- we didn't opt for log4j. So we're good, right? Well, let's do a `gradle dependencies` and see if we're pulling it in transitively -- still good. See some `log4j-api`, but no `log4j-core`. We're not actually doing any logging with log4j…

You're now making me feel better about our decision to exclude the log4j-api from our spring build entirely.

log4j-api isn't actually a problem (directly). It's the usage of log4j-core that has the JndiManager class that's the injection point for RCE.

In the case of the transient dependency, it's further complicated because we've seen that some packages repackage the JARs they depend on... that means that statically analyzing for log4j is very difficult because you can't use hashes (even if you unzip the jar and hash class files directly).

I've been working on a scanner for this stuff on GitHub[0], and it's a real pain in the neck lol. Especially for Vendor software that you don't control.

0: https://github.com/lunasec-io/lunasec/tree/master/tools/log4...

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#79

Post by jethro_tell »

bombcar wrote: post #49
js8 wrote: post #14

Earlier quoted context omitted.

> nobody reacted until now when minecraft servers got hacked That shows which part of the IT industry is really needed.. :-)

More importantly Minecraft servers are a target of convenience that both could and would be attacked by script kiddies. The open question is did anyone exploit this quietly and targeted before?

Of coarse. Especially if it was known since black hat 2016.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#80

Post by jeltz »

archi42 wrote: post #68
jeltz wrote: post #45

Earlier quoted context omitted.

Yeah, people should stop talking about sanitation in relation to SQL, because that is how we end up with data like "OConnor". The two correct solutions are escaping and parametrization/prepared statements (i.e. sending the parameters out of band).

Huh? I understand "sanitation" to mean "a transformation of data that makes the data safe for use in the subsequent program". Escaping is one way of doing that transformation, and it's good because it's not lossy. Another example: A "transformation" that's a "sanitation" but not "escaping" would be replacing all occurrences of " (btw, thanks for that it's "sanitation" and not "sanitization" ^^).

Not sure I agree, for me sanitation has a strong connotation with removing things. And sending data out of band from code on the other hand cannot be seen as a form of sanitation. And is my preferred method of solving this issue.
Post reply on HN