Vulnerabilidad de retorno de carro y RCE en Git

 (dgl.cx)
1 puntos por GN⁺ 2025-07-09 | 1 comentarios | Compartir por WhatsApp
  • Presentación de una técnica de ataque que aprovecha caracteres de retorno de carro dentro de un repositorio Git
  • Esta vulnerabilidad genera la posibilidad de ejecución remota de código (RCE)
  • Durante ciertos procesos de git clone se ejecutan comandos maliciosos
  • Se confirmó el impacto en entornos Linux y Windows
  • Se enfatiza el riesgo de una gestión insegura de repositorios Git

Caracteres de retorno de carro y vulnerabilidad en Git

  • Dentro de un repositorio Git se pueden crear nombres de archivo que incluyan caracteres de retorno de carro (\r)
  • Al clonar con git clone un repositorio que contiene esos nombres de archivo, durante el proceso de interpretación de comandos puede producirse la ejecución no intencional de comandos

Escenario de ejecución remota de código (RCE)

  • Un atacante agrega al repositorio y hace commit de un archivo con un carácter de retorno de carro insertado
  • Si un usuario hace git clone de ese repositorio, una interpretación incorrecta del sistema de archivos y de los comandos de git puede provocar el riesgo de ejecutar código no deseado
  • En particular, es posible inducir la ejecución automática de scripts de hooks (por ejemplo, código dentro de la carpeta .git/hooks)

Entornos afectados y respuesta

  • Puede ocurrir en git sobre varios sistemas operativos, incluidos Linux y Windows
  • Representa una grave amenaza de seguridad para desarrolladores y empresas que administran repositorios git o clonan con frecuencia repositorios externos

