Desde Linux Darkcrizt  

Se dio a conocer una segunda vulnerabilidad crítica en GitLab en menos de una semana

Gitlab

Gitlab sufre de un segundo problema de seguridad en menos de una semana

En menos de una semana los desarrolladores de Gitlab han tenido que poner manos a la obra, pues hace pocos días se lanzaron las actualizaciones correctivas de GitLab Collaborative Development Platform 15.3.1, 15.2.3 y 15.1.5 que llegaron a resolver una vulnerabilidad crítica.

Catalogada bajo CVE-2022-2884, esta vulnerabilidad podría permitir que un usuario autenticado con acceso a la API de importación de GitHub ejecute código de forma remota en un servidor. Aún no se han dado detalles operativos. La vulnerabilidad fue identificada por un investigador de seguridad como parte del programa de recompensas por vulnerabilidades de HackerOne.

Como solución temporal, se recomendó al administrador que deshabilite la función de importación desde GitHub (en la interfaz web de GitLab: «Menú» -> «Administrador» -> «Configuración» -> «General» -> «Controles de visibilidad y acceso» -> «Importar fuentes» -> deshabilitar «GitHub»).

Posterior a ello y en menos de una semana GitLab publico la próxima serie de actualizaciones correctivas para su plataforma de desarrollo colaborativo: 15.3.2, 15.2.4 y 15.1.6, que corrige la segunda vulnerabilidad crítica.

Catalogada bajo CVE-2022-2992, esta vulnerabilidad permite a un usuario autenticado ejecutar código de forma remota en un servidor. Al igual que la vulnerabilidad CVE-2022-2884 que se solucionó hace una semana, existe un nuevo problema en la API para importar datos del servicio GitHub. La vulnerabilidad se manifiesta, entre otras cosas, en los releases 15.3.1, 15.2.3 y 15.1.5, en los que se solucionó la primera vulnerabilidad en el código de importación desde GitHub.

Aún no se han dado detalles operativos. La vulnerabilidad se envió a GitLab como parte del programa de recompensas por vulnerabilidades de HackerOne, pero a diferencia del problema anterior, fue identificada por otro colaborador.

Como solución temporal, se recomienda al administrador que deshabilite la función de importación desde GitHub (en la interfaz web de GitLab: «Menú» -> «Administrador» -> «Configuración» -> «General» -> «Controles de visibilidad y acceso» -> «Importar fuentes» -> deshabilitar «GitHub»).

Además, las actualizaciones propuestas corrigen 14 vulnerabilidades más, dos de las cuales están marcadas como peligrosas, diez tienen un nivel de gravedad medio y dos están marcadas como no peligrosas.

Las siguientes son reconocidas como peligrosas: la vulnerabilidad CVE-2022-2865, que le permite agregar su propio código JavaScript a las páginas que se muestran a otros usuarios a través de la manipulación de etiquetas de color,

Fue posible explotar una vulnerabilidad al configurar la función de color de las etiquetas que podría conducir a un XSS almacenado que permitía a los atacantes realizar acciones arbitrarias en nombre de las víctimas en el lado del cliente. 

Otra de las vulnerabilidades que se solucionó con la nueva serie de correcciones, es la CVE-2022-2527, que hace posible sustituir su contenido a través del campo de descripción en la línea de tiempo de la escala de Incidentes). Las vulnerabilidades de gravedad media están relacionadas principalmente con la posibilidad de denegación de servicio.

La falta de validación de longitud en las descripciones de Snippet en GitLab CE/EE que afecta a todas las versiones anteriores a la 15.1.6, todas las versiones a partir de la 15.2 anterior a la 15.2.4, todas las versiones a partir de la 15.3 anterior a la 15.3.2 permite que un atacante autenticado cree un Snippet maliciosamente grande que, cuando se solicita con o sin autenticación, genera una carga excesiva en el servidor, lo que puede provocar una denegación de servicio.

De las otras vulnerabilidades que fueron solucionadas:

  • El registro de paquetes no respeta completamente la lista de IP permitidas del grupo, GitLab no estaba realizando la autenticación correcta con algunos Registros de paquetes cuando se configuraron las restricciones de dirección IP, lo que permitía que un atacante que ya poseía un token de implementación válido lo usara indebidamente desde cualquier ubicación.
  • Abusar de las llamadas Gitaly.GetTreeEntries conduce a la denegación de servicio, permitieron un usuario autenticado y autorizado para agotar los recursos del servidor al importar un proyecto malicioso.
  • Solicitudes HTTP arbitrarias posibles en .ipynb Notebook con etiquetas de formulario malicioso, que permite a un atacante emitir solicitudes HTTP arbitrarias.
  • Denegación de servicio de expresión regular a través de entrada especialmente diseñada, permitían a un atacante desencadenar un uso elevado de la CPU mediante una entrada diseñada añadida en el campo de mensaje Confirmar.
  • Divulgación de información a través de referencias GFM arbitrarias representadas en eventos de la línea de tiempo del incidente
  • Lea el contenido del repositorio a través de la función LivePreview: Era posible que un usuario no autorizado leyera el contenido del repositorio si un miembro del proyecto usaba un enlace manipulado.
  • Denegación de servicio a través de la API al crear una rama: El manejo inadecuado de datos en la creación de sucursales podría haberse utilizado para desencadenar un uso elevado de la CPU.
  • Denegación de servicio a través de la vista previa del problema

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.