El proveedor de ciberseguridad Trellix pasó el último mes publicando correcciones para CVE-2007-4559, una vulnerabilidad de Python en el módulo tarfile del lenguaje de programación que afectaba a más de 300.000 repositorios de código abierto. El investigador de Trellix Kasimir Schulz se topó con el fallo a principios de este año e inicialmente creyó que se trataba de una nueva vulnerabilidad. Sin embargo, Schulz descubrió más tarde que se trataba de una vulnerabilidad existente en Python que nunca había sido parcheada.
Aunque el fallo se asignó a un CVE cuando se descubrió originalmente en 2007 y se le dio una puntuación CVSS de gravedad media de 6,8, los investigadores de Trellix descubrieron que era más fácil de explotar de lo que se pensaba inicialmente y que podía llevar a la ejecución de código, aumentando su prioridad como amenaza.
El redescubrimiento de la CVE-2007-4559 -y las dificultades para parchearla- también puso de manifiesto problemas de seguridad de mayor envergadura para proyectos como la Python Software Foundation (PSF), que dependen de voluntarios para desarrollar, mantener y parchear el software.
Cómo la CVE-2007-4559 cayó en el olvido
Lars Gustäbel, un antiguo voluntario de PSF, lideró la vulnerabilidad de Python hace 15 años e incluso propuso una solución en 2014. Sin embargo, dejó PSF en 2019 en medio de una discusión sobre el parche de Python tarfile que parece haberse quedado en el camino con su salida.
En un hilo público de GitHub de 2007 que discutía la vulnerabilidad de Python tarfile, Gustäbel dijo que "después de una cuidadosa consideración" él y un compañero de mantenimiento de PSF decidieron que la falla no justificaba un problema de seguridad. En lugar de aplicar un parche, PSF proporcionó una documentación de advertencia que indicaba que podía ser "peligroso extraer archivos de fuentes no fiables".
Puede leer también | Una vulnerabilidad de Python pone en peligro 350.000 proyectos de código abierto
"En principio, sigo manteniendo esa afirmación", dijo Gustäbel en un correo electrónico a la redacción de TechTarget. "Sin embargo, esto no es un asunto trivial y tiene muchas facetas".
Proporcionó contexto adicional en una entrada de blog la semana pasada, señalando que descartó el primer informe de error en 2007 y propuso un parche para su discusión en el rastreador de errores de Python en 2014.
"En ese momento, me pareció que no era la forma en que la mayoría de la gente quería que se arreglara el problema. La discusión se apagó al instante, por lo que no hubo una votación clara y el parche nunca se implementó", escribió Gustäbel en la entrada del blog. "En 2018, se reanudó la discusión sobre el parche, pero debido a las limitaciones de tiempo ya no pude participar. Cada vez tenía más dificultades para cumplir con mi papel de mantenedor de archivos tar. Por lo tanto, en 2019 renuncié a mi puesto de mantenedor".
Puede leer también | Python mejor lenguaje de programación para algoritmos comerciales
El hilo de GitHub muestra que el parche propuesto por Gustäbel no recibió respuestas en 2014. Aunque la discusión sobre el parche se reanudó en 2018, y varios voluntarios expresaron su apoyo al esfuerzo e incluso hicieron revisiones al parche, la participación en la discusión disminuyó, y el parche nunca se publicó.
En medio de las preguntas sobre el estado del parche en 2019, un desarrollador de Python respondió: "Se hizo un progreso como el descrito en este tema, pero todavía hay trabajo por hacer, y nadie parece estar tomando esto por sí mismo en este momento."
Aunque Gustäbel recalcó que ya no trabaja con PSF y que no habla en nombre de la organización ni de sus desarrolladores, escribió que "las afirmaciones de que hay una vulnerabilidad de seguridad en el módulo tarfile que se ha ignorado durante 15 años son algo exageradas y están fuera de contexto."
Puede leer también | Python en la lista top 2022 preferida por los programadores
Además, Gustäbel abordó muchas de las preocupaciones del informe de Schulz del mes pasado, que documentaba mayores riesgos para la vulnerabilidad de Python. En su opinión, el fallo "no muestra una vulnerabilidad de seguridad en el módulo tarfile, sino en el IDE Spyder", un entorno de desarrollo de código abierto para la programación en Python. Los investigadores de Trellix demostraron cómo un atacante podría explotar el fallo de Python para la ejecución remota de código utilizando ese entorno.
"Tanto el módulo tarfile como el pickle se utilizan de formas que no deben usarse y que están fuertemente desaconsejadas en la documentación", escribió Gustäbel en la entrada del blog.
A pesar de la nueva investigación de Trellix sobre la CVE-2007-4559, el parche propuesto por Gustäbel aún no ha sido publicado. El hilo de GitHub no muestra nuevas discusiones sobre el parche propuesto desde que Trellix publicó su informe el mes pasado.
Puede leer también | Cómo instalar Python en Linux, Windows y MAC OS
No está claro qué medidas tomará finalmente PSF, si es que toma alguna, para la vulnerabilidad de Python. Según el hilo de GitHub sobre el cambio propuesto, la función de opt-in se discutió largamente en las últimas semanas, pero aún no se ha desplegado.
Trellix aborda el problema
Cuando los investigadores de Trellix descubrieron que el 61% de los repositorios de GitHub que utilizaban el paquete tarfile eran vulnerables a un ataque, la empresa de ciberseguridad actuó desarrollando sus propios parches. Hasta la semana pasada, Douglas McKee, ingeniero principal y director de investigación de vulnerabilidades de Trellix, dijo que había enviado algo menos de 11.000 pull requests a los repositorios, con unos 140 parches aplicados confirmados.
Trellix está en camino de alcanzar su número inicial de unos 60.000 parches antes de que se complete la inmensa tarea. No se han involucrado más socios, y McKee destacó la lentitud del proceso de aplicación de parches, pero sí destacó un aspecto positivo.
"Un ejemplo de cómo esto está mejorando la ciberseguridad en todas las industrias es la aceptación de nuestro pull request por parte de Monai, una red de código abierto para la inteligencia artificial médica. Este marco se ha descargado más de 600.000 veces y era susceptible de esta vulnerabilidad", dijo McKee.
"Al tratarse de un framework, esto afecta directamente a la cadena de suministro, ya que las aplicaciones se construyen en torno a esta base de código", señaló. "Nuestros esfuerzos han ayudado a asegurar esta pieza de tecnología de código abierto para los profesionales médicos. Nos entusiasma ver el impacto positivo que nuestros esfuerzos seguirán teniendo en múltiples industrias."
Puede leer también | 3 Bibliotecas especiales de Python para la programación de Visión Computacional
A pesar de las opiniones encontradas entre Trellix y PSF sobre cómo avanzar, la vulnerabilidad de Python demostró las preocupaciones de seguridad del código abierto cuando se trata de comunicación y soporte. Los expertos en infoseguridad coinciden en que se trata de una situación compleja y que es difícil decir exactamente dónde está la responsabilidad.
Josh Bressers, vicepresidente de seguridad del proveedor de seguridad de la cadena de suministro Anchore, dijo que aunque el software de código abierto no tiene garantías, cree que hay ciertas expectativas de la tecnología principal. En este caso, Python es un lenguaje de programación muy utilizado.
"La Python Software Foundation tiene una declaración de intenciones que incluye 'proteger' el lenguaje Python, y sospecho que todo el mundo estaría de acuerdo en que esto es aplicable", dijo Bressers a TechTarget Editorial.
Puede leer también | Diferencias entre desarrolladores FullStack versus Java FullStack Python
Tim Mackey, principal estratega de seguridad del Centro de Investigación de Ciberseguridad de Synopsys, dijo que es importante reconocer que, dado que Python es de código abierto, cualquier persona con las habilidades para escribir en C puede contribuir con actualizaciones. El hecho de que nadie haya contribuido habla de un problema más amplio con el consumo de código abierto, añadió. Ese consumo es elevado: Synopsys publicó en abril un informe sobre la seguridad del código abierto que determinaba que, aunque casi el 100% de las empresas utilizan software de código abierto, su gestión resulta difícil.
"Si basas el futuro de tu empresa en código libre y no contribuyes o te comprometes activamente con los equipos de desarrollo que crean ese software libre, estás aceptando implícitamente cualquier riesgo asociado a las decisiones que toman esos autores", dijo Mackey en un correo electrónico a TechTarget Editorial.
Del mismo modo, dijo que es importante reconocer que las fundaciones de software de código abierto como PSF no pueden compararse con los proveedores de software comercial que están obligados a parchear todos los fallos. Es fácil culpar a esa fundación cuando el desarrollo de código abierto ofrece a todo el mundo la oportunidad de contribuir tanto a las correcciones como a las nuevas funcionalidades, dijo, incluidos los investigadores que están llamando la atención sobre el fallo.
Puede leer también | Desarrollador Python no necesita Título Profesional
"En este caso, hay una discusión renovada dentro del tema de GitHub, y esa discusión muestra lo difícil que es arreglar un problema de seguridad sin crear cambios de ruptura para los usuarios", dijo Mackey.
Otra discrepancia, que señaló el CSO de Tenable, Robert Huber, es que algunos proyectos de código abierto cuentan con más personal y responden más rápidamente a los problemas que otros. Los factores que contribuyen a ello son los recursos y el nivel de esfuerzo que se requiere para una solución, lo cual, señaló, no difiere de los proyectos comerciales.
El reporte del caso fue obtenido de Tech Target