-
Notifications
You must be signed in to change notification settings - Fork 173
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
CVE-2021-44832: RCE in log4j 2.17.0 #218
Comments
Do we know if a newer version to detect this new vulnerability will be released as well? |
Thanks @xeraph appreciate it - will let you know. Do you happen to know if there's one to run for 32bit? |
@naudob No.. graalvm does not support native image build for 32bit. Use JAR version instead. |
Love this tool! - Was curious since deleting the JDBCAppender class would mitigate CVE-2021-44832, why not make that a switch in the tool for users to have a temporary mitigation while they work on getting the full patch? |
@miyou361 Unlike JMSAppender, JDBC logging is more common configuration. I need more user feedback. |
Tested on a few servers. Successfully detected 2.17 version on them.
|
@xeraph @arnarthor88 I also had a similar question. If we ran the previous version for mitigations up to 2.16, does that mean they are mitigated for this new vulnerability since the files were archived or do we need to run the new one to remove certain files for this new vulnerability? Thanks |
@arnarthor88 The scanner just check version. @naudob If you already ran scanner and fixed 2.16 or below log4j 2.x binaries or log4j 1.x binaries, there is no futher mitigation patch. |
Thanks @xeraph appreciate your great work. So just to confirm if I have a server and I ran the previous Logpresso version where it detects up to to 2.15 or 2.16, and my current server does not have version 2.17, I do not need to re-run again? Thank you |
@naudob Sure. |
@xeraph - Understood on increased potential app breakage due to more broad use of JDBCAppender, hence suggestion as making it an option (flag) to remove just like v1 fix. One item along this same train of thought is that I believe a number of people may not understand what specific CVE's are actually mitigated when the fix flag and v1 flag is set, so I've taking a stab at it here: The following CVE's are NOT mitigated by any of the current tool fix options:
The following CVE's ARE mitigated when all current fix flags are used:
Might be helpful to slightly modify the project overview text to directly state which items are only detected, vs which ones can be mitigated with the tool. I welcome correction on the above if appropriate. |
@miyou361 Added |
log4j 2.17.1 has been released to resolve CVE-2021-44832, a new RCE
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
The text was updated successfully, but these errors were encountered: