Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logpresso identifies CVE-2021-4104 in reload4j #271

Open
fipro78 opened this issue Feb 4, 2022 · 6 comments
Open

logpresso identifies CVE-2021-4104 in reload4j #271

fipro78 opened this issue Feb 4, 2022 · 6 comments
Assignees
Labels
discussion question or suggestion patch released

Comments

@fipro78
Copy link

fipro78 commented Feb 4, 2022

reload4j is a drop-in replacement intended to fix the latest security issues.
https://reload4j.qos.ch/

They have fixed CVE-2021-4104 by hardening, not by removing the class. logpresso does anyhow report the CVE-2021-4104 vulnerability.

I have created a ticket in the reload4j repository:
qos-ch/reload4j#36

The question is, how is the check in logpresso for CVE-2021-4104 implemented and is the CVE really still present or fixed by hardening? Would be great to have a consistent view on this to avoid confusions by adopters.

@xeraph
Copy link
Contributor

xeraph commented Feb 4, 2022

@fipro78 It's most likely a false positive of scanner. I will investigate it.

@xeraph xeraph self-assigned this Feb 4, 2022
@xeraph xeraph added discussion question or suggestion patch released labels Feb 4, 2022
@xeraph
Copy link
Contributor

xeraph commented Feb 5, 2022

@fipro78 v2.9.2 release will detect vulnerabilities from old version of reload4j like this:

[?] Found CVE-2022-23302 (log4j 1.2) vulnerability in d:\tmp2\reload4j-1.2.18.0.jar, log4j 1.2.18.0
[?] Found CVE-2022-23305 (log4j 1.2) vulnerability in d:\tmp2\reload4j-1.2.18.1.jar, log4j 1.2.18.1
[?] Found CVE-2020-9488  (log4j 1.2) vulnerability in d:\tmp2\reload4j-1.2.18.2.jar, log4j 1.2.18.2

Scanner will not detect vulnerability for reload4j 1.2.18.3 or above version.

@fipro78
Copy link
Author

fipro78 commented Feb 10, 2022

@xeraph thanks for fixing this. I tested it and it works as intended for the artefacts from Maven Central.

Eclipse is re-bundling the artefact from Maven to add jar signing. The content otherwise is the same. But logpresso identifies the CVE again, because the pom.properties file is located in another folder structure, which is caused by the re-bundling:

_META-INF\maven\org.eclipse.orbit.bundles\org.apache.log4j_

The re-bundled artefact is available in the integration build of Eclipse Orbit:

https://download.eclipse.org/tools/orbit/downloads/drops/I20220210065320/

The name of the artefact changed to org.apache.log4j_1.2.19.

Would it be possible to add the handling for the re-bundled version also?

@xeraph
Copy link
Contributor

xeraph commented Feb 13, 2022

@fipro78 Would you test v3.0.1 release? It will detect also re-bundled reload4j version.

@fipro78
Copy link
Author

fipro78 commented Feb 14, 2022

@xeraph I downloaded the latest reload4j jars (Maven Central and re-bundled Eclipse Orbit) and the latest logpresso 3.0.1 for Windows. It now works as expected, the vulnerabilities are not detected anymore.

Thanks for the fast reaction!

@xeraph
Copy link
Contributor

xeraph commented Feb 14, 2022

@fipro78 Thank you for test report! :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion question or suggestion patch released
Projects
None yet
Development

No branches or pull requests

2 participants