5 ms·

Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.luna

Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/

deleted 5y ago
[deleted]
dang 5y ago
Ok, I think we can change the URL to that from the submitted URL (https://github.com/apache/logging-log4j2/pull/608 https://github.com/apache/logging-log4j2/pull/608), which doesn't provide much (any?) context for understanding what's being fixed there.
- freeqaz 5y ago
  Thanks, dang!
nightpool 5y ago
Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch https://github.com/Glavo/log4j-patch is a JAR that you can add to your classpath to simply override the same class. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... for more details.
- LOG4J2-2109 5y ago
  The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 or - Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior. [1] https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3198
  - freeqaz 5y ago
    Thanks for writing up this fix. I quoted it in the post here: https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-mitigation https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-m...
  - markhahn 5y ago
    extirpate jndi. personally, I'd extirpate Java too. but I'm curious: does anyone need and use jndi?
  - skimania 5y ago
    The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above. https://stackoverflow.com/a/42802636/270317 https://stackoverflow.com/a/42802636/270317
    - LOG4J2-2109 5y ago
      Confirming that this is correct: the {nolookups} option was added in v2.7 as a result of LOG4J2-905, so this mitigation is not available on versions prior to 2.7. Corroborating sources: [4] https://issues.apache.org/jira/browse/LOG4J2-905 https://issues.apache.org/jira/browse/LOG4J2-905 [5] https://logging.apache.org/log4j/2.x/changes-report.html#a2.7 https://logging.apache.org/log4j/2.x/changes-report.html#a2.... Checking on the viability of the classloading-based mitigations now across the versions. It seems that LOG4J-1051 was raised [6] to make the class instantiator more tolerant of missing classes, and the resulting changes were released in v2.4 and v2.7. Will check how earlier versions behave in this case. [6] https://issues.apache.org/jira/browse/LOG4J2-1051 https://issues.apache.org/jira/browse/LOG4J2-1051
    - deleted 5y ago
      [deleted]
  - anuragrsk 5y ago
    is log4j also has this security issue or this is only in log4j2?
beliu 5y ago
Thank you for this super clear and concise write-up. Used it to write up these instructions for our users and customers to patch the vulnerability across their codebase and sharing here in case it's of use/interest to others: https://twitter.com/beyang/status/1469171471784329219 https://twitter.com/beyang/status/1469171471784329219.

deleted 5y ago

[deleted]

dang 5y ago

Ok, I think we can change the URL to that from the submitted URL (https://github.com/apache/logging-log4j2/pull/608 https://github.com/apache/logging-log4j2/pull/608), which doesn't provide much (any?) context for understanding what's being fixed there.

freeqaz 5y ago
Thanks, dang!

nightpool 5y ago

Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch https://github.com/Glavo/log4j-patch is a JAR that you can add to your classpath to simply override the same class. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/pull/608#issuecomme... for more details.

LOG4J2-2109 5y ago
The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 or - Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior. [1] https://issues.apache.org/jira/browse/LOG4J2-2109 https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3198
- freeqaz 5y ago
  Thanks for writing up this fix. I quoted it in the post here: https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-mitigation https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-m...
- markhahn 5y ago
  extirpate jndi. personally, I'd extirpate Java too. but I'm curious: does anyone need and use jndi?
- skimania 5y ago
  The solution of using {nolookups} on every logging pattern is only available from version 2.7 and above. https://stackoverflow.com/a/42802636/270317 https://stackoverflow.com/a/42802636/270317
  - LOG4J2-2109 5y ago
    Confirming that this is correct: the {nolookups} option was added in v2.7 as a result of LOG4J2-905, so this mitigation is not available on versions prior to 2.7. Corroborating sources: [4] https://issues.apache.org/jira/browse/LOG4J2-905 https://issues.apache.org/jira/browse/LOG4J2-905 [5] https://logging.apache.org/log4j/2.x/changes-report.html#a2.7 https://logging.apache.org/log4j/2.x/changes-report.html#a2.... Checking on the viability of the classloading-based mitigations now across the versions. It seems that LOG4J-1051 was raised [6] to make the class instantiator more tolerant of missing classes, and the resulting changes were released in v2.4 and v2.7. Will check how earlier versions behave in this case. [6] https://issues.apache.org/jira/browse/LOG4J2-1051 https://issues.apache.org/jira/browse/LOG4J2-1051
  - deleted 5y ago
    [deleted]
- anuragrsk 5y ago
  is log4j also has this security issue or this is only in log4j2?

beliu 5y ago

Thank you for this super clear and concise write-up. Used it to write up these instructions for our users and customers to patch the vulnerability across their codebase and sharing here in case it's of use/interest to others: https://twitter.com/beyang/status/1469171471784329219 https://twitter.com/beyang/status/1469171471784329219.