In response to the zero-day vulnerability we fixed in November, I wrote the following:
Moving forward, the Jenkins security team is revisiting the design of the Jenkins CLI over the coming weeks to prevent this class of vulnerability in the future. If you are interested in participating in that discussion, please join in on the jenkinsci-dev@ mailing list.
In early February, several project contributors met after FOSDEM for a one day hackathon. I looked into the feasibility of a purely SSH-based CLI. While I considered the experiment to be a success, it was far from ready to be used in a production environment.
A few weeks later, long-time contributor and Jenkins security team member Jesse Glick took over, and published a detailed proposal for a new, simple CLI protocol without remoting.
In just a month, he implemented his proposal, and I’m very happy to announce that this new implementation of the Jenkins CLI has now made it into 2.54!
Existing jenkins-cli.jar clients should continue working as before, unless an administrator disables the remoting connection mode in Configure Global Security.
That said, we recommend you download the new jenkins-cli.jar in Jenkins, and use its new -http mode.
With few (now deprecated) exceptions, CLI commands work like before.
This will allow you to disable the remoting mode for the CLI on the Jenkins controller to prevent similar vulnerabilities in the future.
SSH-based CLI use should be unaffected by this change. Note that new Jenkins instances now start with the SSH server port disabled, and the configuration option for that was moved into Configure Global Security.
You can learn all about the CLI and its new behavior in the Jenkins handbook.
|
Daniel Beck
Daniel is a Jenkins core maintainer and member of the Jenkins security team. He was the inaugural Jenkins security officer from 2015 to 2021. He sometimes contributes to developer documentation and project infrastructure in his spare time. |