Recomendaciones de seguridad

  • Al clonar repositorios Git externos no confiables, es necesario usar la versión más reciente y verificar el estado de seguridad
  • Es necesario detectar y revisar antes de clonar los nombres de archivo que incluyan caracteres inusuales dentro del repositorio, especialmente retorno de carro y similares

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-09
Opinión de Hacker News

  • Todo esto termina causando un fenómeno al hacer un clone de submódulos: al leer se usa path = ..., pero al escribir se registra en otra ruta distinta que no termina en ^M

    • Se plantea la duda de cómo ocurre aquí exactamente la "ejecución remota de código" que menciona el artículo y qué tan grave es desde el punto de vista de seguridad

    • Aunque todavía no publicaron un PoC, mencionan que es casi una variación directa del exploit de CVE-2024-32002, y que las pruebas del commit que lo corrigió también dan pistas importantes

    • Citan la explicación de CVE-2024-32002: al manipular maliciosamente un repositorio con submódulos y aprovechar un bug de Git, se pueden escribir archivos en el directorio .git/ en vez del worktree del submódulo. Gracias a eso, es posible escribir hooks que se ejecutan inmediatamente durante el clone, sin que el usuario siquiera tenga oportunidad de inspeccionar el código que realmente va a ejecutarse

    • En resumen, se puede meter un hook malicioso de git en el repositorio, y aunque normalmente los hooks de git no se instalan con git clone, este ataque sí lo hace posible, abriendo la puerta a la ejecución de hooks durante el proceso de clonación

    • Se indica que hay más información sobre el nuevo CVE aquí

      • Al leer valores de configuración, Git elimina los caracteres CR y LF, pero al escribir no pone entre comillas el CR, lo que causa una pérdida al volver a leer
      • Si la ruta del submódulo termina con un carácter CR, se termina usando la ruta sin ese carácter, lo que puede hacer que el submódulo se haga checkout en una ubicación incorrecta
      • Si ya existe un symlink entre esa ruta truncada y el directorio de hooks del submódulo, un atacante puede lograr ejecución arbitraria de código mediante un hook post-checkout
      • Además de este CVE, comentan que hay muchas otras vulnerabilidades en Git que también vale la pena revisar

    • Mencionan esa verdad simple pero incómoda: si es posible escribir archivos arbitrarios, la mayoría de las veces eso termina convirtiéndose en RCE

  • Se menciona el riesgo de escribir archivos de configuración con un DSL ad-hoc

    • Muchas veces no existe una especificación formal de la sintaxis, y el criterio real de parseo queda repartido entre implementaciones caseras de serialización y deserialización

    • Si ambas se desalinean —por ejemplo, si se agrega nueva sintaxis al parser pero el writer no la refleja—, esa diferencia de parseo puede volverse una bomba

    • La lección sería: hace falta tener una sola source of truth y generar automáticamente a partir de ella las partes que dependan de eso

    • Señalan que este bug es independiente del problema de source of truth

      • Lo describen como un error lógico puro, algo que habría explotado igual si existiera una biblioteca estándar de sistema para esto en Unix
      • Si hubiera estado en una biblioteca estándar de ese tipo, el impacto habría sido mucho peor; ahora el daño es menor porque afecta sobre todo a desarrolladores

    • Opinan que el DSL usado aquí (formato de archivo ini), aunque sea ad-hoc, es muy común, familiar y bastante ordenado como para servir en la práctica como especificación suficiente

      • La esencia del bug no está en el formato, sino en el parser (o lexer) hardcodeado que quedó en medio, y sostienen que ya deberíamos dejar de escribir ese tipo de código
      • Todavía quedan algunos casos donde hace falta algo clever hecho a mano, pero nunca debería usarse para formatos de intercambio de datos; si hace falta ini, mejor toml; si no, JSON; incluso YAML; si de verdad se busca dolor, XML; y si alguien insiste en que necesita un formato binario, protobufs
      • En conclusión, salvo que seas autor de un lenguaje de programación, no deberías escribir tu propio parser y tendrías que usar bibliotecas sí o sí

  • Alguien reprodujo el problema directamente y lo subió a este repositorio

    • Intentó actualizar de inmediato a la versión más reciente de git, pero todavía no está disponible en Arch

    • Dice que va a evitar hacer pull hasta que salga un nuevo parche, y le preocupa que esto pueda afectar repositorios populares con pull automático, por lo que la actualización podría tardar bastante

    • Se preguntan si esta vulnerabilidad se hizo pública antes de que existiera parche

      • Antes, la mayoría de los artículos que explicaban cómo explotar una vulnerabilidad aparecían meses después de que ya estuviera parcheada; ahora quisieran que todas las publicaciones aclararan claramente, aunque sea de pasada, la diferencia entre "esto es realmente peligroso ahora mismo" y "ya está parcheado, no hay de qué preocuparse"

  • Al ver que se decía que solo se hizo una "variación simple" del exploit existente, se preguntan por qué Git no usa Landlock (una función de seguridad de sandbox exclusiva de Linux)

    • Plantean que una operación de git clone debería tener acceso de solo lectura al directorio de config, lectura/escritura al directorio destino del clone y prohibición de invocar subprocesos

    • Se burlan un poco de ese momento trillado donde todos los exploits siempre terminan abriendo la calculadora

    • Señalan el problema de que, si se prohíben los subprocesos, entonces se rompen todos los hooks de git como post-checkout

      • Si eso no hiciera falta, también se podría ejecutar git dentro de un entorno tipo contenedor con seccomp, pero muchas funciones quedarían limitadas

    • Y además, sin subprocesos tampoco se podría usar git por ssh

  • Preguntan si Homebrew en sí mismo es el problema, es decir, si hace recursive clone

    • Encuentran una posible pista en este código

    • Opinan que el objetivo mismo de Homebrew es ejecutar código del repositorio, así que sería casi raro que no hiciera recursive clone

      • El punto es que el RCE solo tiene relevancia cuando se ejecutan datos clonados que no deberían ejecutarse, y comentan que esos casos no son tan comunes

  • Al ver una cita famosa de Jon Postel sobre CR+LF, recuerdan viejos tiempos

    • Comparten este texto y evalúan que, comparado con 2003, quizá hoy ese consejo ya no sea el correcto
    • Lo conectan con la explicación que daba Mark Crispin en aquel entonces, según la cual la gente estaba entendiendo mal el asunto, y con los casos donde Daniel J. Bernstein señaló a fines de los años 90 los problemas que surgen en la conversión humano-máquina (parsing/quoting)
    • Observan que, incluso 25 años después, se sigue repitiendo el problema de código quoter que no hace escape de CR, y que aun después de corregirlo tampoco se revisa todo el whitespace
    • Según git blame, el código problemático fue escrito hace 19 años, casi coincidiendo con el aniversario número 10 de la retrospectiva de Bernstein
    • Comparten materiales adicionales como el commit relacionado y el paper de qmail
    • En definitiva, subrayan la realidad de que seguimos teniendo que reaprender en el siglo XXI las lecciones duramente aprendidas en el siglo XX

  • Parece que todavía no estaba disponible la actualización a git 2.50.1 en Homebrew, así que tocaría esperar un poco más

    • Recomiendan probar la actualización con este issue o con brew install git --HEAD

  • Comparten que tanto Homebrew como Debian Bookworm seguían ofreciendo versiones vulnerables

    • Luego avisan que Homebrew ya permite usar la versión 2.50.1

  • Se preguntan si una syscall que lista directorios, al encontrarse con nombres de archivo que contienen caracteres de control ASCII (bytes), debería negar la existencia de esos archivos, tratarlos como corrupción de disco o hacer otra cosa

    • Mencionan que esos bytes podrían tener otro significado según la locale actual, y que como no se asume que todos los nombres de archivo estén en UTF-16 como en Windows, pueden aparecer situaciones inesperadas

    • Responden brevemente que este problema existe porque, en sistemas tipo Unix, los nombres de archivo (y otras cadenas) son simplemente arreglos de bytes