Trellix automatiza la aplicación de parches para 62 000 proyectos de código abierto vulnerables

Trellix y GitHub han reparado colectivamente un total de 61 895 proyectos de código abierto que se encontraron susceptibles a una vulnerabilidad de cruce de ruta de hace 15 años en el módulo tarfile de Python.

El equipo del Centro de Investigación Avanzada de la empresa destacó la prevalencia de CVE-2007-4559 en septiembre de 2022, luego de identificar que 15 años después de su descubrimiento, estaba en uso en aproximadamente 350,000 proyectos de código abierto y un número desconocido de código cerrado. unos.

El equipo tropezó con la vulnerabilidad mientras investigaba un problema no relacionado y al principio pensó que era un día cero completamente nuevo, pero después de que comenzaron a tirar del hilo, descubrieron que, de hecho, estaban buscando un error antiguo en el “extracto”. y funciones “extraer todo” en el módulo tarfile de Python.

Cuando se explota, CVE-2022-4559 permite que un atacante remoto asistido por el usuario sobrescriba archivos arbitrarios a través de una secuencia específica en los nombres de archivo en un archivo TAR, logrando la ejecución de código arbitrario o el control del dispositivo de destino.

En octubre de 2007, se consideró que el error era de poca importancia y sigue estando generalizado en múltiples marcos, incluidos algunos creados por Amazon Web Services, Google, Intel y Netflix, y muchas otras aplicaciones utilizadas para el aprendizaje automático, la automatización y la contenedorización de Docker. .

Doug McKee, ingeniero principal y director de investigación de vulnerabilidades de Trellix, dijo que desde entonces, el equipo ha estado trabajando en un esfuerzo de cuatro meses para automatizar la aplicación de parches a proyectos de código abierto vulnerables, inspirándose en una charla en DEFCON 2022 del investigador Jonathan Leitschuh. “A través de GitHub, los desarrolladores y los miembros de la comunidad pueden enviar código a proyectos o repositorios en la plataforma a través de un proceso llamado solicitud de extracción”, dijo. “Una vez que se abre una solicitud, los mantenedores del proyecto revisan el código sugerido, solicitan colaboración o aclaración si es necesario, y aceptan el nuevo código. En nuestro caso, el código enviado a través de una solicitud de extracción entregó parches únicos para cada uno de los proyectos vulnerables de GitHub.

“Cuando describimos un proceso para automatizar la aplicación de parches… nuestro equipo de vulnerabilidades del Centro de Investigación Avanzada pudo automatizar la mayoría de los procesos, excepto el control de calidad. Dividimos el proceso en dos pasos, la fase de aplicación de parches y la fase de solicitud de extracción, las cuales estaban automatizadas y simplemente necesitaban ejecutarse”.

Después de obtener una lista de repositorios y archivos que contenían la palabra clave “importar archivo tar” de GitHub, el equipo de Trellix compiló una lista única de repositorios para escanear, y clonó y escaneó cada uno usando una herramienta de verificación de vulnerabilidades de aplicaciones llamada Creosote que creó para ese propósito. . Si Creosote encontraba un repositorio vulnerable, el equipo parcheaba el archivo y creaba una diferencia de parche local que contenía el archivo parcheado, para que pudieran compararse con el archivo original y los metadatos del repositorio.

Hecho esto, el equipo revisó la lista de diferencias de rutas locales, creó una bifurcación del repositorio vulnerable, lo clonó y luego reemplazó el archivo original con el archivo parcheado si encontraron que no había cambiado mientras tanto; si lo había hecho, tomaron se esfuerza por no sobrescribir ningún otro cambio.

Luego, los cambios se confirmaron en el repositorio vulnerable y se creó una solicitud de extracción desde el repositorio bifurcado hasta el original para explicar a los propietarios del repositorio lo que estaba sucediendo. Ahora depende de los propios propietarios del repositorio aceptar el parche, agregó McKee.

“El módulo tarfile vulnerable está incluido en el paquete básico de Python y es una solución fácilmente disponible para un problema común; también, sin una solución directa de Python, está firmemente integrado en la cadena de suministro de muchos proyectos”, dijo.

“Es la permanencia junto con el hecho de que casi todo el material de aprendizaje sobre cómo usar correctamente el módulo tarfile enseña a los desarrolladores cómo usarlo incorrectamente, lo que crea una amplia superficie de ataque. A través de estos esfuerzos para automatizar y parchear proyectos vulnerables, se reduce la superficie de ataque de la cadena de suministro de software.

“Este trabajo para reducir la superficie de ataque no se puede realizar sin la colaboración de toda nuestra industria”, agregó McKee. “Como industria, no podemos darnos el lujo de ignorar la necesidad de buscar y erradicar las vulnerabilidades fundamentales. Se pueden realizar parches masivos de proyectos de código abierto, incluso si lleva mucho tiempo, y puede brindar beneficios a organizaciones de todos los tamaños, en todos los sectores y regiones”.

Instó a todas y cada una de las organizaciones que usan bibliotecas de código y marcos en sus aplicaciones a implementar controles adecuados y medidas de evaluación para garantizar una visibilidad adecuada de sus cadenas de suministro de software, y enfatizó la importancia de apoyarse en los desarrolladores para que se eduquen en todas las capas de la tecnología. pila.

Exit mobile version