Please add support 3 CVE (log4j) about log4shell-finder

[trust1345]

logback have different version numbers, different folder structure. I will check that later

Maybe this will help
logpresso/CVE-2021-44228-Scanner@79ab0e5

[trust1345]

In all cases that I have been able to check, the latest version works well. I think we need to make a release.

PS. Updated the information in the table above

[trust1345]

In all cases that I have been able to check, the latest version works well.
I think need to make a release.

[HynekPetrak]

@trust1345 CVE-2021-42550 is logback, not log4j vulnerability.

[trust1345]

Yes, this is understandable, but I think that the scanner has almost everything ready to implement the search for this CVE.
The actions to find this vulnerability are similar.Why not?

[HynekPetrak]

logback have different version numbers, different folder structure. I will check that later

[HynekPetrak]

@trust1345 added detection of CVE-2017-5645.
It was rather complicated and may have broken detection of other vulnerabilities, please test carefully.

[trust1345]

Hi @HynekPetrak version https://github.com/HynekPetrak/log4shell-finder/tree/95a52803f3cca82803e10600ef56a2f845abb209
falls into traceback with the all argument
error_1.2120220118.txt
In attached file first run with directory argument (successful launch), second with all argument drop into traceback.

Run task with samples these https://github.com/mergebase/log4j-samples

[HynekPetrak]

Fixed, please check

[trust1345]

Thanks, I'm still checking out different options.

[trust1345]

Tried to bring the table up to date.
Last update 2022.12.25

log4J 2.x

detect	CVE	CVSSv3	Severity	lib from	lib to	lib fix	comment
x	CVE-2021-44228	10,0	Critical	2.0-beta9	2.14.1	2.15.0
x	CVE-2017-5645	9,8	Critical	2.0-alpha1	2.8.1	2.8.2
x	CVE-2021-45046	9,0	Critical	2.0-beta9	2.15.0 excluding 2.12.2	2.12.2/2.16.0
x	CVE-2021-44832	6,6	Medium	2.0-alpha7	2.17.0, excluding 2.3.2/2.12.4	2.3.2/2.12.4/2.17.1
x	CVE-2021-45105	5,9	Medium	2.0-beta9	2.16.0, excluding 2.12.3	2.3.1/2.12.3/2.17.0
-	CVE-2020-9488	3,7	Low	2.0	2.13.1/2.12.1/2.3.1	2.13.2/2.12.3/2.3.2

log4J 1.x

detect	CVE	CVSSv3	Severity	lib from	lib to	lib fix	comment
x	CVE-2019-17571	9,8	Critical	1.2.0	1.2.17	nofix
x	CVE-2021-4104	7,5	High	1.2.0	1.2.17	nofix
x	CVE-2022-23302	8,8	High	1.0.1	1.2.17	nofix
x	CVE-2022-23305	9,8	Critical	1.2.0	1.2.17	nofix
x	CVE-2022-23307	9,8	Critical	1.0	1.2.17	nofix	same as CVE-2020-9493
-	CVE-2020-9488	3,7	Low	1.2.0	1.2.17	nofix

reload4j

Fork log4J 1.x reload4j (2022-01-12 - first release reload 4 about project 1.2.18.0 ) with the elimination of security vulnerabilities, released as a new version in the log4j 1 branch.x while maintaining backward compatibility (not considering hardening)

