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

41–50 of 103 posts

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

#41

Post by jabiko »

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…

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}

In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623

Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.

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

#42

Post by silon42 »

wcoenen wrote: post #21
simion314 wrote: post #10

Earlier quoted context omitted.

>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want…

I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity. A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.

I wish they didn't add SELECTION back... https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection

But I'll never accept client side decorations.

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

#43

Post by tie_ »

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 problem with an obscure feature that is left with insecure defaults, and is (was?) unknown to the vast majority of developers who integrate the library in their apps.

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

#44

Post by terom »

jabiko wrote: post #41
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…

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx} In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623 Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.

They still work in the CVE-2021-45046 context lookup vector.

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

#45

Post by jeltz »

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…

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).

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

#46

Post by Macha »

terom wrote: post #44
jabiko wrote: post #41

Earlier quoted context omitted.

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx} In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623 Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.

They still work in the CVE-2021-45046 context lookup vector.

My understanding is this is true if you've simply disabled them with the config flag to 2.15, but is not true in 2.16?

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

#48

Post by terom »

Macha wrote: post #46
terom wrote: post #44

Earlier quoted context omitted.

They still work in the CVE-2021-45046 context lookup vector.

My understanding is this is true if you've simply disabled them with the config flag to 2.15, but is not true in 2.16?

That applies to the But 2.16 disables JNDI lookups entirely, so that they cannot be triggered via any lookups, including context lookups. But context lookups can still trigger other non-JNDI lookups.

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

#49

Post by bombcar »

js8 wrote: post #14
mol4711 wrote: post #11

Earlier quoted context omitted.

This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.

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

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

#50

Post by dekmetzi »

jabiko wrote: post #41
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…

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx} In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623 Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.

Agree. Too easy for folks to create vulnerabilities by evaluating those arguments as if they were trusted.
Post reply on HN