La vulnerabilitat de Python posa de manifest els problemes de seguretat de codi obert

Els esforços de reparació d’una vulnerabilitat de Python de 15 anys d’antiguitat sense pegats han plantejat preguntes sobre la seguretat de codi obert després que una empresa hagi assumit la immensa tasca.

El proveïdor de ciberseguretat Trellix va passar l’últim mes llançant solucions per a CVE-2007-4559, una vulnerabilitat de Python al mòdul tarfile del llenguatge de programació que va afectar més de 300.000 dipòsits de codi obert. L’investigador de Trellix, Kasimir Schulz, va ensopegar amb l’error a principis d’aquest any i inicialment va creure que era una nova vulnerabilitat. No obstant això, més tard, Schulz va descobrir que era una vulnerabilitat de Python existent que mai s’havia pegat.

Tot i que el defecte se li va assignar un CVE quan es va descobrir originalment el 2007 i se li va donar una puntuació CVSS de severitat mitjana de 6,8, els investigadors de Trellix van descobrir que era més fàcil d’explotar del que es pensava inicialment i que podria conduir a l’execució de codi, augmentant la seva prioritat com a amenaça. .

El redescobriment de CVE-2007-4559, i les lluites per corregir-lo, també van posar de manifest problemes de seguretat de codi obert més grans per a projectes com la Python Software Foundation (PSF) que depenen de voluntaris per desenvolupar, mantenir i aplicar pedaços al programari. Què passa quan els voluntaris d’un projecte no poden arribar a un consens sobre com gestionar una vulnerabilitat denunciada? I què passa quan aquests voluntaris abandonen el projecte?

Com CVE-2007-4559 va caure per les esquerdes

Lars Gustäbel, un antic voluntari de PSF, va estar al capdavant de la vulnerabilitat de Python fa 15 anys i fins i tot va proposar una solució el 2014. No obstant això, va deixar PSF el 2019 enmig d’una discussió en curs sobre el pegat de tarfile de Python que sembla haver quedat en el camí amb la seva marxa. .

En un fil públic de GitHub del 2007 que parlava de la vulnerabilitat de l’arxiu tar de Python, Gustäbel va dir que “després d’una consideració acurada” ell i un company de manteniment de PSF van decidir que la fallada no justificava un problema de seguretat. En lloc d’aplicar pedaços, PSF va proporcionar documentació d’advertència que deia que podria ser “perillós extreure arxius de fonts no fiables”.

“En principi, segueixo mantenint aquesta afirmació”, va dir Gustäbel en un correu electrònic a TechTarget Editorial. “No obstant això, això no és una qüestió trivial, i hi ha moltes facetes”.

Va proporcionar context addicional en una publicació al bloc la setmana passada, assenyalant que va descartar el primer informe d’errors el 2007 i va proposar un pedaç per a la discussió al rastrejador d’errors de Python el 2014.

“En aquell moment, em va semblar que aquesta no era la manera com la majoria de la gent volia que es solucionés el problema. La discussió es va apagar a l’instant, de manera que no hi va haver una votació clara i el pegat mai es va implementar”, va escriure Gustäbel al entrada al blog. “L’any 2018 es va reprendre la discussió sobre el pegat, però per limitacions de temps ja no vaig poder participar. Vaig tenir dificultats creixents per complir amb la meva funció de mantenidor de fitxers tarifs. Per tant, el 2019 vaig renunciar a la meva posició de mantenedor”.

El fil de GitHub mostra que el pedaç proposat per Gustäbel va rebre les nostres respostes l’any 2014. Mentre que la discussió sobre el pegat es va reprendre el 2018, i diversos voluntaris van expressar el seu suport a l’esforç i fins i tot van fer revisions al pegat, la participació en la discussió va disminuir i el pegat es va reduir. mai llançat.

Enmig de les preguntes sobre l’estat del pedaç el 2019, un desenvolupador de Python va respondre: “S’ha fet un avenç tal com es descriu en aquest tema, però encara hi ha feina per fer i ningú sembla que s’encarregui d’això en aquests moments. .”

Tot i que Gustäbel va subratllar que ja no treballa amb PSF i que no parla per l’organització i els seus desenvolupadors, va escriure que “les afirmacions que hi ha una vulnerabilitat de seguretat al mòdul tarfile que s’ha ignorat durant 15 anys són una mica exagerades i fora de lloc. context”.

