Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-34871

After upgrading to Jenkins 2.3 we are unable to trigger parametrized build (SECURITY-170 / CVE-2016-3721)

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • win server host
      Jenkins version 2.3
      Parameterized Trigger plugin version 2.30

      After upgrading to Jenkins 2.3 we are not able to pass a custom parameter specified in a property file. It looks like there is a security feature in this versions (https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11) that disables simply passing build parameters.

      This makes no sense to me since in my configuration (attached picture - config.jpg) I explicitly specify that I need to trigger the build with predefined properties.
      Maybe I am missing something?

      I tried to get the suggested solution working on slave level (passed java -Dhudson.model.ParametersAction.safeParameters=myParam) to slave start-up but this does not work. It looks like this needs to be passed when we start the master but this is no workaround. We simply have a lot of parameters and we cannot pass them to master at start-up.
      Again - maybe I am missing something in this workaround?

          [JENKINS-34871] After upgrading to Jenkins 2.3 we are unable to trigger parametrized build (SECURITY-170 / CVE-2016-3721)

          Daniel Beck added a comment -

          This is one plugin whose breakage is deliberate, and in fact the whole point of the security update. It allowed users of one job (Job A) to provide arbitrary arguments to a different job (Job B), even if the creator of Job B doesn't define those parameters. This enables a number of attacks, the most generic being the one described in broad strokes using PATH in the advisory.

          The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters.

          Daniel Beck added a comment - This is one plugin whose breakage is deliberate, and in fact the whole point of the security update. It allowed users of one job (Job A) to provide arbitrary arguments to a different job (Job B), even if the creator of Job B doesn't define those parameters. This enables a number of attacks, the most generic being the one described in broad strokes using PATH in the advisory. The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters.

          Adi Adrian added a comment -

          I do not understand-is there any plan to fix this issue?For me it is critical,I cannot update Jenkins from version 2.2 as my projects triggering parameterized build on other projects will not work.I just tried the version 2.8 and the same problem appeared.
          I tried the suggestion:
          "The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters." by enabling in project B the option "This project is parameterized" and adding parameters with the same name as the one passed by the project A.
          In this case the issue dissapeared,parameters from project A were passed correctly to project B(tried Jenkins 2.8).
          But this means I need to change a lot of projects if I want to upgrade to a Jenkins version newer than 2.2.
          Isn't there any other solution than changing all the projects B (called by projects A)?

          Adi Adrian added a comment - I do not understand-is there any plan to fix this issue?For me it is critical,I cannot update Jenkins from version 2.2 as my projects triggering parameterized build on other projects will not work.I just tried the version 2.8 and the same problem appeared. I tried the suggestion: "The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters." by enabling in project B the option "This project is parameterized" and adding parameters with the same name as the one passed by the project A. In this case the issue dissapeared,parameters from project A were passed correctly to project B(tried Jenkins 2.8). But this means I need to change a lot of projects if I want to upgrade to a Jenkins version newer than 2.2. Isn't there any other solution than changing all the projects B (called by projects A)?

          Lars added a comment -

          Besides that, adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project.

          Lars added a comment - Besides that, adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project.

          Daniel Beck added a comment -

          But this means I need to change a lot of projects if I want to upgrade to a Jenkins version newer than 2.2.
          Isn't there any other solution than changing all the projects B (called by projects A)?

          Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior.

          adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project.

          It's not possible for Jenkins to distinguish between "intended" additional parameters and "unintended" additional parameters, and since they're used to override environment variables, the safe approach is to not allow them. But I wouldn't be surprised if there's a plugin out there that provides an 'invisible' parameter type that can only be customized by launching programmatically. Possibly this one, but haven't tested it.

          Daniel Beck added a comment - But this means I need to change a lot of projects if I want to upgrade to a Jenkins version newer than 2.2. Isn't there any other solution than changing all the projects B (called by projects A)? Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior. adding the parameters to a project causes them to be editable by the user in case of a manual build. In some cases this is not intended. Some parameters are only needed when triggered by another project. It's not possible for Jenkins to distinguish between "intended" additional parameters and "unintended" additional parameters, and since they're used to override environment variables, the safe approach is to not allow them. But I wouldn't be surprised if there's a plugin out there that provides an 'invisible' parameter type that can only be customized by launching programmatically. Possibly this one , but haven't tested it.

          Lars added a comment -

          Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior.

          Always? https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11 said this is "intended as a short-term workaround only".

          Thank you for proposing the Hidden Parameter Plugin. I didn't know it. I will give it a try.

          Lars added a comment - Well, you can always disable this protection mechanism. It's specifically for existing instances that for one reason or another need to rely the existing behavior. Always? https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11 said this is "intended as a short-term workaround only". Thank you for proposing the Hidden Parameter Plugin. I didn't know it. I will give it a try.

          Claus Schneider added a comment - - edited

          It is also possible to turn the bucket upside-down.. I have played with a patch for the envinject plugin that regex-based retrieve parameters from upstream build. This way B is reading A and not A pushing to B..
          This way parameters just need to be stored in A's environment. You do not need to use parameterized trigger - but any upstream/downstream trigger

          How does this sound?

          Claus Schneider added a comment - - edited It is also possible to turn the bucket upside-down.. I have played with a patch for the envinject plugin that regex-based retrieve parameters from upstream build. This way B is reading A and not A pushing to B.. This way parameters just need to be stored in A's environment. You do not need to use parameterized trigger - but any upstream/downstream trigger How does this sound?

          Same when trying to use "Use properties from file"

          Albert Shamsiyan added a comment - Same when trying to use "Use properties from file"

          Doron Shai added a comment -

          When we will have a fix for it?
          When i downgraded to 2.19.4 i still have this problem

          Doron Shai added a comment - When we will have a fix for it? When i downgraded to 2.19.4 i still have this problem

          Brian Herrera added a comment - - edited

          "The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters."
          By enabling in project B the option "This project is parameterized" and adding parameters with the same name as the one passed by the project A.

          Confirming this worked for me.

          Brian Herrera added a comment - - edited "The correct way to handle this is to extend your triggered/downstream jobs (every "Job B") to accept additional parameters." By enabling in project B the option "This project is parameterized" and adding parameters with the same name as the one passed by the project A. Confirming this worked for me.

          After adding "-Dhudson.model.ParametersAction.keepUndefinedParameters=true" to /etc/sysconfig/jenkins file in jenkins-2.46.3-1.1.noarch version. It works. Since it has reported as a security fix. Can we have a permanent fix for this bug?

           

           

          Santhosh Kumar added a comment - After adding "-Dhudson.model.ParametersAction.keepUndefinedParameters=true" to /etc/sysconfig/jenkins file in jenkins-2.46.3-1.1.noarch version. It works. Since it has reported as a security fix. Can we have a permanent fix for this bug?    

            vassilena Vassilena Treneva
            vassilena Vassilena Treneva
            Votes:
            16 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated: