You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Detects Log4J versions on your file-system within any application that are vulnerable to [CVE-2021-44228](https://mergebase.com/vulnerability/CVE-2021-44228/) and [CVE-2021-45046](https://mergebase.com/vulnerability/CVE-2021-45046/). It is able to even find instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too!
4
6
5
-
Currently reports `log4j-core` versions 2.12.2 and 2.17.0 as **\_SAFE\_**, 2.15.0 and 2.16.0 as **\_OKAY\_** and all other versions as **\_VULNERABLE\_**
7
+
# Table of Contents
8
+
-[Introduction](#itemdetector)
9
+
-[Example Usage](#itemexample)
10
+
-[More Example Usage](#itemmore)
11
+
-[Understanding The Results](#itemresults)
12
+
-[Usage](#itemusage)
13
+
-[Build From Source ](#itembuild)
14
+
-[Testing](#itemtesting)
15
+
-[License](#itemlicense)
16
+
-[Frequently Asked Questions](#faq)
17
+
-[How Does It Work?](#itemwork)
18
+
-[This Scanner Only Reports Hits Against The `log4j-core` Library. What About `log4j-api`? ](#itemapi)
19
+
-[Why Report About 2.10.0, 2.15.0, and 2.16.0 ? ](#item2.10.0)
20
+
-[What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about? ](#itemwar)
21
+
-[What About Log4J 1.2.x ?](#item1.2.x)
22
+
-[How Can I Be Sure This Isn't A Trojan Pretending To Be A Log4J Detector?](#itemtrojan)
23
+
-[What Is MergeBase All About?](#item)
24
+
25
+
26
+
27
+
# Introduction <aname="itemdetector"></a>
28
+
29
+
Currently reports `log4j-core` versions 2.12.2 and 2.16.0 as **\_SAFE\_**, 2.15.0 as **\_OKAY\_** and all other versions as **\_VULNERABLE\_**
6
30
(although it does report pre-2.0-beta9 as "**\_POTENTIALLY_SAFE\_**").
7
31
8
32
Can correctly detect log4j inside executable spring-boot jars/wars, dependencies blended
@@ -11,13 +35,13 @@ exploded jar files just sitting uncompressed on the file-system (aka *.class).
11
35
12
36
We currently maintain a collection of [log4j-samples](https://github.com/mergebase/log4j-samples) we use for testing.
# Understanding The Results <aname="itemresults"></a>
47
70
48
71
**\_VULNERABLE\_** -> You need to upgrade or remove this file.
49
72
50
-
**\_OKAY\_** -> We only report this for Log4J versions 2.15.0 and 2.16.0. We recommend upgrading to 2.17.0.
73
+
**\_OKAY\_** -> We only report this for Log4J version 2.15.0. We recommend upgrading to 2.16.0.
51
74
52
-
**\_SAFE\_** -> We currently only report this for Log4J versions 2.17.0 and 2.12.2.
75
+
**\_SAFE\_** -> We currently only report this for Log4J versions 2.16.0 and 2.12.2.
53
76
54
-
**\_OLD\_** -> You are safe from CVE-2021-44228, but should plan to upgrade because Log4J 1.2.x has been EOL for 7 years and has several known-vulnerabilities.
77
+
**\_OLD\_** -> You are safe from CVE-2021-44228, but should plan to upgrade because Log4J 1.2.x has been EOL for 10 years and has several known-vulnerabilities.
55
78
56
79
**\_POTENTIALLY_SAFE\_** -> The "JndiLookup.class" file is not present, either because your version of Log4J is very old (pre 2.0-beta9), or because someone already removed this file. Make sure it was someone in your team or company that removed "JndiLookup.class" if that's the case, because attackers have been known to remove this file themselves to prevent additional competing attackers from gaining access to compromised systems.
57
80
58
-
# This Scanner Only Reports Hits Against The `log4j-core` Library. What About `log4j-api`?
59
-
60
-
Many scanners (including GitHub's own [Dependabot](https://github.com/dependabot)) currently report both "`log4j-core`" and "`log4j-api`" libraries as vulnerable. These scanners are incorrect. There is currently no existing version of the "`log4j-api`" library that can be exploited by any of these vulnerabilities.
61
-
62
-
# Why Report About 2.10.0, 2.15.0, 2.16.0, and 2.17.0 ?
63
-
64
-
We consider version 2.10.0 important because that's the first version where Log4J's vulnerable "message lookup feature" can be disabled via Log4J configuration.
65
-
66
-
We consider versions 2.15.0 and 2.16.0 important because these are the first versions where Log4J's default out-of-the-box configuration is not vulnerable to CVE-2021-44228.
67
-
68
-
And version 2.17.0 is important because it's not vulnerable to CVE-2021-45046. Despite CVE-2021-45046 being much less serious,
69
-
we anticipate everyone will want to patch to 2.17.0.
70
-
71
-
# What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about?
72
-
73
-
The "!" means the log4j-detector entered a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar). Since zip files can
74
-
contain zip files, a single result might contain more than one "!" indicator in its result.
75
-
76
-
Note: the log4j-detector only recursively enters zip archives. It does not enter tar or gz or bz2, etc. The main reason
77
-
being that Java systems are often configured to execute jars inside jars, but they are never configured to execute other
78
-
file formats (that I know of!). And so a log4j copy inside a *.tar.gz is probably not reachable for a running Java
79
-
system, and hence, not a vulnerability worth reporting.
80
-
81
-
2nd note: for zips-inside-zips our scanner does load the inner-zip completely into memory (using ByteArrayInputStream)
82
-
before attempting to scan it. You might need to give Java some extra memory if you have extremely large inner-zips on
We maintain a collection of log4j samples here: https://github.com/mergebase/log4j-samples
112
108
113
-
# License
109
+
# License <aname="itemlicense"></a>
114
110
115
111
GPL version 3.0
116
112
117
-
# How Does It Work?
113
+
# Frequently Asked Questions <aname="faq"></a>
114
+
115
+
# How Does It Work? <aname="itemwork"></a>
118
116
119
117
The Java compiler stores String literals directly in the compiled *.class files. If log4j-detector detects a file
120
118
named "JndiManager.class"
121
119
on your file-system, it then examines that file for this String: "Invalid JNDI URI - {}". Turns out that specific String
122
120
literal is only present in the patched version of Log4J (version 2.15.0). Any versions of Log4J without that String are
123
121
vulnerable.
124
122
125
-
# What About Log4J 1.2.x ?
123
+
## This Scanner Only Reports Hits Against The `log4j-core` Library. What About `log4j-api`? <aname="itemapi"></a>
124
+
125
+
Many scanners (including GitHub's own [Dependabot](https://github.com/dependabot)) currently report both "`log4j-core`" and "`log4j-api`" libraries as vulnerable. These scanners are incorrect. There is currently no existing version of the "`log4j-api`" library that can be exploited by any of these vulnerabilities.
126
+
127
+
At [MergeBase](https://mergebase.com/) we pride ourselves on our scan accuracy. You're already busy enough patching and defending your systems. We don't want you to waste your time with false positives. That's why we don't report any hits against `log4j-api`.
128
+
129
+
130
+
## Why Report About 2.10.0, 2.15.0, and 2.16.0 ? <aname="item2.10.0"></a>
131
+
132
+
We consider version 2.10.0 important because that's the first version where Log4J's vulnerable "message lookup feature" can be disabled via Log4J configuration.
133
+
134
+
We consider version 2.15.0 important because that's the first version where Log4J's default out-of-the-box configuration is not vulnerable to CVE-2021-44228.
135
+
136
+
And version 2.16.0 is important because it's not vulnerable to CVE-2021-45046. Despite CVE-2021-45046 being much less serious,
137
+
we anticipate everyone will want to patch to 2.16.0.
138
+
139
+
## What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about? <aname="itemwar"></a>
140
+
141
+
The "!" means the log4j-detector entered a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar). Since zip files can
142
+
contain zip files, a single result might contain more than one "!" indicator in its result.
143
+
144
+
Note: the log4j-detector only recursively enters zip archives. It does not enter tar or gz or bz2, etc. The main reason
145
+
being that Java systems are often configured to execute jars inside jars, but they are never configured to execute other
146
+
file formats (that I know of!). And so a log4j copy inside a *.tar.gz is probably not reachable for a running Java
147
+
system, and hence, not a vulnerability worth reporting.
148
+
149
+
2nd note: for zips-inside-zips our scanner does load the inner-zip completely into memory (using ByteArrayInputStream)
150
+
before attempting to scan it. You might need to give Java some extra memory if you have extremely large inner-zips on
151
+
your system (e.g., 1 GB or larger).
152
+
153
+
## What About Log4J 1.2.x ? <aname="item1.2.x"></a>
126
154
127
155
Only versions of Log4J 2.x (from 2.0-beta9 to 2.14.1) are vulnerable to CVE-2021-44228.
128
156
129
-
# How Can I Be Sure This Isn't A Trojan Pretending To Be A Log4J Detector?
157
+
##How Can I Be Sure This Isn't A Trojan Pretending To Be A Log4J Detector? <aname="itemtrojan"></a>
130
158
131
159
Great question! Since we include the complete source code here in Github (all 750 lines of Java), as well as the steps
132
160
to build it, and since this tool has zero dependencies, it shouldn't take too long to carefully study the code to your
133
161
satisfaction. If you don't trust Maven you can go directly into the "src/main/java/com/mergebase/log4j" directory and
134
162
type "javac \*.java". That works, too!
135
163
136
-
# What Is MergeBase All About?
164
+
# What Is MergeBase All About? <aname="itemmergebase"></a>
165
+
166
+
137
167
138
168
[MergeBase](https://mergebase.com/) is an SCA company (Software Composition Analysis) based in Vancouver, Canada. We're
139
169
similar to companies like Snyk, Sonatype, Blackduck, etc., in that we help companies detect and manage vulnerable
0 commit comments