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

81–90 of 103 posts

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

#81

Post by giobox »

thereddaikon wrote: post #63
sumtechguy wrote: post #52

Earlier quoted context omitted.

What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, deploy and bobs your uncle you are good. But some projects are little more interesting in that they include libs like this, or include libs that include it. It is part of their foundation/framework. So you can still put in override and ignore what the lib wants.…

There isn't one. This method of development inherently leads to these kinds of problems. Software engineering is still in its infancy and has yet to truly develop a universal best practice development cycle. Eventually these things will be codified.

> Eventually these things will be codified.

Is there actually evidence for this? The 30 year arc of the industry to date that I am familiar with so far shows little sign of engineering standards in software codifying around anything.

If we are in the infancy stage in 2020, we are one very large infant. More likely to me is that in the future, software will change so much again that what we do today is unrecognisable; not because of codification but because of the inevitable tech churn between now and then.

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

#82

Post by avgcorrection »

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…

> Blindly trusting user input instead of doing proper sanitization.

More like blindly trusting that a logging library will just log the strings that you pass to it.

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

#83

Post by Buttons840 »

giobox wrote: post #81
thereddaikon wrote: post #63

Earlier quoted context omitted.

There isn't one. This method of development inherently leads to these kinds of problems. Software engineering is still in its infancy and has yet to truly develop a universal best practice development cycle. Eventually these things will be codified.

> Eventually these things will be codified. Is there actually evidence for this? The 30 year arc of the industry to date that I am familiar with so far shows little sign of engineering standards in software codifying around anything. If we are in the infancy stage in 2020, we are one very large infant. More likely to me is that in the future, software will change so much again that what we do today is unrecognisable;…

The closest things we get to standards are automated vulnerability checkers. I'm currently dealing with one of these vulnerability scanners which claims our code base has some XSS vulnerabilities, which I know is wrong because the app isn't a web app. SMH

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

#84

Post by mrclark411 »

yawaramin wrote: post #54
tfigment wrote: post #53

Earlier quoted context omitted.

What i discovered was all of my applications that use log4j do not use version 2. They have out of date dependencies or use slf4j. I'm not sure how i feel but mostly happy im not scrambling. I wonder what adoption rate v2 actually has.

I think adoption has mostly gone towards slf4j+logback now.

logback is *gpl, I think that scares folks away.

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

#85

Post by krylon »

When I was shopping for groceries today, I saw something strange. The buses have displays to show what Line they are, today all of the buses I saw had blank displays. On my way home, I could see the display on the bus driver's seat, which only displayed an otherwise blank Windows Embedded CE 6.0 start screen.

Oh, and the thingy you put your ticket in get the stamp was out of order on all the buses.

Made me wonder if that was due to some component involved was using log4j? I don't think it's very likely - why would the bus display or the ticket stamping machine be affected in a way that requires turning them off? But who knows, maybe somebody overreacted, or maybe these depend on some backoffice infrastructure that is temporarily offline due to log4j.

It was weird, though. This is the first time I remember a security vulnerability made the national news (in Germany, if it matters). I don't think even Heartbleed got that much attention outside IT news outlets.

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

#86

Post by hermitdev »

jeltz wrote: post #80
archi42 wrote: post #68

Earlier quoted context omitted.

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.

I think, generally, sanitization means protecting against potentially malicious input. Whether it takes form via escaping or removal or some other remediation is beside the point.

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

#87

Post by archi42 »

jeltz wrote: post #80
archi42 wrote: post #68

Earlier quoted context omitted.

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.

You're essentially saying "sanitation" equals "filtering". Looking at CWE-707 (https://cwe.mitre.org/data/definitions/707.html) I'd rather say that "sanitation" is what MITRE calls [begin quote]transformation of the input/output to be "safe" using techniques such as filtering, encoding/decoding, escaping/unescaping, quoting/unquoting, or canonicalization[end quote] (well, I'm repeating myself here).

Now a Google search finds instances where sanitization/sanitation also includes techniques beyond filtering: https://www.webopedia.com/definitions/input-sanitization/ https://hack.technoherder.com/input-sanitization/ https://developer.wordpress.org/plugins/security/securing-in... https://stackoverflow.com/questions/129677/how-can-i-sanitiz...

But there are also results where it isn't really clear, or where the only sanitation technique considered is filtering. So I'd say "yeah, it's unclear and poorly defined".

Buuuuut: I still like my definition more, as I have a word for "all techniques that aim to make an input safe for processing" (sanitation/sanitization) while I can still refer to "destructive elimination of substrings" as just "filtering", which is a again different from outright "rejection of input" by using an "allow list" or "deny list". :P

I agree that splitting data and code is the way to go, if that's an option. But I didn't talk about that in the post you're answering to, so I'll ignore that ;-)

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

#88

Post by Sniffnoy »

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…

I would normally assume "sanitization" means "escaping"... as far as I'm concerned, anything other than escaping is incorrect sanitization!

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

#89

Post by retzkek »

tgflynn wrote: post #56
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…

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.

Logstash is a hugely popular application for collecting/processing/shipping logs, mainly associated with elasticsearch ("ELK") but has lots of output plugins. It uses log4j, so if one of the log events it was processing contained an exploit string, and also caused logstash to encounter an error processing or shipping the message*, that message would get logged to logstash's own log, thus triggering the exploit deep in someone's infrastructure.

* probably not too hard to come up with a way to break one of the many "grok" pattern regexes https://github.com/logstash-plugins/logstash-patterns-core/b...

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

#90

Post by regularfry »

tgflynn wrote: post #56
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…

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.

In addition to sibling comments, there's also a SocketServer component in the library you can instantiate and fire log messages at if you want to.

Which, if you're still on 1.2.x, also has an RCE against it.

Post reply on HN