fkie_cve-2025-27148
Vulnerability from fkie_nvd
Published
2025-02-25 21:15
Modified
2025-02-25 21:15
Severity ?
8.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Summary
Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class<>)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe. Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the "sticky" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only.
References
security-advisories@github.comhttps://en.wikipedia.org/wiki/Fstab#Options_common_to_all_filesystems
security-advisories@github.comhttps://en.wikipedia.org/wiki/Sticky_bit
security-advisories@github.comhttps://github.com/gradle/gradle/pull/32025
security-advisories@github.comhttps://github.com/gradle/gradle/security/advisories/GHSA-465q-w4mf-4f4r
security-advisories@github.comhttps://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336
security-advisories@github.comhttps://github.com/gradle/native-platform/blob/574dfe8d9fb546c990436468d617ab81c140871d/native-platform/src/main/java/net/rubygrapefruit/platform/internal/NativeLibraryLocator.java#L68-L78
security-advisories@github.comhttps://github.com/gradle/native-platform/pull/353
security-advisories@github.comhttps://github.com/gradle/native-platform/security/advisories/GHSA-2xxp-vw2f-p3x8
Impacted products
Vendor Product Version


To clipboard 

{
   cveTags: [],
   descriptions: [
      {
         lang: "en",
         value: "Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.\n\nIn net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class<>)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.\n\nGradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the \"sticky\" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the \"sticky\" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only.",
      },
      {
         lang: "es",
         value: "Gradle es una herramienta de automatización de compilación y su herramienta de plataforma nativa proporciona enlaces Java para API nativas. En sistemas tipo Unix, el directorio temporal del sistema se puede crear con permisos abiertos que permiten que varios usuarios creen y eliminen archivos dentro de él. Esta inicialización de la librería podría ser vulnerable a una escalada de privilegios local por parte de un atacante que elimine y vuelva a crear rápidamente archivos en el directorio temporal del sistema. Las compilaciones de Gradle que dependen de versiones de net.rubygrapefruit:native-platform anteriores a 0.22-milestone-28 podrían ser vulnerables a una escalada de privilegios local por parte de un atacante que elimine y vuelva a crear rápidamente archivos en el directorio temporal del sistema. En net.rubygrapefruit:native-platform anterior a la versión 0.22-milestone-28, si se llamaba al método `Native.get(Class&lt;&gt;)`, sin llamar primero a `Native.init(File)`, con un argumento distinto de `null` utilizado como ruta de archivo de trabajo, la librería se inicializaría a sí misma utilizando el directorio temporal del sistema y las líneas 68 a 78 de NativeLibraryLocator.java. La versión 0.22-milestone-28 se ha publicado con cambios que solucionan el problema. La inicialización ahora es obligatoria y ya no utiliza el directorio temporal del sistema, a menos que se pase dicha ruta para la inicialización. El único workaround para las versiones afectadas es asegurarse de realizar una inicialización adecuada, utilizando una ubicación que sea segura. Gradle 8.12, solo esa versión exacta, tenía rutas de código donde la inicialización de la librería de integración nativa subyacente tomaba una ruta predeterminada, dependiendo de la copia de los binarios al directorio temporal del sistema. Cualquier ejecución de Gradle exponía esta vulnerabilidad. Los usuarios de Windows o versiones modernas de macOS no son vulnerables, como tampoco lo son los usuarios de un sistema operativo tipo Unix con el bit \"sticky\" configurado o \"noexec\" en su directorio temporal del sistema. Este problema se solucionó en Gradle 8.12.1. La versión Gradle 8.13 también se actualiza a una versión de la librería nativa que ya no tiene ese error. Hay algunas soluciones alternativas disponibles. En sistemas operativos tipo Unix, asegúrese de que el bit \"sticky\" esté configurado. Esto solo permite que el usuario original (o root) elimine un archivo. Montar \"/tmp\" como \"noexec\" evitará que se inicie Gradle 8.12. Aquellos que no puedan cambiar los permisos del directorio temporal del sistema pueden mover el directorio temporal de Java configurando la propiedad del sistema java.io.tmpdir. La nueva ruta debe limitar los permisos solo al usuario de compilación.",
      },
   ],
   id: "CVE-2025-27148",
   lastModified: "2025-02-25T21:15:18.073",
   metrics: {
      cvssMetricV31: [
         {
            cvssData: {
               attackComplexity: "LOW",
               attackVector: "LOCAL",
               availabilityImpact: "HIGH",
               baseScore: 8.8,
               baseSeverity: "HIGH",
               confidentialityImpact: "HIGH",
               integrityImpact: "HIGH",
               privilegesRequired: "LOW",
               scope: "CHANGED",
               userInteraction: "NONE",
               vectorString: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
               version: "3.1",
            },
            exploitabilityScore: 2,
            impactScore: 6,
            source: "security-advisories@github.com",
            type: "Secondary",
         },
      ],
   },
   published: "2025-02-25T21:15:18.073",
   references: [
      {
         source: "security-advisories@github.com",
         url: "https://en.wikipedia.org/wiki/Fstab#Options_common_to_all_filesystems",
      },
      {
         source: "security-advisories@github.com",
         url: "https://en.wikipedia.org/wiki/Sticky_bit",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/gradle/pull/32025",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/gradle/security/advisories/GHSA-465q-w4mf-4f4r",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/native-platform/blob/574dfe8d9fb546c990436468d617ab81c140871d/native-platform/src/main/java/net/rubygrapefruit/platform/internal/NativeLibraryLocator.java#L68-L78",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/native-platform/pull/353",
      },
      {
         source: "security-advisories@github.com",
         url: "https://github.com/gradle/native-platform/security/advisories/GHSA-2xxp-vw2f-p3x8",
      },
   ],
   sourceIdentifier: "security-advisories@github.com",
   vulnStatus: "Awaiting Analysis",
   weaknesses: [
      {
         description: [
            {
               lang: "en",
               value: "CWE-378",
            },
            {
               lang: "en",
               value: "CWE-379",
            },
         ],
         source: "security-advisories@github.com",
         type: "Primary",
      },
   ],
}


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.