Apache Log4j Vulnerability

The Apache Software Foundation (ASF) on Tuesday rolled out fresh
patches to contain an arbitrary code execution flaw in Log4j that
could be abused by threat actors to run malicious code on affected
systems, making it the fifth security shortcoming to be discovered
in the tool in the span of a month.

Tracked as CVE-2021-44832[1], the vulnerability is
rated 6.6 in severity on a scale of 10 and impacts all versions of
the logging library from 2.0-alpha7 to 2.17.0 with the exception of
2.3.2 and 2.12.4. While Log4j versions 1.x are not affected, users
are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for
Java 7), or 2.17.1 (for Java 8 and later).

“Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding
security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote
code execution (RCE) attack where an attacker with permission to
modify the logging configuration file can construct a malicious
configuration using a JDBC Appender with a data source referencing
a JNDI URI which can execute remote code,” the ASF said[2]
in an advisory. “This issue is fixed by limiting JNDI data source
names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and
2.3.2.”

Although no credits were awarded by the ASF for the issue,
Checkmarx security researcher Yaniv Nizry claimed credit[3]
for reporting the vulnerability to Apache on December 27.

Automatic GitHub Backups

“The complexity of this vulnerability is higher than the
original CVE-2021-44228 since it requires the attacker to have
control over the configuration,” Nizry noted[4]. “Unlike Logback, in
Log4j there is a feature to load a remote configuration file or to
configure the logger through the code, so an arbitrary code
execution could be achieved with [an] MitM attack, user input
ending up in a vulnerable configuration variable, or modifying the
config file.”

With the latest fix, the project maintainers have addressed a
total of four issues in Log4j since the Log4Shell[5]
flaw came to light earlier this month, not to mention a fifth
vulnerability affecting versions Log4j 1.2 that will not be fixed

  • CVE-2021-44228[6] (CVSS score: 10.0) – A
    remote code execution vulnerability affecting Log4j versions from
    2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
  • CVE-2021-45046[7] (CVSS score: 9.0) – An
    information leak and remote code execution vulnerability affecting
    Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in
    version 2.16.0)
  • CVE-2021-45105[8] (CVSS score: 7.5) – A
    denial-of-service vulnerability affecting Log4j versions from
    2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
  • CVE-2021-4104[9] (CVSS score: 8.1) – An
    untrusted deserialization flaw affecting Log4j version 1.2 (No fix
    available; Upgrade to version 2.17.1)

The development also comes as intelligence agencies from across
Australia, Canada, New Zealand, the U.K., and the U.S. issued[10] a joint advisory
warning of mass exploitation of multiple vulnerabilities in
Apache’s Log4j software library by nefarious adversaries.

References

  1. ^
    CVE-2021-44832
    (nvd.nist.gov)
  2. ^
    said
    (logging.apache.org)
  3. ^
    claimed
    credit
    (twitter.com)
  4. ^
    noted
    (checkmarx.com)
  5. ^
    Log4Shell
    (thehackernews.com)
  6. ^
    CVE-2021-44228
    (thehackernews.com)
  7. ^
    CVE-2021-45046
    (thehackernews.com)
  8. ^
    CVE-2021-45105
    (thehackernews.com)
  9. ^
    CVE-2021-4104
    (nvd.nist.gov)
  10. ^
    issued
    (thehackernews.com)

Read more