ghsa-cm59-pr5q-cw85
Vulnerability from github
Published
2022-07-11 20:59
Modified
2022-07-11 20:59
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Summary
Temporary Directory Hijacking to Local Privilege Escalation Vulnerability in org.springframework.boot:spring-boot
Details

spring-boot versions prior to version v2.2.11.RELEASE was vulnerable to temporary directory hijacking. This vulnerability impacted the org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir method.

The vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation).

Impact Location

This vulnerability impacted the following source location:

java /** * Return the absolute temp dir for given web server. * @param prefix server name * @return the temp dir for given server. */ protected final File createTempDir(String prefix) { try { File tempDir = File.createTempFile(prefix + ".", "." + getPort()); tempDir.delete(); tempDir.mkdir(); tempDir.deleteOnExit(); return tempDir; } - https://github.com/spring-projects/spring-boot/blob/ce70e7d768977242a8ea6f93188388f273be5851/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/server/AbstractConfigurableWebServerFactory.java#L165-L177

This vulnerability exists because File.mkdir returns false when it fails to create a directory, it does not throw an exception. As such, the following race condition exists:

java File tmpDir =File.createTempFile(prefix + ".", "." + getPort()); // Attacker knows the full path of the file that will be generated // delete the file that was created tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. // and make a directory of the same name // SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown. // Attacker can write any new files to this directory that they wish. // Attacker can read any files created by this process.

Prerequisites

This vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

Patches

This vulnerability was inadvertently fixed as a part of this patch: https://github.com/spring-projects/spring-boot/commit/667ccdae84822072f9ea1a27ed5c77964c71002d

This vulnerability is patched in versions v2.2.11.RELEASE or later.

Workarounds

Setting the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.

Show details on source website

To clipboard 

{
   affected: [
      {
         database_specific: {
            last_known_affected_version_range: "<= 2.2.10.RELEASE",
         },
         package: {
            ecosystem: "Maven",
            name: "org.springframework.boot:spring-boot",
         },
         ranges: [
            {
               events: [
                  {
                     introduced: "0",
                  },
                  {
                     fixed: "2.2.11.RELEASE",
                  },
               ],
               type: "ECOSYSTEM",
            },
         ],
      },
   ],
   aliases: [
      "CVE-2022-27772",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-377",
         "CWE-379",
         "CWE-668",
      ],
      github_reviewed: true,
      github_reviewed_at: "2022-07-11T20:59:02Z",
      nvd_published_at: "2022-03-30T18:15:00Z",
      severity: "HIGH",
   },
   details: "spring-boot versions prior to version `v2.2.11.RELEASE` was vulnerable to temporary directory hijacking. This vulnerability impacted the `org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir` method.\n\nThe vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation).\n\n#### Impact Location\n\nThis vulnerability impacted the following source location:\n\n```java\n\t/**\n\t * Return the absolute temp dir for given web server.\n\t * @param prefix server name\n\t * @return the temp dir for given server.\n\t */\n\tprotected final File createTempDir(String prefix) {\n\t\ttry {\n\t\t\tFile tempDir = File.createTempFile(prefix + \".\", \".\" + getPort());\n\t\t\ttempDir.delete();\n\t\t\ttempDir.mkdir();\n\t\t\ttempDir.deleteOnExit();\n\t\t\treturn tempDir;\n\t\t}\n```\n\\- https://github.com/spring-projects/spring-boot/blob/ce70e7d768977242a8ea6f93188388f273be5851/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/server/AbstractConfigurableWebServerFactory.java#L165-L177\n\nThis vulnerability exists because `File.mkdir` returns `false` when it fails to create a directory, it does not throw an exception. As such, the following race condition exists:\n\n```java\nFile tmpDir =File.createTempFile(prefix + \".\", \".\" + getPort()); // Attacker knows the full path of the file that will be generated\n// delete the file that was created\ntmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.\n// and make a directory of the same name\n// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory\ntmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.\n// Attacker can write any new files to this directory that they wish.\n// Attacker can read any files created by this process.\n```\n\n### Prerequisites\n\nThis vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.\n\n### Patches\n\nThis vulnerability was inadvertently fixed as a part of this patch: https://github.com/spring-projects/spring-boot/commit/667ccdae84822072f9ea1a27ed5c77964c71002d\n\nThis vulnerability is patched in versions `v2.2.11.RELEASE` or later.\n\n### Workarounds\n\nSetting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.",
   id: "GHSA-cm59-pr5q-cw85",
   modified: "2022-07-11T20:59:02Z",
   published: "2022-07-11T20:59:02Z",
   references: [
      {
         type: "WEB",
         url: "https://github.com/JLLeitschuh/security-research/security/advisories/GHSA-cm59-pr5q-cw85",
      },
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2022-27772",
      },
      {
         type: "WEB",
         url: "https://github.com/spring-projects/spring-boot/commit/667ccdae84822072f9ea1a27ed5c77964c71002d",
      },
      {
         type: "PACKAGE",
         url: "https://github.com/spring-projects/spring-boot",
      },
   ],
   schema_version: "1.4.0",
   severity: [
      {
         score: "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
         type: "CVSS_V3",
      },
   ],
   summary: "Temporary Directory Hijacking to Local Privilege Escalation Vulnerability in org.springframework.boot:spring-boot",
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.