20 votes

Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)

Posted by Shahriar
Tags: security, java, rce, apache, log4j, cve, exploit, vulnerability, remote control execution, log4shell
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/

Link information

This data is scraped automatically and may be incorrect.

Authors
Free Wortley, Chris Thompson, Forrest Allison
Published
Dec 14 2021
Word count
892 words

4 comments

  2. [3]
    whbboyd
    Link
    Maybe worth noting, for anyone feeling the panic restarting, that this vulnerability is much less severe than CVE-2021-44228 (denial of service versus remote code execution; it's still really bad...

    Maybe worth noting, for anyone feeling the panic restarting, that this vulnerability is much less severe than CVE-2021-44228 (denial of service versus remote code execution; it's still really bad given the circumstances, but we're talking "1906 San Francisco earthquake" versus "Chicxulub impactor").

    But, since you've already dusted off your build infrastructure and set things up to deal with the dino-killer vulnerability, may as well make use of it again to deal with the city-killer…

    3 votes
    1. [2]
      whbboyd
      Link Parent
      Whoops, a consequential update: Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046) It's RCE again, you may now resume panicking. (To the best of my...

      Whoops, a consequential update:

      Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046)

      It's RCE again, you may now resume panicking.

      (To the best of my knowledge, 2.16 fully-disables the vulnerable lookup mechanism, so if you've made that upgrade, you're safe.)

      My recommendation to anyone affected by either of these issues, who doesn't have extensive infrastructure built around log4j, would be to stop using it. You can do this with no changes to client code by removing log4j-core from your application; adding log4j-over-slf4j (the SLF4J API bridge) to your application; and adding an appropriate SLF4J logging backend to your application (I think almost everybody should be using slf4j-simple; but if you have complicated requirements, or you're trying to port a complicated log4j configuration, logback is a substantially more featureful alternative.)

      5 votes
      1. whbboyd
        Link Parent
        Remarkably, this ride's not over yet: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation This one is denial-of-service (under some? circumstances, attacker-crafted...

        Remarkably, this ride's not over yet:

        Apache Log4j2 does not always protect from infinite recursion in lookup evaluation

        This one is denial-of-service (under some? circumstances, attacker-crafted log inputs can cause the lookup code to recurse infinitely (!), using a ton of resources and ultimately crashing the logging thread). It is mitigated by log4j-core version 2.17.0.

        I'll reiterate my advice to stop using log4j-core, I guess.

        3 votes