Kenmerk Terwijl ze haast hebben met het begrijpen, bouwen en verzenden van AI-producten, worden ontwikkelaars en datawetenschappers aangespoord om rekening te houden met de beveiliging en niet ten prooi te vallen aan aanvallen op de toeleveringsketen.

Er zijn talloze modellen, bibliotheken, algoritmen, vooraf gebouwde tools en pakketten om mee te spelen, en de vooruitgang is meedogenloos. De output van deze systemen is misschien een ander verhaal, hoewel het onmiskenbaar is dat er in ieder geval altijd iets nieuws is om mee te spelen.

Ongeacht alle opwinding, hype, nieuwsgierigheid en angst om iets te missen, veiligheid mag niet worden vergeten. Als dit geen schok voor je is: fantastisch. Maar een herinnering is hier handig, vooral omdat technologie voor machinaal leren vaak door wetenschappers wordt samengesteld in plaats van door ingenieurs, tenminste in de ontwikkelingsfase, en hoewel die mensen hun weg weten in zaken als neurale netwerkarchitecturen, kwantisering en volgende... gen-trainingstechnieken is infosec begrijpelijkerwijs misschien niet hun sterkste punt.

Het samenstellen van een AI-project verschilt niet zoveel van het bouwen van welk ander stuk software dan ook. Normaal gesproken plakt u bibliotheken, pakketten, trainingsgegevens, modellen en aangepaste broncode aan elkaar om gevolgtrekkingstaken uit te voeren. Codecomponenten die beschikbaar zijn in openbare repository's kunnen verborgen achterdeurtjes of data-exfiltrators bevatten, en vooraf gebouwde modellen en datasets kunnen worden vergiftigd om ervoor te zorgen dat apps zich onverwacht ongepast gedragen.

Sommige modellen kunnen zelfs malware bevatten uitgevoerd als de inhoud ervan niet veilig is gedeserialiseerd. De beveiliging van ChatGPT-plug-ins heeft dat ook kom onder nauwkeurig onderzoek.

Met andere woorden: supply chain-aanvallen die we in de softwareontwikkelingswereld hebben gezien, kunnen ook plaatsvinden in AI-land. Slechte pakketten kunnen ertoe leiden dat de werkstations van ontwikkelaars worden gecompromitteerd, wat leidt tot schadelijke inbraken in bedrijfsnetwerken, en als er met modellen en trainingsdatasets wordt geknoeid, kunnen applicaties dingen verkeerd classificeren, gebruikers beledigen, enzovoort. Achterdeurtjes of met malware verrijkte bibliotheken en modellen kunnen, als ze in de geleverde software worden opgenomen, gebruikers van die apps ook blootstellen aan aanvallen.

Ze lossen een interessant wiskundig probleem op en gebruiken het vervolgens, en dat is alles. Het is niet getest met een pen, er is geen AI red teaming

Als reactie hierop ontstaan ​​cybersecurity- en AI-startups specifiek om deze dreiging aan te pakken; ongetwijfeld hebben gevestigde spelers er ook een oogje op, dat hopen we tenminste. Projecten voor machinaal leren moeten worden gecontroleerd en geïnspecteerd, getest op beveiliging en geëvalueerd op veiligheid.

“[AI] is uit de academische wereld gegroeid. Het zijn grotendeels onderzoeksprojecten aan de universiteit geweest, of het zijn kleine softwareontwikkelingsprojecten geweest die grotendeels zijn voortgekomen uit academici of grote bedrijven, en die hebben gewoon niet de beveiliging vanbinnen”, zegt Tom Bonner, VP onderzoek bij HiddenLayer, een van de onderzoekers. zo’n op beveiliging gerichte startup, verteld Het register.

“Ze lossen een interessant wiskundig probleem op met behulp van software en zetten het vervolgens in, en dat is alles. Het is niet door een pen getest, er is geen sprake van AI red teaming, risicobeoordelingen of een veilige ontwikkelingslevenscyclus. Plotseling hebben AI en machinaal leren een grote vlucht genomen en iedereen wil zich erin verdiepen. Ze pakken allemaal alle gangbare softwarepakketten op die uit de academische wereld zijn voortgekomen, en zie, ze zitten vol kwetsbaarheden, vol gaten.”

