Skip to content

Commit 34647b8

Browse files
sjrdsjrd
committed
Add a post on the state of the log4j CVE in the Scala ecosystem.
1 parent 2ba105c commit 34647b8

File tree

1 file changed

+156
-0
lines changed

1 file changed

+156
-0
lines changed

‎_posts/2021-12-16-state-of-log4j-in-scala-ecosystem.md

Lines changed: 156 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,156 @@
1+
---
2+
category: blog-detail
3+
post-type: blog
4+
by: Sébastien Doeraene, Adrien Piquerez
5+
title: "The state of the log4j CVE in the Scala ecosystem"
6+
---
7+
8+
The computer science world is currently turned upside down over a very widespread vulnerability in log4j v2, as well as a followup one.
9+
The vulnerabilities are registered as [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) and [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046).
10+
11+
A project is affected by the log4j vulnerabilities if it contains a vulnerable version of a log4j artifact on its classpath.
12+
13+
You may find below a non-comprenhensive list of core Scala tools and libraries known to be affected by the vulnerability, and in which version (if any) it is addressed.
14+
15+
We also give some useful tasks and settings to address the vulnerabilities in applications built with sbt, Mill or Maven.
16+
17+
## State of core tools and libraries
18+
19+
### Disclaimer
20+
21+
The following information is provided AS IS, without any warranty of any kind, for your convenience.
22+
A proper security assessment of any CVE, including the log4j vulnerabilities, remains your sole responsibility.
23+
24+
### Affected tools and libraries with fix available
25+
26+
The following core tools and libraries have versions affected by the log4j vulnerability, but have published newer versions with the appropriate patches.
27+
It is recommended that you upgrade to these versions as soon as possible.
28+
29+
If this is not possible, see the tip above on how to force the dependency of log4j.
30+
31+
| Organization | Artifact or tool name | Fixed in version |
32+
|--------------|-----------------------|------------------|
33+
| | sbt | 1.5.7 |
34+
35+
### Affected tools and libraries without known fix available
36+
37+
The following core tools and libraries are affected by the log4j vulnerability, and have not yet published an updated version with the appropriate patches.
38+
Consult the CVEs to use any other applicable mitigation that may apply in your case.
39+
40+
It may also be possible to force the dependency of log4j, as explained above.
41+
42+
| Organization | Artifact name |
43+
|--------------|---------------|
44+
| none known so far | |
45+
46+
## Useful sbt tasks and settings
47+
48+
If your application is written in sbt, which is common in the Scala ecosystem, here are some information on how to identify the classpath of your application, and how to force an upgrade of the log4j dependency.
49+
50+
### `fullClasspath`
51+
52+
The task `fullClasspath`, properly scoped to a project and a configuration, gives the final, full classpath with which your project is executed.
53+
A typical invocation looks like
54+
55+
```
56+
$ sbt
57+
> show myProject/Compile/fullClasspath
58+
[info] * Attributed(.../myProject/target/scala-2.12/sbt-1.0/classes)
59+
...
60+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.11.2/log4j-api-2.11.2.jar)
61+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.11.2/log4j-core-2.11.2.jar)
62+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j-impl/2.11.2/log4j-slf4j-impl-2.11.2.jar)
63+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-sbt/librarymanagement-core_2.12/1.5.3/librarymanagement-core_2.12-1.5.3.jar)
64+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-sbt/librarymanagement-ivy_2.12/1.5.3/librarymanagement-ivy_2.12-1.5.3.jar)
65+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-sbt/compiler-interface/1.5.7/compiler-interface-1.5.7.jar)
66+
...
67+
[success] Total time: 0 s, completed Dec 16, 2021 11:07:28 AM
68+
```
69+
70+
With older versions of sbt, the command looks like
71+
72+
```
73+
$ sbt
74+
> show myProject/compile:fullClasspath
75+
```
76+
77+
The version numbers found there for log4j (2.11.2) are the ones that are used when running the program.
78+
This is a vulnerable version, so we should upgrade.
79+
80+
### Upgrading transitive dependencies
81+
82+
In the above example, our program does not directly depend on log4j.
83+
It comes from a transitive dependency.
84+
Fortunately, in the Maven ecosystem, we do not need to wait for upstream libraries to upgrade to new versions of vulnerable libraries.
85+
We can force the upgrade of transitive libraries right from our build.
86+
87+
In the above project, we add the following sbt setting in the appropriate `.settings()` call to force an upgrade of log4j:
88+
89+
```scala
90+
libraryDependencies ++= Seq(
91+
"org.apache.logging.log4j" % "log4j-api" % "2.16.0",
92+
"org.apache.logging.log4j" % "log4j-core" % "2.16.0",
93+
"org.apache.logging.log4j" % "log4j-slf4j-impl" % "2.16.0",
94+
),
95+
```
96+
97+
Reloading the build and displaying the `fullClasspath`, we can confirm that the fixed version of log4j is used:
98+
99+
```
100+
$ sbt
101+
> show myProject/Compile/fullClasspath
102+
...
103+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.16.0/log4j-api-2.16.0.jar)
104+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/log4j-core-2.16.0.jar)
105+
[info] * Attributed(.../.cache/coursier/v1/https/repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j-impl/2.16.0/log4j-slf4j-impl-2.16.0.jar)
106+
...
107+
[success] Total time: 0 s, completed Dec 16, 2021 11:20:44 AM
108+
```
109+
110+
## Useful Mill commands
111+
112+
Using Mill, you can show the full classpath of a project using the following command:
113+
114+
```
115+
$ mill show myProject.runClasspath
116+
```
117+
118+
You can also force an upgrade of transitive dependencies with additional entries in your `ivyDeps`:
119+
120+
```scala
121+
def ivyDeps = Agg(
122+
ivy"org.apache.logging.log4j:log4j-api:2.16.0",
123+
ivy"org.apache.logging.log4j:log4j-core:2.16.0",
124+
ivy"org.apache.logging.log4j:log4j-slf4j-impl:2.16.0",
125+
)
126+
```
127+
128+
## Useful Maven commands
129+
130+
Similarly to the above, you can show the full classpath of a Maven project using the following command:
131+
132+
```
133+
$ mvn dependency:build-classpath
134+
```
135+
136+
More information can be found [in this StackOverflow answer](https://stackoverflow.com/a/27451672/1829647).
137+
138+
Like in sbt, you can force an upgrade of transitivie dependencies of log4j using `<dependency>` entries:
139+
140+
```xml
141+
<dependency>
142+
<groupId>org.apache.logging.log4j</groupId>
143+
<artifactId>log4j-api</artifactId>
144+
<version>2.16.0</version>
145+
</dependency>
146+
<dependency>
147+
<groupId>org.apache.logging.log4j</groupId>
148+
<artifactId>log4j-core</artifactId>
149+
<version>2.16.0</version>
150+
</dependency>
151+
<dependency>
152+
<groupId>org.apache.logging.log4j</groupId>
153+
<artifactId>log4j-slf4j-impl</artifactId>
154+
<version>2.16.0</version>
155+
</dependency>
156+
```

0 commit comments

Comments
 (0)