MarkEWaite Jenkins Governance Board
The security team has provided more details in the Jira ticket tracking fixes in the affected plugins. If you’d like to know more about the affected versions of Apache Log4j 2, see
The security team has provided more details in the Jira ticket tracking fixes in the affected plugins. If you’d like to know more about the affected versions of Apache Log4j 2, see
Same instructions apply. Open the script console, paste in that groovy script, and confirm the output says “No such property”.
Jenkins 2.235.x is vulnerable to other issues. See the security advisories for more details
I am using Jenkins version 2.320 on Centos 8.3. I find the following file present on the system: /var/cache/jenkins/war/WEB-INF/lib/log4j-over-slf4j-1.7.32.jar
I have performed the Groovy check for plugins which yielded the negative result listed above.
Can you please explain the use of this file in the Jenkins core (given the statement above), and why it is/is not vulnerable to CVE-2021-44228.
1 reply
og4j-over-slf4j is an adapter JAR that allows projects to migrate from log4j to slf4j (Log4j Bridge) :
SLF4J ship with a module called log4j-over-slf4j . It allows log4j users to migrate existing applications to SLF4J without changing a single line of code but simply by replacing the log4j.jar file with log4j-over-slf4j.jar , as described below.
The jar is (I can only guess) a holdover from when Jenkins used to use log4j and migrated to slf4j.
From http://slf4j.org/log4shell.html:
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
Which would mean you just need to ensure the actual log4j 2.x jar is not there.
1 reply
Thank you. I have confirmed that there is no log4j on the system, neither 1.x nor 2.x.
# find / -type f -name "*log4j*"
# yum list installed | grep -i log4
#
You have multiple high and critical vulnerabilities. I would worry about those before I’d worry about log4j.
I ran the: org.apache.logging.log4j.core.lookup.JndiLookup.class.protectionDomain.codeSource
Received: groovy.lang.MissingPropertyException: No such property: org for class: Script1
with a stack trace. Yet I have a vulnerable version of log4j located at:
/opt/jenkins/.m2/repository/org/apache/logging/log4j/log4j-core/2.14.1
I’m running 2.303.3.
Anyone have a clue why or how I can get rid of or upgrade this?
Thanks!
1 reply
See the reply from @batmat in the Jenkins user mailing list.
That file location is a cache maintained by Apache Maven. If that is your Jenkins controller, it likely means that you’re making the mistake of building on the Jenkins controller. Don’t do that. Reasons why are described in
Can someone please confirm how to check if Jenkins is affected by similar less critical vulnerability CVE-2021-4104 ?
1 reply
The National Vulnerability Database says
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration (emphasis added). … Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default
Jenkins core makes no mention of JMSAppender. I believe it is not configured to use JMSAppender.
If you’re granting write access to the Jenkins Log4j configuration on your Jenkins controller, I believe that means you have granted write access to the Jenkins home directory. If you’ve given someone write access to the Jenkins home directory, they are assumed to be trusted.
Note, I’m not part of the security team, so my assessment may be incorrect, but as far as I can tell, Jenkins is not vulnerable to that issue.
We have log4j vulnerabilities in our Jenkins instance. Our plugins looks fine. Nonetheless, the following appears in our scan:
The version of Apache Log4j on the remote host is 2.x < 2.15.0. It is, therefore, affected by a remote code execution vulnerability in the JDNI parser due to improper log validation. An unauthenticated, remote attacker can exploit this to bypass authentication and execute arbitrary commands. \n\nLog4j 1.x, which reached its End of Life prior to 2016, comes with JMSAppender which will perform a JNDI lookup if enabled in Log4j’s configuration file, hence customers should evaluate triggers in 1.x based on the risk that it is EOL and whether JNDI lookups are enabled.\n\nNote that Nessus has not tested for these issues but has instead relied only on the application’s self-reported version number.
How should this be resolved?
1 reply
As was stated in the other thread. Jenkins doesn’t use log4j, so its not vulnerable to log4j exploits. The blog post your replying to lists ways to test if your install has it. To remedy things, uninstall any plugins that are using it. Or update and hope said plugins got fixed.