How to use NPM Rest API to get audit (npm audit) result
Introduction Npm has a tool called: npm audit which reports if your packages or…
December 15, 2021
On 9th December 2021, an industry-wide vulnerability was discovered that specifically affect the Apache Log4j Java library
.
The security vulnerability allows an attacker (Hacker) to achieve Remote Code Execution (RCE) on a host.
See the detailed Vulnerability CVE
It’s important to note that Apache log4j is a Java package which indicates any platform/application using Java is potentially at risk. This is a fast moving exploit with exploit code being released in the wild after few days this vulnerability was found and Apache has now published a patch to remediate the vulnerability.
Following versions are affected:
2.0-beta9 <= Apache log4j <= 2.15.0
They initially suggested to migrate it to 2.15. But, as soon as they released. Next day, another security vulnerability popped up.
Now, the safe version you need to move is: 2.16.0
The best way to mitigate from this vulnerability is to upgrade to 2.16.0
.
If by any chance, you are not able to upgrade to this library version. It is recommended to ensure that you are setting a system property on both client side and server side:
log4j2.formatMsgNoLookups=true
Note: This vulnerability is only affecting log4k library 2.0-beta9 <= Apache log4j <= 2.15.0
So, 1.x
is actually safe. But, you should always plan to migrate to the latest libraries.
This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.
Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup
to true
do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.16.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.16.0</version>
</dependency>
Companies are in hurry to fix this ASAP. As, they understand its impact. Almost, everybody is working on upgrading these libraries.
Introduction Npm has a tool called: npm audit which reports if your packages or…
Introduction Cyberark kind of tools are a must for security in your…
Introduction In this post, we will see Python 3.7.9 patch for FIPS enabled…
Introduction While this topic may applicable to all mysql/mariadb users who…
The problem comes while using FTPS. When developer uses login method of this…
Code that I have is: It was: I changed it to: So, I needed to change button type…
Introduction So you have a Django project, and want to run it using docker image…
Introduction It is very important to introduce few process so that your code and…
Introduction In this post, we will see a sample Jenkin Pipeline Groovy script…
Introduction We often require to execute in timed manner, i.e. to specify a max…
Introduction In some of the cases, we need to specify namespace name along with…
Introduction In most of cases, you are not pulling images from docker hub public…