Jenkins builds of GitLab branches stopped working due to security patch

There have been some security patches to Jenkins recently, which have stopped some plugins from working – in our case, the Gitlab Merge Request Builder Plugin.

Parameters that used to get passed in as part of a trigger to build a branch stopped being passed through.

Errors in the Jenkins build console output looked like this – you can see that ${gitlabSourceBranch} is not being replaced properly with the branch name:

git config remote.refs/remotes/origin/${gitlabSourceBranch}.url # timeout=10

And the log file had lots of entries like this:

May 17, 2016 9:25:33 AM hudson.model.ParametersAction filter
WARNING: Skipped parameter `gitlabSourceBranch` as it is undefined on `knowmalaria-merge`. Set `-Dhudson.model.ParametersAction.keepUndefinedParameters`=true to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach

To get the branches building again, we had to update the parameters that the Jenkins server is started with.

In /etc/init.d/jenkins, set up a list of the parameters that the build will need :

# allow parameters to be passed in to gitlab builds

and pass those parameters to the process at startup:

# --user in daemon doesn't prepare environment variables like HOME, USER, LOGNAME or USERNAME,
# so we let su do so for us now

Then restart your Jenkins server:

sudo service jenkins restart

You may have a different list of parameters that need to be passed to the build – check the ‘parameters’ page for one of your previous builds.

See more description of the original security flaw here:

Validate your inputs

Todays podcast listening for the commute was Bruce Sams talking about web app security from Software Engineering Radio.

Starting with a live demo of some hacking techniques (surprisingly effective even with just the audio), it covers some of the popular attacks – SQL injection, javascript in input fields, cookie stealing, guessing adjacent ID numbers and so on.

Apparently about 70% of web app vulnerabilities come from the inputs to the system – we spend a lot of time worrying about things like SSL and encrypted logins, but actually the vast majority of attacks use the applications themselves.

Sams says that when he’s asked for his top 10 tips for making your web app secure, he says:

  1. Validate your inputs properly
  2. See (1).

An interesting aspect of validation, though, is that it applies not just the obvious things like form fields and text strings, but to all the HTTP header elements as well.

For example, WordPress MU (in versions prior to 2.7) had a function that would echo the HTTP Host header without having sanitised it. The attacker can craft a request that contains some Javascript in the Host header which, when echoed, can grab cookies (or other evil cross-site scripting stuff)..