De AI-toeleveringsketen heeft talloze toegangspunten voor criminelen, die bijvoorbeeld gebruik kunnen maken van: typosquatting om ontwikkelaars te misleiden om kwaadaardige kopieën van anderszins legitieme bibliotheken te gebruiken, waardoor de boeven gevoelige gegevens en bedrijfsreferenties kunnen stelen, servers kunnen kapen waarop de code draait, en meer, zo wordt betoogd. Bescherming van de toeleveringsketen van software moet ook worden toegepast bij de ontwikkeling van machine learning-systemen.

“Als je een cirkeldiagram bedenkt van hoe je gehackt zult worden zodra je een AI-afdeling in je bedrijf of organisatie opent”, zegt Dan McInerney, hoofd AI-beveiligingsonderzoeker bij Protect AI, tegen Het register, “Een klein deel van die taart zal bestaan ​​uit modelinvoeraanvallen, en dat is waar iedereen het over heeft. En een groot deel zal de supply chain aanvallen – de tools die je gebruikt om het model zelf te bouwen.”

Invoeraanvallen zijn interessante manieren dat mensen AI-software kunnen kraken door ze te gebruiken.

Om het potentiële gevaar te illustreren, publiceerde HiddenLayer onlangs gemarkeerd wat het sterk gelooft is een beveiligingsprobleem met een online service van Hugging Face die modellen in het onveilige Pickle-formaat omzet naar het veiligere Beveiligingen, ook ontwikkeld door Hugging Face.

Pickle-modellen kunnen malware en andere willekeurige code bevatten die stil en onverwacht kan worden uitgevoerd wanneer ze worden gedeserialiseerd, wat niet geweldig is. Safetensors is gemaakt als een veiliger alternatief: modellen die dat formaat gebruiken, mogen bij deserialisatie geen ingebedde code uitvoeren. Voor degenen die het niet weten: Hugging Face host honderdduizenden neurale netwerkmodellen, datasets en stukjes code die ontwikkelaars met slechts een paar klikken of opdrachten kunnen downloaden en gebruiken.

De Safetensors-converter draait op de Hugging Face-infrastructuur en kan worden geïnstrueerd om een ​​PyTorch Pickle-model dat wordt gehost door Hugging Face te converteren naar een kopie in het Safetensors-formaat. Maar dat online conversieproces zelf is volgens HiddenLayer kwetsbaar voor het uitvoeren van willekeurige code.

Onderzoekers van HiddenLayer zeiden dat ze ontdekten dat ze een conversieverzoek konden indienen voor een kwaadaardig Pickle-model dat willekeurige code bevatte, en tijdens het transformatieproces zou die code worden uitgevoerd op de systemen van Hugging Face, waardoor iemand met de converterbot en zijn gebruikers kon gaan rommelen. Als een gebruiker een kwaadaardig model converteert, kan zijn Hugging Face-token worden geëxfiltreerd door de verborgen code, en “kunnen we in feite zijn Hugging Face-token stelen, zijn repository in gevaar brengen en alle privérepository’s, datasets en modellen bekijken die die gebruiker heeft. toegang tot”, betoogde HiddenLayer.

Bovendien wordt ons verteld dat de inloggegevens van de converterbot kunnen worden geopend en gelekt door code die is opgeslagen in een Pickle-model, waardoor iemand zich kan voordoen als de bot en pull-verzoeken kan openen voor wijzigingen in andere repository's. Deze wijzigingen kunnen, als ze worden geaccepteerd, schadelijke inhoud introduceren. We hebben Hugging Face om een ​​reactie gevraagd op de bevindingen van HiddenLayer.

"Ironisch genoeg was de conversieservice voor de conversie naar Safetensors zelf verschrikkelijk onveilig", vertelde Bonner van HiddenLayer ons. “Gezien het toegangsniveau dat de conversiebot had tot de repository’s, was het feitelijk mogelijk om het token te stelen dat ze gebruiken om wijzigingen door te geven via andere repository’s.

“Dus in theorie had een aanvaller elke wijziging in een willekeurige repository kunnen indienen en het kunnen laten lijken alsof deze van Hugging Face kwam, en een beveiligingsupdate had hen voor de gek kunnen houden om deze te accepteren. Mensen zouden gewoon achterdeurmodellen of onveilige modellen in hun repo's hebben gehad en zouden het niet weten.'

Dit is meer dan een theoretische dreiging: Devops-winkel JFrog zei dat het gevonden kwaadaardige code verborgen in 100 modellen gehost op Hugging Face.

Er zijn in werkelijkheid verschillende manieren om schadelijke hoeveelheden code te verbergen in modellen die – afhankelijk van het bestandsformaat – worden uitgevoerd wanneer de neurale netwerken worden geladen en geparseerd, waardoor onverlaten toegang kunnen krijgen tot de machines van mensen. PyTorch- en Tensorflow Keras-modellen “vormen het grootste potentiële risico bij het uitvoeren van kwaadaardige code, omdat het populaire modeltypen zijn met bekende code-uitvoeringstechnieken die zijn gepubliceerd”, merkte JFrog op.

Onzekere aanbevelingen

Programmeurs die code-suggesterende assistenten gebruiken om applicaties te ontwikkelen, moeten ook voorzichtig zijn, waarschuwde Bonner, anders kunnen ze uiteindelijk onveilige code incorporeren. GitHub Copilot is bijvoorbeeld getraind in open source-opslagplaatsen, en minstens 350,000 daarvan zijn potentieel kwetsbaar voor een oud veiligheidsprobleem waarbij Python- en tar-archieven betrokken zijn.

Python's tarbestand module helpt programma's, zoals de naam al doet vermoeden, bij het uitpakken van tar-archieven. Het is mogelijk om een ​​.tar zodanig te maken dat wanneer een bestand in het archief wordt uitgepakt door de Python-module, het zal proberen een willekeurig bestand op het bestandssysteem van de gebruiker te overschrijven. Dit kan worden misbruikt om instellingen te verwijderen, scripts te vervangen en ander onheil te veroorzaken.

De fout werd in 2007 opgemerkt en gemarkeerd in 2022 opnieuw, wat mensen ertoe aanzet projecten te patchen om deze uitbuiting te voorkomen. Die beveiligingsupdates hebben misschien niet hun weg gevonden naar de datasets die worden gebruikt om grote taalmodellen te trainen om te programmeren, klaagde Bonner. "Dus als je een LLM vraagt ​​om meteen een tar-bestand uit te pakken, zal hij je waarschijnlijk [de oude] kwetsbare code terugspugen."

Bonner drong er bij de AI-gemeenschap op aan om te beginnen met het implementeren van beveiligingspraktijken in de toeleveringsketen, zoals van ontwikkelaars eisen dat ze digitaal bewijzen dat ze zijn wie ze zeggen dat ze zijn bij het aanbrengen van wijzigingen in openbare codeopslagplaatsen, wat mensen gerust zou stellen dat nieuwe versies van dingen zijn geproduceerd door legitieme ontwikkelaars. en het waren geen kwaadaardige wijzigingen. Dat zou vereisen dat ontwikkelaars alles beveiligen wat ze gebruiken om zich te authenticeren, zodat iemand anders zich niet als hen kan voordoen.

En alle ontwikkelaars, groot en klein, moeten beveiligingsbeoordelingen uitvoeren en de tools die ze gebruiken inspecteren, en hun software testen voordat deze wordt geïmplementeerd.

Het is lastig om de beveiliging in de AI-toeleveringsketen te verbeteren, en omdat er zoveel tools en modellen worden gebouwd en uitgebracht, is het moeilijk bij te houden.

McInerney van Protect AI benadrukte: “Dat is een beetje de toestand waarin we ons nu bevinden. Er is overal veel laaghangend fruit. Er is gewoon niet genoeg mankracht om alles te bekijken, omdat alles zo snel gaat.” ®

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://go.theregister.com/feed/www.theregister.com/2024/03/17/ai_supply_chain/