search

qos-ch / reload4j

reload4j is a drop-in replacement for log4j 1.2.17
Apache License 2.0
148 stars 22 forks source link

CVE-2022-23307 #43

Closed zjfplayer closed 2 years ago

zjfplayer commented 2 years ago

We used the scanning platform to scan the latest 1.2.19 version of reload4j and found the following CRITICAL vulnerabilities

CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists. CWE-502 Deserialization of Untrusted Data

CVSSv2: Base Score: HIGH (10.0) Vector: /AV:N/AC:L/Au:N/C:C/I:C/A:C CVSSv3: Base Score: CRITICAL (9.8) Vector: /AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

For details, see https://nvd.nist.gov/vuln/detail/CVE-2022-23307

123Haynes commented 2 years ago

@zjfplayer That CVE has already been fixed in reload4j 1.2.18.1.

See https://github.com/qos-ch/reload4j/commit/64902fe18ce5a5dd40487051a2f6231d9fbbe9b0 for the commit and https://reload4j.qos.ch/ for the release notes.

ceki commented 2 years ago

@zjfplayer Thank you for your comments. May I ask which scanning tool is reporting the issue?

As @123Haynes observed, the deserialization CVE was solved in reload4j 1.2.18.1 by controlling the set of allowed deserialized types whereas chainsaw in log4j 2.x solves the issue by removing the LoggingReceiver class.

This difference might be confusing the scanning tool...

zjfplayer commented 2 years ago

@123Haynes @ceki Thank you for your replies. The scanning platform is an internal platform of our company. According to your reply, I communicated with the person in charge of the platform and it is true that this is a wrong report.