Entre los dos fallos corregidos en la
última iteración del popular sistema de control de versiones, uno permite la
ejecución de código arbitrario a través del clonado recusivo de un repositorio.
El pasado día 29 el equipo de
desarrollo de Git lanzaba una nueva versión que corrige dos vulnerabilidades.
La primera, con identificador CVE-2018-11233, trata un fallo en las pruebas de
validez de rutas en sistemas NTFS que permite leer zonas de memoria aleatorias.
La segunda (CVE-2018-11235) es la que
llama especialmente la atención. A través de un fichero .gitmodules
especialmente manipulado es posible ejecutar código arbitrario en la maquina
que esté clonando un repositorio junto a sus submódulos.
En Git, el proceso de descarga inicial
de un repositorio se denomina clonado. Durante este proceso, cierta información
no se incluye en la copia local del repositorio. Un ejemplo son los hooks
(scripts que se ejecutan al realizarse acciones concretas). Estos son definidos
en la versión local de cada usuario, evitando por ejemplo que un repositorio
recién clonado ejecute comandos en el equipo del usuario.
Por otro lado, tenemos los submdulos.
Estos son utilizados para incluir repositorios de otros proyectos dentro de
otro que los requiere. Cuando se clona un repositorio, se pueden clonar sus
submódulos automáticamente usando el comando 'git clone --recurse-submodules'.
El comportamiento normal de este
comando es clonar tanto el repositorio padre como su submódulo, dejando hooks y
otras configuraciones fuera de la versión local de ambos. Pero en esta
vulnerabilidad se presenta una forma de evitarlo. Primero, se define un
submódulo dentro de un repositorio padre, pero además se incluye el código y la
configuración del submódulo. De esta forma nos saltamos el proceso de clonado
del submódulo (el código ya existe en nuestra versión local) y permitimos a los
hooks viajar dentro del repositorio descargado.
Una vez con la definición de los hooks
en la máquina del usuario, solo necesitamos que se apunten a ellos para
ejecutarlos. Desgraciadamente, existe un error en la validación del parámetro
'name' en la configuración de Git que permite definir dónde residen los hooks
que son ejecutados. Se podría definir, por ejemplo, que se ejecutaran los hooks
que residen en '../submodulo/.git/'. De esta forma, un atacante remoto podría
crear un repositorio especialmente manipulado y ejecutar código arbitrario en
nuestro sistema a través de un repositorio Git malicioso.
La vulnerabilidad, que ha sido
descubierta por Etienne Stalmans, ya ha sido solucionada en las versiones
v2.17.1, v2.13.7, v2.14.4, v2.15.2 y v2.16.4 de Git. Sin embargo, dada la gran
cantidad de sistemas que usan Git como base, aun queda trabajo por delante. Por
ejemplo, en Kubernetes esta vulnerabilidad permitiría obtener permisos de
superusuario en un nodo usando volumenes GitRepo.
Más
información:
·
Git
v2.17.1 Release Notes: https://marc.info/?l=git&m=152761328506724&w=2
·
Remediating
the May 2018 Git Security Vulnerability: https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/
Fuente: Hispasec.com