Los investigadores de seguridad en profundidad publicaron por primera vez un código de explotación funcional el 24 de julio para una falla de GitLab que GitLab parchó seis semanas antes, el 10 de junio. Ejecuta comandos como git en cualquier autogestionado 18.11.3 servidor que no ha tomado la actualización.
Cualquier usuario autenticado que pueda acceder a un proyecto puede ejecutarlo. El atacante confirma un cuaderno Jupyter diseñado y abre su diferencia de confirmación, que filtra un puntero de montón. Si hay suficientes de ellos, una sonda automatizada podrá localizar las bibliotecas en la memoria. Luego, dos portátiles más disparan la carga útil. Sin derechos de administrador, sin acceso a CI o ejecutor, sin interacción con la víctima, sin acceso al proyecto de nadie más.
GitLab no presentó la solución como solución de seguridad. Una revisión de The Hacker News encontró que el DO 3.17.3 El problema figura en las correcciones de errores en la versión del parche del 10 de junio, no en la tabla de correcciones de seguridad. No hay CVE, ni puntuación CVSS, ni se menciona la cadena de diferencias del cuaderno. Los operadores que clasificaron esa liberación contra la mesa de seguridad no tenían motivos para tratarla como urgente.
Dos errores de corrupción de memoria en Oj, un analizador Ruby JSON implementado en gran medida en C nativo, hacen que la cadena funcione. Depthfirst dice que su sistema los marcó de forma autónoma y los investigadores los encadenaron a mano.
El renderizador de portátiles de GitLab, una joya en el árbol llamada ipynbdiffpasa controlado por repositorio .ipynb JSON a Oj::Parser.usual.parse dentro de un trabajador Puma de larga duración, por lo que los bytes controlados por el atacante llegan a la memoria C administrada manualmente por Oj dentro del proceso de aplicación.
Un error escribe más allá de una pila anidada fija de 1.024 bytes hasta que controla el análisis del analizador. start llamar de vuelta. El otro trunca una clave de objeto de 65.565 bytes a 29 en un campo firmado de 16 bits y devuelve un puntero de montón en vivo, que GitLab representa en la diferencia. La fuga localiza libc y la escritura apunta la devolución de llamada a system().
| Componente | Afectado | Primero arreglado |
|---|---|---|
| GitLabCE/EE | 15.2.0 al 18.10.7 | 18.10.8 |
| GitLabCE/EE | 18.11.0 al 18.11.4 | 18.11.5 |
| GitLabCE/EE | 19.0.0 a 19.0.1 | 19.0.2 |
| Oh espera | 3.13.0 a 3.17.1 | 3.17.3 |
Todos los niveles se ven afectados, CE y EE, desde Gratis hasta Ultimate. Ruby en sí no lo es. DO 3.17.2 Incluye otras correcciones de la misma revisión, pero no estas dos.
Actualizar a 18.10.8, 18.11.5o 19.0.2. Ni GitLab ni Depthfirst ofrecen una solución alternativa para quienes no pueden hacerlo.
La trampa es Helm y Operador: verifique la versión de GitLab dentro de la imagen del servicio web que ejecuta Puma, no la versión del gráfico o del Operador. Todo lo que esté entre 15.2 y 18.9 no tiene backport, porque esas líneas se encuentran fuera de los trenes de parches mantenidos por seguridad de GitLab, por lo que esas instalaciones deben pasar a una versión compatible.
Los comandos se ejecutan como gitla cuenta detrás de Puma. Hasta dónde llega eso depende de cómo esté aislada la instalación. Al alcance: código fuente, secretos de Rails, credenciales de servicio, datos de CI/CD y servicios internos con los que la aplicación puede comunicarse.
El exploit público está construido para GitLab 18.11.3 en x86-64. Las compensaciones de gadgets, el estado de registro y el comportamiento de jemalloc provienen de esa imagen, y una base de biblioteca recuperada se mantiene solo hasta que se reinicia el maestro Puma, por lo que esto no se aplica directamente a un objetivo arbitrario.
Los errores de Oj son generales; Portar el exploit es un verdadero trabajo. Depthfirst midió de cinco a diez minutos para la búsqueda de memoria en una instalación nueva de dos trabajadores y proyecta de una a dos horas en instalaciones de mayor duración. Su artículo tiene la cadena completa.
Depth informó por primera vez los errores de Oj el 21 de mayo, el mantenedor fusionó las correcciones el 27 de mayo y Oj 3.17.3 enviado el 4 de junio. La cadena GitLab llegó a GitLab el 5 de junio, se confirmó el 8 de junio y se parchó el 10 de junio. Depthfirst dice que no tiene conocimiento de la explotación en estado salvaje y que GitLab reprodujo el RCE de forma independiente. Su revisión más amplia del DO produjo nueve avisos CVE más, ninguno de ellos en esta cadena.
Hacker News preguntó a GitLab por qué la solución no se clasificó como un problema de seguridad y si se asignará un CVE, y preguntó en profundidad sobre la portabilidad del exploit. Las respuestas están pendientes.
