+
https://en.wikipedia.org/wiki/Road_signs_in_Singapore[ +
image:https://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Singapore_Road_Signs_-_Restrictive_Sign_-_Stop_-_Security_Check.svg/240px-Singapore_Road_Signs_-_Restrictive_Sign_-_Stop_-_Security_Check.svg.png[image] +
]

+
+

 +
I suspect many of you have been impacted by https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271[CVE-2014-6271] (aka "shellshock" bash vulnerability.) We had our share of updates to do for various *.jenkins-ci.org servers. +
 +

 +
Java application servers in general (including one that ships in Jenkins) do not fork off processes like Apache does to serve requests, so the kind of CGI attacks you see on Apache does not apply. We are currently unaware of any vulnerabilities in Jenkins related to CVE-2014-6271, and no plan to issue a patch for that. +
 +

 +
That said, we did come up with one possible way attackers can exploit vulnerable bash through Jenkins, that you might want to be aware of. +
 +

 +
When a build is parameterized, parameters are passed to the processes Jenkins launch as environment variables. So if you have a shell step (which uses `+bash+` by default), and if Eve only has a BUILD permission but not CONFIGURE permission, then Eve can exploit this vulnerability by carefully crafting parameter values, and have the bash runs arbitrary processes on the agent that run the build. +
 +

 +
In most such scenarios, Eve would have to be an authenticated user on Jenkins. Jenkins also leaves the record of who triggered what build with what parameters, so there's an audit trail. But if your Jenkins fits this description, hopefully this serves as one more reason to update your bash. +
 +

 +
Finally, to get notified of future security advisories from Jenkins, see https://wiki.jenkins.io/display/JENKINS/Security+Advisories[this Wiki page].