detect	CVE	CVSSv3	Severity	lib from	lib to	lib fix	comment
x	CVE-2019-17571	9,8	Critical	none	none	1.2.18.0
x	CVE-2021-4104	7,5	High	none	none	1.2.18.0	(JMSAppender) fixed by hardening the components
x	CVE-2022-23302	8,8	High	1.2.18.0	1.2.18.0	1.2.18.1	(JMSSink) - fixed by hardening the component
x	CVE-2022-23305	9,8	Critical	1.2.18.0	1.2.18.1	1.2.18.1	(JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection
x	CVE-2022-23307	9,8	Critical	1.2.18.0	1.2.18.0	1.2.18.1	same as CVE-2020-9493, (Chainsaw) - fixed by hardening the component
-	CVE-2020-9488	3,7	Low	1.2.18.0	1.2.18.2	1.2.18.3

Other CVEs

Other CVEs require the same approach (search and parse) as log4j just contained in other products.

detect	CVE	CVSSv3	Severity	product name	lib from	lib to	lib fix	comment
-	CVE-2020-9493	9,8	Critical	Apache Chainsaw	2.0	2.1.0	2.1.0	this vulnerability does not apply to log4j, it is a Apache chainsaw vulnerability
-	CVE-2021-42550	6,6	Medium	logback	1.0	1.2.9	1.2.10	this vulnerability does not apply to log4j, it is a logback vulnerability

[HynekPetrak]

added support for CVE-2019-17571 (9.8)

[HynekPetrak]

note CVE-2017-5645 is already supported.

[HynekPetrak]

added support for CVE-2022-23307 (8.1)

[trust1345]

Fix CVE-2020-9488 place in the table (move to log4j 2.x).

[HynekPetrak]

added detection of CVE-2022-23305 (8.1)

[HynekPetrak]

With release I would rather wait for me fixing the false positives on reload4j:

[+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23307 (8.1)] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains Log4J-None <= 1.2.17
[+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.0.jar contains Log4J-1.2.18.0 <= 1.2.17

[HynekPetrak]

added detection of CVE-2022-23305, CVE-2022-23302 and proper handling of reload4j.

Detection of CVE-2022-23307 is equivalent to CVE-2020-9493

@trust1345 test on your dataset, please. I'm ready to make a release.\

My test case:

[-] [OLDSAFE]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.2.jar contains reload4j-1.2.18.2
[-] [OLDSAFE]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains reload4j-1.2.18.1
[+] [CVE-2019-17571 (9.8), CVE-2021-4104 (7.5), CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Package /home/hynek/war.bak/reload4j/log4j-1.2.17.jar contains log4j-1.2.17
[+] [CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.0.jar contains log4j-1.2.18.0
[+] [CVE-2022-23302 (6.6), CVE-2022-23305 (8.1), CVE-2022-23307 (8.1)]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.0/org/apache/log4j contains log4j-1.2.18.0
[-] [OLDSAFE]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.2/org/apache/log4j contains reload4j-1.2.18.2
[-] [OLDSAFE]  Folder /home/hynek/war.bak/reload4j/reload4j-1.2.18.1/org/apache/log4j contains reload4j-1.2.18.1

[trust1345]

[-] [OLDSAFE] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.2.jar contains reload4j-1.2.18.2
[-] [OLDSAFE] Package /home/hynek/war.bak/reload4j/reload4j-1.2.18.1.jar contains reload4j-1.2.18.1

https://reload4j.qos.ch/

2021-01-21 - Release of reload4j 1.2.18.2
• CVE-2022-23305 (JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection.
Thanks to the remarkable work of Vladimir Sitnikov JDBCAppender now interprets the SQL expression on the fly so as to insert new events using PreparedStartement instances. Note that the table column types are restricted to those types compatible with Java's String.

PS.
Updated the information in the table above. I tried not to forget anything. Maybe I missed something.

[trust1345]

@trust1345 test on your dataset, please. I'm ready to make a release.\

Checked the latest version from git, something went wrong I think.

sample2.zip

1	2	3	4	5
CVE-2021-44832 (6.6), CVE-2021-45105 (5.9), NOJNDILOOKUP	/opt/virtual/download/log4j/sample/add/fp/log4j-core-2.17.1.jar	contains log4j-core-2.17.1 == 2.16.0, JndiLookup.class not found	2.17.1	log4j-core
OLDSAFE	/opt/virtual/download/log4j/sample/add/com.oracle.ocm_1.0.0.0.jar	contains Oracle OCM 1.0 Fri Feb 20 19:26:55 EST 2009-1.0.0.0	1.0.0.0	Oracle OCM 1.0 Fri Feb 20 19:26:55 EST 2009
OLDSAFE	/opt/virtual/download/log4j/sample/add/emocmutl.jar	contains log4j-1.x	1.x	log4j
OLDSAFE	/opt/virtual/download/log4j/sample/add/log4j-boot.jar	contains JBoss [Trinity]-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20	4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20	JBoss [Trinity]
CVE-2021-44832 (6.6), CVE-2021-45105 (5.9), NOJNDILOOKUP	/opt/virtual/download/log4j/sample/add/fp/elasticsearch-sql-cli-6.8.23.jar	contains log4j-core-2.17.1 == 2.16.0, JndiLookup.class not found	2.17.1	log4j-core

[HynekPetrak]

2021-01-21 - Release of reload4j 1.2.18.2
• CVE-2022-23305 (JDBCAppender) - fixed by using JDBC PreparedStatement which are invulnerable to SQL injection.
Thanks to the remarkable work of Vladimir Sitnikov JDBCAppender now interprets the SQL expression on the fly so as to insert new events using PreparedStartement instances. Note that the table column types are restricted to those types compatible with Java's String.

They actually fixed the CVE-2022-23305 already in 1.2.18.1 by removing the JDBCAppender completely. In version 1.2.18.2 they brought it back hardened. So they way I'm reporting it, I believe, is correct.

[HynekPetrak]

@trust1345 I've possibly reworked the detection logic, still need to test before release. Please test on your side, if possible.

[trust1345]

They actually fixed the CVE-2022-23305 already in 1.2.18.1 by removing the JDBCAppender completely. In version 1.2.18.2 they brought it back hardened. So they way I'm reporting it, I believe, is correct.

OK, I agree

[trust1345]

Updated the table according to
2021-01-24 - Release of reload4j 1.2.18.3
add CVE-2020-9488 to log4j 1.x and reload4j

[trust1345]

@trust1345 I've possibly reworked the detection logic, still need to test before release. Please test on your side, if possible.

I doubt that

• com.oracle.ocm_1.0.0.0.jar
• emocmutl.jar
• log4j-boot.jar

(log4j-1.x)
From my previous comment ( https://github.com/HynekPetrak/log4shell-finder/files/7926399/sample2.zip ) do not contain CVE from the table.
It seems illogical that they have the status of OLDSAFE.

[HynekPetrak]

Why illogical? OLDSAFE is meant for log4j 1.x with no CVE. By definition

[trust1345]

Why illogical? OLDSAFE is meant for log4j 1.x with no CVE. By definition

For example, it says here (CVE-2022-23302)
https://lists.apache.org/thread/bsr3l5qz4g0myrjhy9h67bcxodpkwj4w

Description:
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104.

I think that just no one wants to dig into the old code to find out the details.
As for example with CVE-2020-9488, which did not appear in log4j 1.x until reload4j began to touch the code

But at the moment I have not found such information in the descriptions on reliable sources. Perhaps you should leave it like this, waiting until the analysis from nist is over

[HynekPetrak]

CVE-2021-4104 is a bug of JMSAppender class - in your example there is no JMSAppender, so it's not vulnerable to CVE-2021-4104. For every CVE I'm trying to identify the vulnerable piece of code and the patch applied in order to empirically check, whether that particular instance of log4j is vulnerable or not.

[trust1345]

Updated the table (nvd.nist.gov)
CVSS CVE-2022-23302 CVSS 6,6 -> CVSS 8,8
CVSS CVE-2022-23305 CVSS 8,1 -> CVSS 9,8
CVSS CVE-2022-23307 CVSS 8,1 -> CVSS 9,8