An unauthenticated remote code execution vulnerability was discovered in the Jenkins continuous integration and continuous delivery automation server. A serialized Java object transferred to the Jenkins CLI can make Jenkins connect to an attacker-controlled LDAP server, which in turn can send a serialized payload leading to code execution, bypassing existing protection mechanisms. Upstream advisory: https://groups.google.com/forum/#!msg/jenkinsci-advisories/-fc-w9tNEJE/GRvEzWoJBgAJ CVE assignment: http://seclists.org/oss-sec/2016/q4/423 Mitigation: https://github.com/jenkinsci-cert/SECURITY-218
Created jenkins tracking bugs for this issue: Affects: fedora-all [bug 1395174]
External References: https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-11-16
I've looked at our Jenkins container images (from/for OpenShift) and I am *not* recommending respins of those images. While mentioned in the `EXPOSE` list, port 50000 (the CLI port) is only available to the outside world if the user either explicitly maps it (`-p 50000:X`) or uses the always-a-bad-idea `-P`. In OpenShift, port 50000 is not automatically exposed via `oc expose svc/jenkins-X-rhel7` as only the web interface (8080) is listed in the `openshift.io.expose-services` label and routed to. In other words: the CLI is by default only exposed within the private network on vanilla Docker and only within the cluster by default on vanilla OpenShift. This lowers the risk to moderate within these context and---in my judgement---below the threshold needed to require respins. _Trevor