A més, Gustäbel va abordar moltes preocupacions de l’informe de Schulz el mes passat que documentava riscos més elevats per a la vulnerabilitat de Python. Segons la seva opinió, la falla “no mostra una vulnerabilitat de seguretat al mòdul tarfile, sinó a l’IDE Spyder”, un entorn de desenvolupament de codi obert per a la programació de Python. Els investigadors de Trellix van demostrar com un atacant podria explotar el defecte de Python per a l’execució de codi remota mitjançant aquest entorn.

Els investigadors de Trellix demostren com explotar la vulnerabilitat de Python de forma remota per comprometre una instància de Spyder IDE, un entorn de desenvolupament de codi obert per a la programació de Python.

“Tant l’arxiu tar com els mòduls pickle s’utilitzen de manera que se suposa que no s’han d’utilitzar i que es desaconsella molt a la documentació”, va escriure Gustäbel a la publicació del bloc.

Malgrat la nova investigació de Trellix sobre CVE-2007-4559, el pegat proposat per Gustäbel encara no s’ha publicat. El fil de GitHub no mostra noves discussions sobre el pegat proposat des que Trellix va publicar el seu informe el mes passat.

No està clar quina acció prendrà PSF, si n’hi ha, per a la vulnerabilitat de Python. Victor Stinner, un desenvolupador de Python amb PSF, va dir el mes passat a TechTarget Editorial que hi havia una proposta, presentada per primera vegada el 2017, per “afegir una opció per optar per un comportament més segur”, però que no s’havia implementat. Segons el fil de GitHub sobre el canvi proposat, la funció d’activació es va discutir llargament durant les últimes setmanes, però encara no s’ha desplegat.

Trellix aborda el problema

Quan els investigadors de Trellix van descobrir que el 61% dels dipòsits de GitHub que utilitzaven el paquet tarfile eren vulnerables a un atac, l’empresa de ciberseguretat va actuar desenvolupant els seus propis pedaços. La setmana passada, Douglas McKee, enginyer principal i director d’investigació de vulnerabilitats de Trellix, va dir que havia enviat una mica menys d’11.000 sol·licituds d’extracció als dipòsits, amb uns 140 pegats aplicats confirmats.

McKee va dir a TechTarget Editorial que Trellix té com a objectiu assolir el seu nombre inicial d’uns 60.000 pegats abans que es completi la immensa tasca. No s’ha implicat cap soci addicional, i McKee va posar èmfasi en la lentitud del procés de pegat, però en va destacar un positiu.

“Un exemple de com això està millorant la ciberseguretat entre les indústries és l’acceptació de la nostra sol·licitud d’extracció per part de Monai, una xarxa de codi obert per a la intel·ligència artificial mèdica. Aquest marc s’ha descarregat més de 600.000 vegades i era susceptible a aquesta vulnerabilitat”, va dir McKee.

“Com que és un marc, això afecta directament la cadena de subministrament, ja que les aplicacions es construeixen al voltant d’aquesta base de codi”, va assenyalar. “Els nostres esforços han ajudat a assegurar aquesta peça de tecnologia de codi obert per als professionals mèdics. Estem emocionats de veure l’impacte positiu que els nostres esforços continuaran tenint en múltiples indústries”.

Malgrat les opinions contradictòries entre Trellix i PSF sobre com avançar, la vulnerabilitat de Python va demostrar problemes de seguretat de codi obert quan es tracta de comunicació i suport. Els experts d’Infosec coincideixen que aquesta és una situació complexa i que és difícil dir exactament on recau la responsabilitat.

Josh Bressers, vicepresident de seguretat del proveïdor de seguretat de la cadena de subministrament Anchore, va dir que, tot i que el programari de codi obert no té cap garantia, creu que hi ha certes expectatives de la tecnologia bàsica. En aquest cas, Python és un llenguatge de programació molt utilitzat.

“La Python Software Foundation té una declaració de missió que inclou “protegir” el llenguatge Python, que sospito que tothom està d’acord que és aplicable”, va dir Bressers a TechTarget Editorial.

