Investigador publica GitLab RCE PoC que permite a usuarios autenticados ejecutar comandos como Git – CYBERDEFENSA.MX
El investigador de seguridad Yuhang Wu en Depthfirst ha publicado un exploit de prueba de concepto (PoC) funcional que ejecuta comandos como git en un GitLab autoadministrado sin parches 18.11.3 servidor.
Un usuario autenticado normal lo activa confirmando dos cuadernos Jupyter diseñados y solicitando su diferencia. La cadena no necesita derechos de administrador, acceso al corredor de integración continua (CI), interacción con la víctima ni acceso al proyecto de otro usuario.
El exploit público es específico de GitLab. 18.11.3 en x86-64; los errores subyacentes de Oj afectan versiones más amplias. Las gamas afectadas son GitLab Community Edition (CE) y Enterprise Edition (EE). 15.2.0 a través de 18.10.7, 18.11.0 a través de 18.11.4y 19.0.0 a través de 19.0.1.
Las primeras versiones fijas son 18.10.8, 18.11.5y 19.0.2. Oj es un analizador JSON de alto rendimiento para Ruby con importante código C nativo.
Gemas publicadas 3.13.0 a través de 3.17.1 son vulnerables; 3.17.3 es la primera versión publicada que contiene ambas correcciones. Las fallas afectan a Free, Premium y Ultimate. Ruby en sí no se ve afectado.
La explotación exitosa se ejecuta como git. Su alcance efectivo depende del aislamiento de la implementación, pero puede incluir código fuente, secretos de Rails, credenciales de servicio, datos de CI/CD y servicios internos accesibles desde la aplicación. GitLab.com fue parcheado el 10 de junio.
Los clientes dedicados no necesitan ninguna acción. Los operadores autogestionados deben pasar a una versión compatible que contenga la solución. Los usuarios de Helm y Operador deben verificar la versión de GitLab dentro de la imagen del servicio web, no solo el gráfico o la versión del Operador. Depthfirst dijo que no tenía conocimiento de explotación en estado salvaje hasta el 24 de julio.
Ni el primera revelación en profundidad ni las notas de la versión de GitLab del 10 de junio enumeran identificadores CVE o puntuaciones CVSS para los dos errores de la cadena. Ninguno de los dos proporciona una solución temporal; ambos dirigen a los operadores autogestionados a actualizarse.
Hacker News ha preguntado a GitLab sobre el estado, la clasificación y la evidencia de explotación de CVE. También preguntó en profundidad sobre la portabilidad de los exploits y si existe una mitigación temporal compatible. Las respuestas están pendientes. Depthfirst enumera nueve CVE para otras fallas del DO encontradas en la misma revisión.
El renderizador de portátiles de GitLab pasa controlado por el repositorio .ipynb JSON a Oj::Parser.usual.parse Dentro de un longevo trabajador de Puma. Eso envía datos del cuaderno controlado por el atacante al estado de analizador nativo de Oj dentro del proceso de solicitud de GitLab.
profundidad primero análisis técnico muestra cómo un error controla un puntero de devolución de llamada, mientras que el otro filtra una dirección de montón necesaria para limitar la búsqueda de aleatorización del diseño del espacio de direcciones (ASLR).
Oj almacena el estado de anidamiento en una pila fija de 1024 bytes, pero nunca comprueba si la profundidad la excede. Por lo tanto, los arreglos profundamente anidados pueden escribir 0x01 bytes en el estado del analizador adyacente. El exploit corrompe buf.headlo que hace que Oj pase un puntero interior falsificado a realloc(). Una asignación posterior de Ruby Array recupera la misma región jemalloc de 3584 bytes y sobrescribe p->start.
Oj asigna una clave de objeto de 65.565 bytes, trunca su longitud a 29 en un campo firmado de 16 bits y devuelve 29 bytes que contienen el puntero de asignación de claves en vivo. GitLab lleva ese puntero a la diferencia del cuaderno renderizado, dándole al exploit la fuga de dirección necesaria para limitar la búsqueda de ASLR. En el GitLab perfilado de dos trabajadores 18.11.3 instalación, la búsqueda solía tardar entre cinco y diez minutos. Los investigadores proyectaron de una a dos horas en el rango más amplio de trabajadores maduros.
Dos archivos de cuaderno ordenados léxicamente en uno diffs_stream La solicitud mantiene ambas etapas dentro del mismo trabajador Puma, que reutiliza el analizador Oj de proceso global. El primer archivo corrompe la devolución de llamada y genera un error que GitLab detecta antes de continuar con la diferencia. El siguiente análisis invoca el puntero sobrescrito y llega system() a través de una secuencia de gadgets específica de la construcción.
El manifestación pública empaqueta la cadena en un GitLab local 18.11.3 laboratorio x86-64 y hace que el trabajador de Puma se conecte nuevamente como git.
Depth informó por primera vez los errores de Oj el 21 de mayo, y el mantenedor fusionó las correcciones el 27 de mayo. DO 3.17.3 enviado el 4 de junio. Los investigadores informaron sobre la cadena GitLab el 5 de junio; Depthfirst dijo que GitLab lo confirmó el 8 de junio.
GitLab lanzó las versiones fijas el 10 de junio y resolvió el informe el 17 de julio, según profundidadprimero. Una revisión de The Hacker News encontró que GitLab enumeró el DO 3.17.3 aparece debajo de las correcciones de errores en lugar de en la tabla de correcciones de seguridad y no describe la cadena RCE de diferencias del cuaderno.
