Trellix automatiza la corrección de vulnerabilidades de código abierto a escala
Se han solucionado más de 61,000 brechas y contando
Trellix ha parcheado más de 61 000 proyectos de código abierto contra un error grave de Python con la ayuda de una herramienta automatizada que acelera drásticamente el proceso.
El año pasado, el equipo del Centro de Investigación Avanzada de Trellix se encontró con un problema debilidad de 15 años Incluido en el módulo tarfile de Python. es visto como CVE-2007-4559la vulnerabilidad se describe como un problema de cruce de ruta que permite a los “atacantes remotos asistidos por el usuario” sobrescribir archivos arbitrarios a través de “.. (punto) secuencias en nombres de archivo en un archivo TAR”.
ANTECEDENTES El error de cruce de ruta de archivo Tarfile de 2007 todavía existe en 350k repositorios de código abierto
Según el investigador de Trellix, Douglas McKee, la falla de seguridad se informó en 2017 pero “no ha sido investigada” ni abordada. Como resultado, la vulnerabilidad se incluyó sin saberlo en aproximadamente 350 000 proyectos de código abierto y se considera “propagada” en muchos proyectos de código cerrado.
Sin embargo, como se documenta en un entrada en el blog El 23 de enero, Trellix está trabajando con GitHub para contener la falla, una tarea difícil cuando tantos proyectos son vulnerables.
El módulo tarfile sensible está incluido en el paquete principal de Python […] también está firmemente integrado en la cadena de suministro de muchos proyectos sin modificación directa de Python”, dice la empresa de ciberseguridad.
Dirigido por Kasimir Schulz y Charles McFarland, el proyecto de meses de duración se centró en parchear automáticamente los repositorios de código abierto que contenían código sensible.
Tácticas de solicitud de extracción masiva
Aparentemente, la inspiración vino de él. Presentación DEFCON 2022 de Jonathan Leitschuhdiscutió el uso de la generación automatizada de consultas por lotes como una metodología escalable para parchear las vulnerabilidades de código abierto.
Trellix y GitHub separaron el proceso en dos fases, ambas automatizadas y solo requerían ejecución, dejando el control de calidad y la aceptación a los propietarios del proyecto.
El primer paso fue desarrollar el propio parche. Trellix recuperó una lista de repositorios y archivos que contenían la palabra clave “importar archivo tar” y luego clonó y analizó cada repositorio. Creosota.
“Si se encuentra que un repositorio contiene una vulnerabilidad, parcheamos el archivo y creamos una diferencia de parche local que contiene el archivo parcheado para que los usuarios puedan comparar fácilmente los dos archivos, el archivo original y algunos metadatos sobre el repositorio”, explicó McKee. .
RELACIONADO Corrección de vulnerabilidades comunes a escala: el proyecto promete requisitos masivos
Durante la fase de solicitud de extracción, el equipo de seguridad cibernética creó bifurcaciones de repositorio, las clonó y reemplazó el archivo original con una versión parcheada si el archivo original no había cambiado. Esta verificación se implementó para evitar que los parches ignoren o sobrescriban las adiciones recientes al código del proyecto.
Finalmente, el archivo se confirma, se crea una solicitud de extracción y se envía un mensaje que explica la bifurcación y le pide al propietario que acepte o rechace los cambios.
Acercarse
Hablando a trago diarioKasimir Schulz, investigador de vulnerabilidades en el Centro de Investigación Avanzada de Trellix, dijo que Creosote y el parche juntos pueden realizar escaneos del repositorio, detectar el error y aplicar el parche en segundos, mientras que incluso el desarrollador más hábil tardaría minutos en hacerlo. sin la ayuda de una herramienta.
“Si bien esta diferencia puede no ser tan significativa para algunos almacenes, puede volverse perceptible rápidamente a medida que aumenta la escala”, señaló Schulz.
A través de GitHub, el equipo de Trellix ha creado 61 895 proyectos de código abierto hasta la fecha.
Schulz dijo que las discusiones recientes en ShmooCon han creado un “nuevo impulso” para parchear la vulnerabilidad en Python, y que “incluso se puede ofrecer una recompensa financiera por una solución”.
Schulz concluyó: “El software y las cadenas de suministro son cada vez más complejos. Hay muchas más personas y empresas que crean toneladas de software diferente. Por lo tanto, tratar de reducir la superficie de ataque es una batalla perdida. En su lugar, deberíamos centrarnos en auditar nuestras propias cadenas de suministro a través de herramientas automatizadas, proporcionando una superficie de ataque, en lugar de perder el tiempo en una batalla imposible de ganar.
TAMBIÉN PODRÍA GUSTARTE La auditoría de seguridad de Git revela errores críticos de inundación