Tim Mackey, estrateg de seguretat principal del Synopsys Cybersecurity Research Center, va dir que és important reconèixer que com que Python és de codi obert, qualsevol persona amb habilitats per escriure en C pot aportar actualitzacions. El fet que ningú hagués contribuït parla d’un tema més ampli amb el consum de codi obert, va afegir. Aquest consum és alt: Synopsys va publicar un informe de seguretat de codi obert a l’abril que va determinar que si bé el 100% de les empreses utilitzen programari de codi obert, gestionar-lo resulta difícil.

“Si estàs basant el futur de la teva empresa en el codi lliure i no contribueixes ni participes activament amb els equips de desenvolupament que creen aquest programari lliure, estàs acceptant implícitament qualsevol risc associat a les decisions que prenen aquests autors”, va dir Mackey. en un correu electrònic a TechTarget Editorial.

De la mateixa manera, va dir que és important reconèixer que les bases de programari de codi obert com PSF no es poden comparar amb els venedors comercials de programari que estan obligats a corregir tots els defectes. És fàcil culpar a aquesta base quan el desenvolupament de codi obert ofereix a tothom l’oportunitat d’aportar solucions i noves funcionalitats, va dir, inclosos els investigadors que criden l’atenció sobre el defecte.

“En aquest cas, hi ha una discussió renovada dins del problema de GitHub, i aquesta discussió mostra com de difícil és solucionar un problema de seguretat sense crear canvis trencadors per als usuaris”, va dir Mackey.

Una altra discrepància, que el CSO de Tenable Robert Huber va assenyalar, és que alguns projectes de codi obert tenen més personal i són molt ràpids per respondre als problemes en comparació amb altres. Els factors contribuents que va destacar van ser els recursos i el nivell d’esforç necessari per a una solució, que va assenyalar que no és diferent per als esforços comercials.

Més important encara, va dir Huber, quan el defecte es va descobrir inicialment el 2007, la seguretat de la cadena de subministrament no es va considerar en la mesura que ho és avui.

Els atacs significatius de la cadena de subministrament de programari durant els últims anys, com SolarWinds, han augmentat la preocupació tant per a les empreses com per als projectes de codi obert. Fins i tot els llançaments de productes aquest mes per part de gegants tecnològics com Google se centren en assegurar la cadena de subministrament de programari.

No obstant això, fa 15 anys, no hi havia cicles de vida de desenvolupament de programari segurs amb anàlisi de la composició del programari, va assenyalar Huber, ni comprovacions de dependència de tercers. No és segur simplement confiar en el programari de codi obert, i Huber va subratllar la importància que és per a les empreses verificar aquest codi per elles mateixes.

“Te [Trellix] la investigació va assenyalar que buscaven el fitxer tar d’importació; tot i que aquest és un indicador que un projecte podria ser vulnerable, no vol dir necessàriament que ho sigui. Hauríeu d’avaluar cada projecte en detall per verificar-ho”, va dir Huber. “En qualsevol cas, és un gran punt de dades per assegurar-vos que esteu practicant bones pràctiques de desenvolupament de programari segur”.

Un altre problema potencial és que la fallada de travessa del directori pot afectar més que només el mòdul tarfile. Les vulnerabilitats de travessa de directoris, que Mackey va descriure com “escenaris on les dades subministrades per l’usuari o modificables per l’usuari s’utilitzen sense validació o sense límits”, no són cap novetat. Més important encara, va dir, és fàcil per als desenvolupadors escriure codi que contingui aquest tipus de defecte.

D’altra banda, Mackey va dir que les eines estàndard de seguretat d’aplicacions poden ajudar a identificar aquesta classe d’amenaça.

Bressers va estar d’acord que el defecte afectarà més que només el fitxer tar, i per això creu que buscar altres mòduls afectats és la manera correcta d’abordar completament el defecte de seguretat de codi obert.

“En lloc de precipitar-se per fer alguna cosa, els desenvolupadors de Python estan iniciant una discussió, que estic 100% d’acord que és el camí correcte”, va dir Bressers.

Si les empreses implementen els pedaços de Trellix, va dir Mackey, és important que els usuaris de Python provein àmpliament les seves aplicacions per assegurar-se que no s’han produït canvis d’interrupció i que no calguin actualitzacions de la configuració.

“Tenint en compte l’edat d’aquesta vulnerabilitat, els usuaris de Python en situacions de llarga vida útil haurien de prestar especial atenció a com es poden utilitzar les dades subministrades per l’usuari per aquesta interfície”, va dir Mackey.

Leave a Comment

Your email address will not be published. Required fields are marked *