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

DurableTaskStep experimental USE_WATCHING breaks secret masking

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • hashicorp-vault-plugin
    • None
    • jenkins/jenkins:lts-jdk11 (linux image deployed in k8s)
      workflow-durable-task-step-plugin 1199.v02b_9244f8064
      hashicorp-vault-plugin 356.ved18810a_b_828

      When using org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=true the sample will show the credentials instead of masking them.

      Sample:

      pipeline {
          agent {
              kubernetes {
              }
          }
      
          stages {
              stage('test') {
                  steps {
                      withVault(
                          [
                              [
                                  path: 'some/path',
                                  secretValues: [
                                      [vaultKey: 'foo'],
                                  ]
                              ]
                          ]
                      ) {
                          sh 'echo $foo'
                      }
                  }
              }
          }
      }
      

      Using kubernetes agent just for simplicity, but remote call is mandatory. When using controller node, masking is also done correctly.

      Sadly this setting gets enabled by a static code block in opentelemetry-plugin: https://github.com/jenkinsci/opentelemetry-plugin/blob/master/src/main/java/io/jenkins/plugins/opentelemetry/job/log/OtelLogStorageFactory.java#L50

          [JENKINS-69781] DurableTaskStep experimental USE_WATCHING breaks secret masking

          Jesse Glick added a comment -

          withCredentials is tested to work, so I presume a mistake in withVault (which probably should not exist).

          Jesse Glick added a comment - withCredentials is tested to work, so I presume a mistake in withVault (which probably should not exist).

          Shawn added a comment -

          Is there any ETA for a fix for CVE-2023-33001?

          Shawn added a comment - Is there any ETA for a fix for CVE-2023-33001 ?

          Mark Waite added a comment -

          shawnmcginn, when the Jenkins security team publishes an advisory with an unresolved vulnerability, like SECURITY-3077 for the Hashicorp Vault plugin, they follow the process described in announcing unresolved vulnerabilities:

          In case of a plugin vulnerability, we try to contact the plugin maintainer(s) to inform them of it. If they decline (or otherwise fail) to fix the vulnerability, or don’t respond in a timely manner, and the security team doesn’t have the capacity to fix it, we follow the process outlined below in the interest of our users:

          1. Publish a security advisory about the plugin, describing the nature of the vulnerability, but noting that there is no fix (other than no longer using the plugin). If there are workarounds, explain them.
          2. In some cases of particularly severe vulnerabilities, stop publishing the vulnerable plugin on the Jenkins update sites.
          3. Add metadata to update sites to inform administrators on the Jenkins UI about vulnerable plugins they have installed.
          4. Display security warnings on the plugins site.

          This allows Jenkins administrators to make an informed decision about their continued use of plugins with unresolved security vulnerabilities.

          Since the security team contacted the maintainers of the plugin and the maintainers did not fix the vulnerability, I think it is safe to assume there is no timeline for a fix of the vulnerability.

          If that plugin is important to your organization, you could propose to your organization that they allow you or someone in your organization to adopt the plugin, fix the vulnerability, and release a new version of the plugin with the fix. That would resolve the issue for your organization and improve the plugin for others.

          Mark Waite added a comment - shawnmcginn , when the Jenkins security team publishes an advisory with an unresolved vulnerability, like SECURITY-3077 for the Hashicorp Vault plugin, they follow the process described in announcing unresolved vulnerabilities : In case of a plugin vulnerability, we try to contact the plugin maintainer(s) to inform them of it. If they decline (or otherwise fail) to fix the vulnerability, or don’t respond in a timely manner, and the security team doesn’t have the capacity to fix it, we follow the process outlined below in the interest of our users: Publish a security advisory about the plugin, describing the nature of the vulnerability, but noting that there is no fix (other than no longer using the plugin). If there are workarounds, explain them. In some cases of particularly severe vulnerabilities, stop publishing the vulnerable plugin on the Jenkins update sites. Add metadata to update sites to inform administrators on the Jenkins UI about vulnerable plugins they have installed. Display security warnings on the plugins site. This allows Jenkins administrators to make an informed decision about their continued use of plugins with unresolved security vulnerabilities. Since the security team contacted the maintainers of the plugin and the maintainers did not fix the vulnerability, I think it is safe to assume there is no timeline for a fix of the vulnerability. If that plugin is important to your organization, you could propose to your organization that they allow you or someone in your organization to adopt the plugin , fix the vulnerability, and release a new version of the plugin with the fix. That would resolve the issue for your organization and improve the plugin for others.

            ptierno Peter Tierno
            scddev Dietmar Scheidl
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: