PyTorch waarschuwt voor malware die via dependency confusion werd verspreid

De ontwikkelaars van machinelearningframework PyTorch waarschuwen gebruikers dat er een geïnfecteerde, nagemaakte library online is gezet. Die zou technische informatie stelen van een geïnfecteerd systeem. De dependency zou 2300 keer zijn gedownload.

De ontwikkelaars van het veelgebruikte opensourcemachinelearningframework schrijven in een blogpost dat er in de laatste week van het jaar een geïnfecteerde binary is geüpload door aanvallers. Het gaat om de PyTorch-library torchtriton, die met de nightlyversie voor Linux automatisch wordt geïnstalleerd. De ontwikkelaars waarschuwen iedereen die PyTorch-nightly tussen 25 en 30 december heeft gedownload via pip om dat meteen te de-installeren. Er is inmiddels een nieuwe binary uitgegeven waar de geïnfecteerde library niet in zit.

In die periode hebben aanvallers een geïnfecteerde versie van torchtriton geüpload naar de Python Package Index. Die PyPI kijkt altijd naar de eerste package die wordt geüpload met een bepaalde naam; als een aanvaller een geïnfecteerde package uploadt, wordt die als eerste meegestuurd bij een download via pip. Dat wordt ook wel een dependency confusion genoemd, al zijn dat soort aanvallen betrekkelijk zeldzaam.

In de praktijk betekent het dat iedereen die de PyTorch-nightlybinary in de bewuste week downloadde, niet de authentieke, maar de geïnfecteerde torchtriton-dependency kreeg geïnstalleerd. Die malware kon data stelen van het geïnfecteerde systeem. Het ging onder andere om informatie uit /etc/passwd en om mogelijke ssh-keys. Ook wordt informatie gestolen waarmee apparaten gefingerprint kunnen worden.

De ontwikkelaars van PyTorch hebben torchtriton tijdelijk verwijderd uit de nightlypackage en hebben contact met PyPI om de malware uit de binary te verwijderen. Ook hebben ze een SHA256-hash gedeeld en een manier beschreven om te controleren of gebruikerssystemen zijn geïnfecteerd.

Door Tijs Hofmans

Nieuwscoördinator

02-01-2023 • 10:20

23

Reacties (23)

23
23
10
1
0
9
Wijzig sortering
Ik ben een leek maar is de werkwijze van pypi (check op naam) niet erg kwetsbaar?
In de blogpost staat wat beter beschreven wat er gebeurde.

Maar PyTorch heeft hun eigen `torchtriton` library gehost op hun eigen `PyTorch nightly package index`.
Nu hebben een mensen een malicious package naar de PyPi index geupload en de pip tool geeft voorkeur aan PyPi.

Als ik een beetje kijk in de discussie in PyTorch repo, lijkt de beste oplossing te zijn om niet packages niet zelf te hosten, maar alleen op PyPi te hebben staan. Maar de reden dat ze het zelf hosten is omdat een package 2.4 GB aan ruimte inneemt, wat te te groot is voor PyPi.
In de blogpost staat wat beter beschreven wat er gebeurde.

Maar PyTorch heeft hun eigen `torchtriton` library gehost op hun eigen `PyTorch nightly package index`.
Nu hebben een mensen een malicious package naar de PyPi index geupload en de pip tool geeft voorkeur aan PyPi.
Maw dit is een inherente design flaw en security bug in pip, welke na eerste installatie van een package, deze niet bindt aan de specifieke index vanwaar deze binnen gehaald is, om daar en alleen daar dan ook toekomstige updates vandaan te halen.

[Reactie gewijzigd door R4gnax op 24 juli 2024 00:12]

Dan heb je nog steeds het probleem van eerste installatie.
Dan heb je nog steeds het probleem van eerste installatie.
Mag aannemen dat eerste installatie onderdeel is van een handmatige operatie waar developers daadwerkelijk opletten. En dat de informatie over de source package index daarna in een lockfile terecht komt, waar niet alleen update operaties gebruik van maken maar ook bijv. automated builds tijdens restore-operaties naar kijken. Zodat je ook geen supply-chain aanvallen meer krijgt via die weg.

[Reactie gewijzigd door R4gnax op 24 juli 2024 00:12]

Je controleert niet ieder pakket handmatig. Dan bouw je je deployment vm en het is gebeurd.
Je controleert niet ieder pakket handmatig. Dan bouw je je deployment vm en het is gebeurd.
Nee; maar je gaat er vanuit dat iedereen in de keten wel de eigen directe dependencies controleert en voor automated builds deze restored uit een lockfile met bronverificatie. Er vanuit gaande dat iedereen dat alle package maintainers dat doen is de hele keten transitief beschermd tegen dit soort dependency confusion supply-chain aanvallen

Dat ga je natuurlijk niet 100% dichtgetimmerd krijgen; maar ook als je de 99% weet te halen maakt het het opzetten van dit soort aanvallen wel een stuk meer een risk-vs-reward dingetje, waardoor de frequentie ervan af zal nemen.
Dat iets niet helemaal werkt; wil niet zeggen dat het helemaal niet werkt.
En laat die 1% nou net dat nare pakketje zijn 😎
En laat die 1% nou net dat nare pakketje zijn 😎
Als je pech zou hebben en te maken hebt met een dependency waarvan de ontwikkelaars zelf niet netjes hun builds op orde zouden hebben; ja.
Anders; nee.
En laten we er vanuit gaan dat die 'anders; nee' zo'n 99% van de gevallen zou zijn; en het probleem in kwestie in algemene zin aardig in zou dammen.

Nogmaals:
dat iets niet helemaal werkt; wil niet zeggen dat het dan helemaal niet werkt.
(Baby; badwater; etc.)
Hier zijn gewoon mitigerende maatregelen voor, dependencies kunnen gewoon met checksums geinstalleerd worden (zoek maar eens naar pipenv en pipfile.lock).

Ook zijn er best mogelijkheden om dependencies alleen vanaf *bepaalde* repositories toe te laten, maar dat moet men wel implementeren.

Het gaat dus niet om pypi die een kwetsbaarheid heeft, pypi is "gewoon een publieke repo".
Het gaat om de tooling die een client gebruikt om een applicatie met dependencies te installeren. Een normale pip install waar wheel aan te pas komt, heeft out of the box geen checksum validatie en etc.
Correct Programmer les 1:
Check all issues that could occur and write handling code.
code gebruiken, van derde zonder enige vorm van controle. Is altijd een risico.
klopt, maar toch is het vele malen veiliger om code van een 'bekende' derde te gebruiken, dan zoals nu: een totaal onbekende, kwaadaardige derde.

Het feit dat iemand zich zo kan voordoen als een gerespecteerde ontwikkelaar lijkt me wel een serieus issue bij PyPi.
Probleem alleen is dat het zomaar kan dat wanneer je een dependency gebruikt deze ook weer dependencies heeft en er hoeft er maar een tussen te zitten die mallware/oid bevat en je bent de sjaak. Dat is het probleem van Dependency systemen er moet, net als bij en app store, goede controle op zitten. En daar wringt vaak de schoen.

Mensen zoeken op internet naar een dependency, komen de verkeerde tegen, kijken niet goed ( wat menselijk is ) en gebruiken de verkeerde en zijn zelf zich van geen kwaad bewust tot er wel een probleem ontstaat.

Dat men zich voor kan doen als een bepaalde ontwikkelaar daar zijn natuurlijk de nodige trucjes voor omdit tegen te gaan. Maar het staat of valt bij controle door de gebruiker zelf.
...het vele malen veiliger om code van een 'bekende' derde...
Is nog steeds onveilig. Tuurlijk vertrouw ik de enen ontwikkelaar meer dan een andere ontwikkelaar.
Des ondanks, maak ik zelf een mirror van de packages die ik bewust gebruik.
Ja het is meer werk, dan het automatisch accepteren van nieuwe versies, maar ik voel mij er wel veiliger bij.
Zolang je een groot team hebt dat iedere security fix binnen korte tijd kan valideren en door laten stromen (de mirror updaten) dan is dat inderdaad een prima optie. Werk momenteel echter bij een software bedrijf met 20k man, en desalniettemin niet genoeg mensen om dat te doen~
Een software bedrijf met 20.000 werknemers, kan zich geen software controleur veroorloven. Laat staan een bedrijf inhuren er voor....

Ben benieuwd, wat jullie security team ( die hebben jullie toch wel? ) hier over zegt.

[Reactie gewijzigd door wica op 24 juli 2024 00:12]

De oplossing is simpel: geen handmatige mirrors maken. Security updates moet je binnen uren weten door te voeren. Dat hoort een geval '1 druk op de knop start een nieuwe build met automatische testen en automatische deployments'. Nu moet ik zeggen: Dat is maar in pijnlijk beperkte mate het geval bij ons (tijdens het log4j drama duurde het weken voordat alles was geupdate :S ), maar ik heb tot dusver nog geen één bedrijf gezien die mensen klaar had staan om 24/7 alle veranderingen van alle dependencies van alle producten te monitoren en over te kopiëren. Je hoort praktisch nooit kopieën te maken van dependencies want dat is super gevaarlijk. Zelfs als je beslist om alle veranderingen handmatig te valideren dan noch moet je gewoon lock files gebruiken.

En trouwens, ter verduidelijking, de validatie waar ik het over had is de validatie die voorkomt dat een kwaadaardige update er door heen komt, gezien dat was waar de discussie over was. Dat is de soort validatie waarvoor je iedere package door en door voor moet kennen. Daar zijn geen bedrijven voor te vinden die dat voor je doen zover ik weet. Dependencies draaien om vertrouwen, niet om handmatige controles.

[Reactie gewijzigd door AlRoke op 24 juli 2024 00:12]

Een eigen mirror, gemaakt met b.v. https://pypi.org/project/bandersnatch/ met alleen een whitelist aan modules. Had je in deze wel gered.

Wij zijn een vrij kleine organisatie (<200), maar alle software staat op onze lokale mirror. Met alleen dan, wat wij willen. De systemen kunnen alleen via deze mirror, software binnen halen en updaten.
Onze eigen mirror, doet daarnaast nog de nodigde scan.

Voordeel voor ons is, wij kunnen door gaan, ook al is heel internet plat. Maar wij hebben ook een beter zicht op welke software er binnen onze organisatie gebruikt wordt.
De opzet is idd even werk, maar heb je ook wat aan :)
/etc/passwd is geen map maar een file.
Dit is al gemeld in “geachte redactie”
https://gathering.tweakers.net/forum/list_messages/2166100

[Reactie gewijzigd door ronansoleste op 24 juli 2024 00:12]

Pytorch mag ook wel eens optreden tegen hun pickle vulnerabity's. Het is kinderlijk eenvoudig om executable code in een pytorch model te stoppen. Binnen KoboldAI hebben we het zelf maar opgelost en als je nu een geinfecteerd model probeert te laden stopt het laad process. Wij doen dat op basis van een functie whitelist waar de functies in staan die ons project kan gebruiken. Als het model iets aan wil roepen buiten die veilige functies gaat het direct op de block.

Dergelijke efforts zou ik graag upstream zien, nu lijkt iedereen over te gaan op safetensors wat weer een losse dependencu vergt.
Wij doen dat op basis van een functie whitelist waar de functies in staan die ons project kan gebruiken. Als het model iets aan wil roepen buiten die veilige functies gaat het direct op de block.

Dergelijke efforts zou ik graag upstream zien,
Euhm geen idee of het open source is, maar aangezien jullie het al hebben geïmplementeerd… bied het aan in een PR?

Op dit item kan niet meer gereageerd worden.