Vulnerabilidad en Gradle (CVE-2025-27148)

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<>)`, 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.