[OT] New zero-day in log4j, please let people know.


Bruno Bossola
 

Hi all,

Please make sure that this is known across your JUGs / companies and the information is passed around properly. A new zero-day has been discovered in Apache Log4j, is actively exploited in the wild, and looks awful. It will be filed as CVE-2021-44228, see our blog post if you want more info, I will drop some info here.

The problem:
This vulnerability allows the attacker to remotely execute code on your system, with the ability to get complete control of the underlying servers.

Mitigations:
Upgrade all instances of log4j-core to version 2.15:
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
        <version>2.15</version>
    </dependency>



Alternatively, launch the JVM with this parameter:
-Dlog4j2.formatMsgNoLookups=true
(useful for example for Jenkins or similar installations where you do not control the code directly)

Some people also suggest patching the library class directly but I would not do that.

Conclusions:
As you may have hinted, this is big. Apache Log4j is used by A LOT of libraries and frameworks themselves, so please make sure you are safe.

Cheers,

Bruno

p.s.
The latest version of Apache Struts, 2.5.28, uses by default Log4j 2.12.21 (vulnerable), so the story may repeat itself ;)



 

Thanks for this Bossola. 


On Mon, Dec 13, 2021, 2:33 PM Bruno Bossola <bbossola@...> wrote:
Hi all,

Please make sure that this is known across your JUGs / companies and the information is passed around properly. A new zero-day has been discovered in Apache Log4j, is actively exploited in the wild, and looks awful. It will be filed as CVE-2021-44228, see our blog post if you want more info, I will drop some info here.

The problem:
This vulnerability allows the attacker to remotely execute code on your system, with the ability to get complete control of the underlying servers.

Mitigations:
Upgrade all instances of log4j-core to version 2.15:
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
        <version>2.15</version>
    </dependency>



Alternatively, launch the JVM with this parameter:
-Dlog4j2.formatMsgNoLookups=true
(useful for example for Jenkins or similar installations where you do not control the code directly)

Some people also suggest patching the library class directly but I would not do that.

Conclusions:
As you may have hinted, this is big. Apache Log4j is used by A LOT of libraries and frameworks themselves, so please make sure you are safe.

Cheers,

Bruno

p.s.
The latest version of Apache Struts, 2.5.28, uses by default Log4j 2.12.21 (vulnerable), so the story may repeat itself ;)



olimpiu pop
 

On the same topic: 

We tried to add all relevant content.



On Mon, 13 Dec 2021 at 15:33, Bruno Bossola <bbossola@...> wrote:
Hi all,

Please make sure that this is known across your JUGs / companies and the information is passed around properly. A new zero-day has been discovered in Apache Log4j, is actively exploited in the wild, and looks awful. It will be filed as CVE-2021-44228, see our blog post if you want more info, I will drop some info here.

The problem:
This vulnerability allows the attacker to remotely execute code on your system, with the ability to get complete control of the underlying servers.

Mitigations:
Upgrade all instances of log4j-core to version 2.15:
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
        <version>2.15</version>
    </dependency>



Alternatively, launch the JVM with this parameter:
-Dlog4j2.formatMsgNoLookups=true
(useful for example for Jenkins or similar installations where you do not control the code directly)

Some people also suggest patching the library class directly but I would not do that.

Conclusions:
As you may have hinted, this is big. Apache Log4j is used by A LOT of libraries and frameworks themselves, so please make sure you are safe.

Cheers,

Bruno

p.s.
The latest version of Apache Struts, 2.5.28, uses by default Log4j 2.12.21 (vulnerable), so the story may repeat itself ;)


--
Olimpiu  Gh. Pop, MSc


Pankaj Shet
 

Hi Team, 

As the entire world knows by now that the log4j vulnerability involves jndi ldap lookup attack. There could be many other libraries using jndi ldap lookup for property resolutions. Is there any possibilty that any other framework like Spring Property placeholder configurator might face similar kind of vulnerabilities? Not sure whether it uses jndi-ldap in similar way internally ? 

Regards,
-Pankaj

On Mon, 13 Dec 2021, 20:44 olimpiu pop, <olimpiu.pop@...> wrote:
On the same topic: 

We tried to add all relevant content.



On Mon, 13 Dec 2021 at 15:33, Bruno Bossola <bbossola@...> wrote:
Hi all,

Please make sure that this is known across your JUGs / companies and the information is passed around properly. A new zero-day has been discovered in Apache Log4j, is actively exploited in the wild, and looks awful. It will be filed as CVE-2021-44228, see our blog post if you want more info, I will drop some info here.

The problem:
This vulnerability allows the attacker to remotely execute code on your system, with the ability to get complete control of the underlying servers.

Mitigations:
Upgrade all instances of log4j-core to version 2.15:
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
        <version>2.15</version>
    </dependency>



Alternatively, launch the JVM with this parameter:
-Dlog4j2.formatMsgNoLookups=true
(useful for example for Jenkins or similar installations where you do not control the code directly)

Some people also suggest patching the library class directly but I would not do that.

Conclusions:
As you may have hinted, this is big. Apache Log4j is used by A LOT of libraries and frameworks themselves, so please make sure you are safe.

Cheers,

Bruno

p.s.
The latest version of Apache Struts, 2.5.28, uses by default Log4j 2.12.21 (vulnerable), so the story may repeat itself ;)


--
Olimpiu  Gh. Pop, MSc