Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas
Se dio a conocer el lanzamiento de las nuevas versiones correctivas de mantenimiento de Git v2.40.1, junto con versiones de mantenimiento para versiones anteriores v2.39.3, v2.38.5, v2.37.7, v2.36.6, v2.35.8,
v2.34.8, v2.33.8, v2.32.7, v2.31.8 , y v2.30.9, esto debido a que dada a conocer información de que fueron identificadas cinco vulnerabilidades en Git.
El lanzamiento de estas versiones de mantenimiento son con la finalidad de abordar los problemas de seguridad identificados como CVE-2023-25652, CVE-2023-25815 y CVE-2023-29007.
Sobre las vulnerabilidades de Git
La vulnerabilidad CVE-2023-29007 permite la sustitución de configuraciones en el archivo de configuración $GIT_DIR/config, que se puede usar para ejecutar código en el sistema especificando rutas a archivos ejecutables en las directivas core.pager, core.editor y core.sshCommand.
La vulnerabilidad se debe a un error lógico debido a que los valores de configuración muy largos pueden tratarse como el comienzo de una nueva sección al cambiar el nombre o eliminar una sección de un archivo de configuración.
En la práctica, la sustitución de los valores de explotación se puede lograr especificando direcciones URL de submódulos muy largas que se guardan en el archivo $GIT_DIR/config durante la inicialización. Estas URL se pueden interpretar como nuevas configuraciones cuando se intenta eliminarlas a través de «git submodule deinit».
Otra de las vulnerabilidades, es CVE-2023-25652 que permite sobrescribir el contenido de los archivos fuera del árbol de trabajo al procesar parches especialmente diseñados con el comando «git apply –reject«. Si intenta ejecutar un parche malicioso con el comando «git apply» que intenta escribir en un archivo a través de un enlace simbólico, la operación será rechazada.
Por su parte, la vulnerabilidad CVE-2023-25815: cuando Git se compila con soporte de prefijo de tiempo de ejecución y se ejecuta sin mensajes traducidos, todavía usaba la maquinaria gettext para mostrar mensajes, que posteriormente potencialmente buscaban mensajes traducidos en lugares inesperados. Esto permitió colocación maliciosa de mensajes manipulados.
En Git 2.39.1, la protección contra la manipulación de enlaces simbólicos se ha ampliado para bloquear parches que crean enlaces simbólicos e intentan escribir a través de ellos. La esencia de la vulnerabilidad en cuestión es que Git no tuvo en cuenta que el usuario puede ejecutar el comando «git apply –reject» para escribir las partes rechazadas del parche como archivos con la extensión «.rej» y el atacante puede utilice esta función para escribir el contenido en un directorio arbitrario, en la medida en que lo permitan los derechos de acceso actuales.
Además, se han solucionado tres vulnerabilidades que aparecen solo en Windows:
- CVE-2023-29012: (busca el ejecutable doskey.exe en el directorio de trabajo del repositorio al ejecutar el comando «Git CMD», que permite organizar la ejecución de su código en el sistema del usuario)
- CVE-2023 -25815: desbordamiento de búfer al procesar archivos de localización personalizados en gettext. Esta vulnerabilidad afecta a los usuarios que trabajan en máquinas Windows a las que otras partes que no son de confianza tienen acceso de escritura. Por lo general, todos los usuarios autenticados tienen permiso para crear carpetas en C:\, lo que permite que actores maliciosos inyecten mensajes incorrectos en git.exe.
- CVE-2023-29011: posibilidad de sustituir el archivo connect.exe cuando se trabaja a través de SOCKS5. La ubicación del archivo de configuración de connect.exe está codificada en una ruta que generalmente se interpreta como C:\etc\connectrc, que es susceptible de manera similar a la anterior.
Como solución alternativa para protegerse contra las vulnerabilidades, se recomienda evitar ejecutar el comando «git apply –reject» cuando se trabaja con parches externos no verificados y verificar el contenido de $GIT_DIR/config antes de ejecutar los comandos «git submodule deinit«, «git config –rename-section» y «git config –remove-section» cuando se trata de repositorios que no son de confianza.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Para los interesados en seguir el lanzamiento de las actualizaciones de los paquetes en distribuciones, pueden hacerlo en las páginas de Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD.