5 ms·

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 j

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 sanitization. (The whole discussion why a logging mechanism should support the whole JDNI stuff is still perfectly valid).

Sebb767 5y ago
This is somewhat intended, though. Also, for intercepting the logs you need _a lot_ more access than for an unauthenticated RCE and that database might not actually be accessible from the outside. It's not cool, but far less severe than the original issue.
- archi42 5y ago
  Yes, absolutely. log4shell is a pwn fest that makes the recent Exchange debacle look rather innocent (and that was already quite bad). But I can envision scenarios like unencrypted rsyslog on a LAN being relevant during pentests, or misconfigured (read: attacker readable) log files.
xorcist 5y ago
People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary. The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are. This particular logging system has been used by millions of developers for the better part of a decade before any one single person realized the actual implications.
- ethanbond 5y ago
  Just a minor clarification that’s worth being explicit about: It has been used by millions of developers for the better part of a decade before anyone disclosed the implications.
  - tfigment 5y ago
    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.
    - yawaramin 5y ago
      I think adoption has mostly gone towards slf4j+logback now.
      - mrclark411 5y ago
        logback is *gpl, I think that scares folks away.
        gunnarmorling 5y ago
        Logback is dual-licensed under EPL v1.0 and the LGPL 2.1, as per the licensee's choosing [1]. In particular, it is not licensed under the GPL. [1] http://logback.qos.ch/license.html http://logback.qos.ch/license.html
        yawaramin 5y ago
        It scares away people who see 'GPL' and refuse to read further, perhaps. Not only is it dual licensed, but both licenses (EPL and LGPL) freely allow linking with proprietary software.
jabiko 5y ago
> 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 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.
- terom 5y ago
  They still work in the CVE-2021-45046 context lookup vector.
  - Macha 5y ago
    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?
    - terom 5y ago
      That applies to the <2.15 mitigation for disabling message lookups. That mitigation for message lookups does not affect context lookups. Nor does the 2.15 fix for disabling, nor the 2.16 fix for removing message lookups. 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.
- dekmetzi 5y ago
  Agree. Too easy for folks to create vulnerabilities by evaluating those arguments as if they were trusted.
tie_ 5y ago
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.
- blueplanet200 5y ago
  > They are a problem of escaping in the application constructing the query This is a form of sanitization.
- jeltz 5y ago
  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).
  - archi42 5y ago
    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 "<" with "<" (among others!). It surely doesn't add escape characters (e.g. \), but instead replaces the problematic substring with a replacement string that makes the string safe to display on a website. Of course you'll want to replace user-supplied "<" with "&lt;". (btw, thanks for that it's "sanitation" and not "sanitization" ^^).
    - chiyc 5y ago
      I've seen "sanitization" used to often mean filtering or removal of some of the input
tgflynn 5y ago
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.
- oasisbob 5y ago
  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.
  - tgflynn 5y ago
    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.
- retzkek 5y ago
  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/blob/main/patterns/legacy/httpd https://github.com/logstash-plugins/logstash-patterns-core/b...
- regularfry 5y ago
NtGuy25 5y ago
This is actually literally a problem call SSTI, which is REALLY common. It's better to use the correct term instead of SQL injection.
- michaelt 5y ago
  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.
avgcorrection 5y ago
> 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.

Sebb767 5y ago

This is somewhat intended, though. Also, for intercepting the logs you need _a lot_ more access than for an unauthenticated RCE and that database might not actually be accessible from the outside. It's not cool, but far less severe than the original issue.

archi42 5y ago
Yes, absolutely. log4shell is a pwn fest that makes the recent Exchange debacle look rather innocent (and that was already quite bad). But I can envision scenarios like unencrypted rsyslog on a LAN being relevant during pentests, or misconfigured (read: attacker readable) log files.

xorcist 5y ago

People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary. The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are. This particular logging system has been used by millions of developers for the better part of a decade before any one single person realized the actual implications.

ethanbond 5y ago
Just a minor clarification that’s worth being explicit about: It has been used by millions of developers for the better part of a decade before anyone disclosed the implications.
- tfigment 5y ago
  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.
  - yawaramin 5y ago
    I think adoption has mostly gone towards slf4j+logback now.
    - mrclark411 5y ago
      logback is *gpl, I think that scares folks away.
      - gunnarmorling 5y ago
        Logback is dual-licensed under EPL v1.0 and the LGPL 2.1, as per the licensee's choosing [1]. In particular, it is not licensed under the GPL. [1] http://logback.qos.ch/license.html http://logback.qos.ch/license.html
      - yawaramin 5y ago
        It scares away people who see 'GPL' and refuse to read further, perhaps. Not only is it dual licensed, but both licenses (EPL and LGPL) freely allow linking with proprietary software.

jabiko 5y ago

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

terom 5y ago
They still work in the CVE-2021-45046 context lookup vector.
- Macha 5y ago
  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?
  - terom 5y ago
    That applies to the <2.15 mitigation for disabling message lookups. That mitigation for message lookups does not affect context lookups. Nor does the 2.15 fix for disabling, nor the 2.16 fix for removing message lookups. 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.
dekmetzi 5y ago
Agree. Too easy for folks to create vulnerabilities by evaluating those arguments as if they were trusted.

tie_ 5y ago

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.

blueplanet200 5y ago
> They are a problem of escaping in the application constructing the query This is a form of sanitization.
jeltz 5y ago
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).
- archi42 5y ago
  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 "<" with "<" (among others!). It surely doesn't add escape characters (e.g. \), but instead replaces the problematic substring with a replacement string that makes the string safe to display on a website. Of course you'll want to replace user-supplied "<" with "&lt;". (btw, thanks for that it's "sanitation" and not "sanitization" ^^).
  - chiyc 5y ago
    I've seen "sanitization" used to often mean filtering or removal of some of the input

tgflynn 5y ago

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.

oasisbob 5y ago
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.
- tgflynn 5y ago
  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.
retzkek 5y ago
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/blob/main/patterns/legacy/httpd https://github.com/logstash-plugins/logstash-patterns-core/b...
regularfry 5y ago

NtGuy25 5y ago

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

michaelt 5y ago
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.

avgcorrection 5y ago

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