Jenkins is an open source automation tool that is commonly used in the industry for CI tasks such as building and testing applications. It’s a powerful tool with many readily available plugins, so its popularity isn’t surprising.
From a security standpoint, the Jenkins team puts a great effort on both the core code and plugins. Jenkins follows good practices, from working with researchers to releasing timely advisories on all issues in Jenkins and plugins. A list of past vulnerabilities can be found in their advisories page.
In this post I’ll unpack one vulnerability that caught my attention in the latest advisory. The advisory listed two issues in the GitHub Pull Request Builder (ghprb) plugin. For the first issue the advisory suggested manual intervention (i.e. running their script) to fully remedy the dangers of that issue.
The Ghprb plugin is used to trigger a Jenkins job when a pull request is created in a GitHub project. It’s not a very complicated plugin, it can be configured to detect pull requests either by using a periodic task or by using GitHub webhooks for automatic triggering.
Prior to the fix in Ghprb 1.40.0, the plugin stored GitHub credentials in the build.xml file that is created on build jobs, in plaintext.
Jenkins typically encrypts and secures credentials to protect credentials from being easily stolen. After running a build job with the vulnerable plugin, the GitHub username and password can be read from the a file by users with sufficient access to the Jenkins machine, unlike other Jenkins credentials.
Given that filesystem access is needed to extract the credentials from the build file, I wouldn’t flag this as a major vulnerability, but in some specific setups this could be dangerous, for example when there are multiple users working with the same Jenkins instance. The credentials themselves are stored in the build file in an XML entry, in basic HTTP authentication format. In other words, if you open a bad build file, you can find your credentials in the form of “username:password” encoded in Base64:
... Basic ZmFrZTpmYWtlcGFzcw== ...
In any regard, I certainly recommend all affected users to run Jenkins’ fix script to delete all the bad build files.
The vulnerability itself was likely discovered due to a bug with Jenkins 2.102 release (JENKINS-48950). Ironically enough I found this bug when trying to reproduce the issue as I was reading the advisory. After configuring the plugin, builds were successfully triggered by pull requests on my GitHub repository, but I could not find any build.xml files on my machine. As it turns out, the plugin broke builds on newer Jenkins versions because of this issue.
The vulnerability was assigned SECURITY-261 by the Jenkins team and later got CVE-2018-1000142.
Keep yourself up-to-date
In this short post I only explained one plugin vulnerability. But keep in mind that new vulnerabilities are found and fixed in Jenkins and Jenkins plugins all the time. For all other issues please find the matching security advisories to catch up on the details.
As for the GitHub Pull Request Builder, upgrade to 1.40.0, get the dangerous files deleted, and keep on waiting for the next advisory.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Baking Compliance in your CI/CD PipelineRead the Blog
Serverless Security Suggestions: Tips for Keeping Serverless Functions SecureRead the Blog
Why a Common Security Toolset is Essential for DevSecOpsRead the Blog
Putting the “Ops” in DevSecOps: Why It’s Hard and How to Do ItRead the Blog
Why the Point Solution Mindset for IT Security is DeadRead the Blog