Rejected: com.sun.jndi.rmi.EvilClass Refusing to unmarshal com.sun.jndi.rmi.EvilClass for security reasons Refusing to marshal com.sun.jndi.rmi.EvilClass for security reasons
Each section covers the upgrade from the previous LTS release, the section on 2.19.1 covers the upgrade from 2.7.4.
The JNLP agent protocol configuration could not be loaded from disk after a Jenkins restart.
If you customized these settings since 2.19.1, review that they are configured as expected.
jenkins.model.Jenkins.slaveAgentPort againA regression in Jenkins 2.0 caused Jenkins to ignore the System property jenkins.model.Jenkins.slaveAgentPort.
The previous behavior has been restored, and a new System property jenkins.model.Jenkins.slaveAgentPort added that, if set, will enforce the JNLP agent port on every Jenkins startup, and will not allow the value to be changed through the UI.
It can still be changed via Groovy scripting for troubleshooting purposes, but any change will be reverted on startup.
The layout of job configuration screens will no longer break if users don’t insert extra line breaks to break long lines. Instead, the text box will allow horizontal scrolling.
The build history for specific agents has long caused numerous potentially long-running threads to spawn. This has been fixed.
A memory leak on the dashboard (view pages) was fixed, so that browser memory use will no longer grow unbounded.
The major part of the security fix is an expansion of the serialization blacklist 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 blacklisted packages will no longer work. This will be indicated by any of the following in exception messages in logs:
Rejected: com.sun.jndi.rmi.EvilClass Refusing to unmarshal com.sun.jndi.rmi.EvilClass for security reasons Refusing to marshal com.sun.jndi.rmi.EvilClass for security reasons
In these examples, com.sun.jndi.rmi.EvilClass is a placeholder for a real class name.
It is possible to customize the blacklist 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 blacklist overriding the default one.
The default blacklist is defined in ClassFilter.java in the remoting component. In a configuration file as used for hudson.remoting.ClassFilter.DEFAULTS_OVERRIDE_LOCATION, the default blacklist 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[.].*
To check whether any given class name is blacklisted, run the following command in Manage Jenkins » Script Console, replacing com.sun.jndi.rmi.EvilClass with the class name you want to check:
hudson.remoting.ClassFilter.DEFAULT.isBlacklisted('com.sun.jndi.rmi.EvilClass')
Removing or relaxing entries on this blacklist 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.
Another change in Jenkins 2.19.3 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.
CLI over HTTP (when the JNLP port is disabled) now works with CSRF protection enabled and does not need explicitly setting hudson.diyChunking. So any workarounds applied for previous versions of Jenkins to make the CLI work can now be reverted.
Previous versions allowed Jenkins to run with invalid plugin configurations. For example, plugins depending on other plugins were loaded even if those dependencies were outdated, or disabled. This could result in difficult to debug errors at run time.
Now, Jenkins will refuse to load plugins with unsatisfied dependencies. Diagnostic messages explaining this will be written to the Jenkins log during startup, and we strongly recommend monitoring that after upgrading.
A long-standing problem with JavaScript-heavy configuration forms was that submitting a form, then using the web browser Back button to return to the form resulted in the wrong form contents. Submitting the form again would then result in unexpectedly broken configuration.
To work around this problem, we disabled autocompletion for almost all form fields.
The Configure Global Security form now includes options to enable/disable specific agent protocol versions, along with short descriptions of each protocol. There is no general guidance on when to customize the status of specific protocols, but it may be needed in the future.
By default, new Jenkins 2 instances will have the JNLP agent port disabled. As this is a requirement for the JNLP Web Start launch method for build agents to work, this form option will now be hidden if the port is disabled. To make it show up, just enable the JNLP agent port in the Global Security Configuration.