Issue
-
We have been able to confirm an unauthenticated remote code execution vulnerability in Jenkins (all versions) with CLI enabled.
Resolution
The recommended resolution, as described in the CloudBees Jenkins Security Advisory 2016-11-16 is upgrading to the releases that include the fix:
-
CloudBees Jenkins Operations Center 2.7.x.y (Rolling Train) should be upgraded to 2.7.21.1.
-
CloudBees Jenkins Operations Center 2.7.x.0.y (Fixed Train) should be upgraded to 2.7.21.0.1
-
CloudBees Jenkins Operations Center 1.625.x.y should be upgraded to 1.625.21.1
-
CloudBees Jenkins Enterprise 2.7.x.y (Rolling Train) should be upgraded to 2.7.21.1
-
CloudBees Jenkins Enterprise 2.7.x.0.y (Fixed Train) should be upgraded to 2.7.21.0.1
-
CloudBees Jenkins Enterprise 1.651.x.y should be upgraded to 1.651.21.1
-
CloudBees Jenkins Enterprise 1.642.x.y should be upgraded to 1.642.21.1
-
Jenkins LTS should be upgraded to 2.19.3
-
Jenkins main line should be upgraded to Jenkins 2.32
Expansion of the Serialization Denylist
The major part of the security fix is an expansion of the serialization denylist used for remoting (Jenkins CLI and master/agent communication) and Xstream (XML configuration and data files).
It is possible that legitimate uses of classes in denylisted packages will no longer work. This will be indicated by any of the following in exception messages in logs:
Rejected: com.sun.rmi.EvilClass Refusing to unmarshal com.sun.rmi.EvilClass for security reasons Refusing to marshal com.sun.rmi.EvilClass for security reasons
In these examples, com.sun.rmi.EvilClass is a placeholder for a real class name.
It is possible to customize the denylist used by setting the hudson.remoting.ClassFilter.DEFAULTS_OVERRIDE_LOCATION System property for the Jenkins controller java invocation.
It is expected to be set to the path to a file containing a complete, custom denylist overriding the default one.
The default denylist is defined in ClassFilter.java in the remoting component.
In a configuration file as used for hudson.remoting.ClassFilter.DEFAULTS_OVERRIDE_LOCATION, the default denylist would look like this:
bsh[.].*
^com[.]google[.]inject[.].*
^com[.]mchange[.]v2[.]c3p0[.].*
^com[.]sun[.]jndi[.].*
^com[.]sun[.]corba[.].*
^com[.]sun[.]javafx[.].*
^com[.]sun[.]org[.]apache[.]regex[.]internal[.].*
^java[.]awt[.].*
^java[.]rmi[.].*
^javax[.]management[.].*
^javax[.]naming[.].*
^javax[.]script[.].*
^javax[.]swing[.].*
^org[.]apache[.]commons[.]beanutils[.].*
^org[.]apache[.]commons[.]collections[.]functors[.].*
^org[.]apache[.]myfaces[.].*
^org[.]apache[.]wicket[.].*
.*org[.]apache[.]xalan.*
^org[.]codehaus[.]groovy[.]runtime[.].*
^org[.]hibernate[.].*
^org[.]python[.].*
^org[.]springframework[.](?!(\p{Alnum}+[.])*\p{Alnum}*Exception$).*
^sun[.]rmi[.].*
Removing or relaxing entries on this denylist must be done carefully as to not open yourself up to known exploits. A possible alternative could be to disable the CLI via HTTP and JNLP agent port (see below) to prevent its unauthenticated use.
Disabling the CLI
Another change in the released versions is the new feature to disable the CLI over HTTP and JNLP by setting the
System property jenkins.CLI.disabled to true.
This is a more convenient alternative to run the Groovy script provided as a workaround to SECURITY-218 and SECURITY-360
for users who do not want to allow unauthenticated access to the Jenkins CLI even with the security fix.
While the CLI can be used using the Jenkins integrated SSH daemon as well, this requires authentication, so it’s not a vector for unauthenticated attacks. To disable this feature as well, disable the SSH server port in Manage Jenkins » Configure Jenkins » SSH Server.