AI-videoverwerking aanvallen

AI verwerkt video's om de inhoud te verwerken en samenvattingen van de video te maken, bedreigingen op te sporen, gedrag te volgen, medische revalidatie te analyseren, om er maar een paar te noemen. Een verscheidenheid aan informatie kan uit video's worden afgeleid, waaronder objectclassificatie, audiotranscriptie, ondertitelstromen, optische tekenherkenning en visuele vergelijkingen. Het aanvalsoppervlak en de potentiële kwetsbaarheden nemen toe naarmate er meer soorten informatie uit video-inhoud worden afgeleid.

We zullen de volgende afgeleide gegevenstypen bekijken:

• Audio in tekst omzetten
• Segmenteren in scènes of hoofdstukken
• Objecten identificeren
• De output van de bovenstaande gegevenstypen samenvatten

Deze presentatie laat zien hoe u LLM-verwarring, informatieverspreiding, uitputting van bronnen en dienstcrashes kunt uitlokken door video's te maken met promptinjecties, randgevallen in streams en hun eigenschappen en door transmissiefouten te simuleren. Er worden hulpmiddelen gepresenteerd die de video's aanpassen aan het te testen systeem. We kunnen dit losjes "fuzzing" noemen. We zullen video's maken om deze systemen aan te vallen en mitigaties aanbevelen.

Gegevenstypen

De huidige mogelijkheden van AI-videobewerking maken het mogelijk om de volgende gegevenstypen uit video's te extraheren:

• Scènes geïdentificeerd door begin- en eindtijdmarkeringen
• Objectclassificatie in geselecteerde frames
• Frames insluiten met behulp van een visiemodel
• Transcriptie van audiokanaal
• Ondertitelstromen
• Optische tekenherkenning (OCR) van geselecteerde frames voor elke tekst op het scherm
• Framebijschrift met behulp van een bijschriftmodel

Er kan veel informatie uit een video worden gehaald. Een typische architectuur is het gebruik van een "pijplijn" die het proces opdeelt in componenten. Elk onderdeel van de pijplijn is specifiek voor het type gegevens dat wordt geëxtraheerd. Aan het einde van de pijplijn worden de gegevens van de verschillende componenten samengevoegd tot een uiteindelijke uitvoer. Wij gaan uit van deze aanpak.

Eigenschappen van video

Er zijn talloze eigenschappen van een video die van invloed kunnen zijn op het geheugen, de schijf en de rekenkracht die nodig zijn om de gegevenstypen te extraheren. Deze eigenschappen beïnvloeden ook het gewenste resultaat van de dienst door edge cases uit te oefenen of foutcondities op te roepen waar het ontwikkelingsteam geen rekening mee heeft gehouden.

Containers

Video containers definiëren hoe de video-, audio- en ondertitelingsstromen worden opgeslagen. De populairste containerformaten zijn momenteel MP4, MKV en MOV. De software die de video gebruikt, heeft een lijst met ondersteunde containers. Dit weten is belangrijk om kwaadaardige video's op de juiste manier te maken.

Framerate

De framesnelheid is het aantal frames per seconde (FPS). Typische framesnelheden zijn 24, 30 en 60. Video's die actie vastleggen, zoals sportevenementen, kunnen 120 FPS zijn. De framerate is niet beperkt tot deze waarden, maar er zijn historische redenen waarom ze gebruikelijk zijn. De bestandsgrootte van de video is recht evenredig met de framesnelheid. In onze tests kunnen we een willekeurige framesnelheid gebruiken om de videogrootte en het geheugengebruik te beïnvloeden, zoals verderop in deze post wordt beschreven.

In de beschrijving van gegevenstypen hierboven staat een kwalificatie van "geselecteerde frames". Een 24 FPS video die 30 minuten lang is, zal 43.200 frames hebben. Dat is veel om te verwerken en meestal onnodig omdat zoveel frames lijken op hun aangrenzende frames, met dezelfde scène. De verwerkingssoftware zal een subset van frames selecteren om te gebruiken met OCR, objectclassificatie of een bijschriftmodel.

Video-codec

De videocodec bepaalt hoe de individuele frames van de video worden weergegeven. Bijna alle codecs bevatten een vorm van compressie. De algemene aanpak is om key-frames te identificeren die volledig in de video zijn opgenomen. Frames tussen sleutelframes bevatten alleen het visuele verschil met het vorige frame. Deze aanpak is ruimtebesparend omdat beweging kan worden opgeroepen door de geleidelijke verandering van veel frames in de loop van de tijd. Als het verschil tussen frames klein is, wordt de totale videogrootte kleiner. Dit zal later belangrijk zijn.

Audio

Audiostreams hebben een bemonsteringsfrequentie die meestal gemeten wordt in kilohertz (kHz). De audiosamplesnelheid beschrijft een soortgelijke maat als de framesnelheid, maar is onafhankelijk van de videostream. Audio van DVD-kwaliteit wordt meestal gesampled op 48 kHz. Er is ook nog de bitsnelheid, meestal gemeten in kilobits per seconde (kbps). Typische MP3-bitsnelheden zijn 128 kbps en 160 kbps. De bemonsteringsfrequentie en bitsnelheid hebben een directe invloed op de grootte van de audiokanalen. Ook hier kunnen we ons voordeel mee doen.

Een audiostream kan meerdere kanalen hebben. Stereo audio heeft twee kanalen. Surround sound heeft verschillende configuraties. 5.1 is een typische configuratie die zes kanalen specificeert, waarbij de ".1" een subwooferkanaal aanduidt. De manier waarop de verwerkingssoftware met meerdere kanalen omgaat is voor ons van belang. Wordt er gedownmixt naar één kanaal, of worden alle kanalen afzonderlijk getranscribeerd? Hoe worden meerdere transcripties aan de AI gepresenteerd?

Ondertitels

Ondertitelstromen kunnen gebaseerd zijn op tekst of afbeeldingen. Aan elke tekenreeks of afbeelding is een begin- en eindtijd gekoppeld. Videodisks hebben meestal ondertitels op basis van afbeeldingen, waarvoor OCR nuttig is. Er zijn veel op tekst gebaseerde ondertitelformaten. Sommige bevatten opmaakfuncties om lettertypes, vet, cursief, beweging, animatie en scripts te specificeren. Het proces waarbij ondertitels aan de videoframes worden toegevoegd, wordt "inbranden" genoemd. Op beeld gebaseerde ondertitels worden bovenop de videoframes geplaatst en bieden de speler weinig flexibiliteit. Ondertitels op basis van tekst geven de speler meer flexibiliteit bij de presentatie.

Aanvallen

We hebben de video-eigenschappen behandeld die belangrijk zijn voor onze aanvallen. Laten we eens kijken hoe we ongebruikelijke waarden kunnen gebruiken om de AI-verwerkingspijplijn aan te vallen.

LLM verwarring

Laten we beginnen met het verwarren van het tekstgebaseerde grote taalmodel (LLM). Zoals gezegd heeft de pijplijn meerdere onderdelen om de gegevens uit de video te halen. De gegevens moeten in een tekstuele vorm aan het LLM worden aangeboden om de analyse uit te voeren.

We beginnen met een voorbeeld van een promptsjabloon voor de LLM om een video samen te vatten:

Maak een beknopte, samenhangende samenvatting van de video op basis van de onderstaande scène-transcripties en visuele aanwijzingen.

Titel: {{title}}

{% for scene in scenes %}

Scène ({{scene.start}}-{scene.end}} s):
TRANSCRIPT: {{scene.transcript}}
SUBTITLE: {{scene.subtitle}}
CAPTION: {{scene.caption}}
OBJECTEN:{{scene.object_classifications}}
OCR: {{scene.ocr}}

{% endfor %}

Dat is een behoorlijke hoeveelheid informatie die de LLM moet verwerken. Voor een normale video, zoals een patiëntengesprek of een kort fragment in de dierentuin, zal de LLM een goed idee krijgen van wat er gaande is, terugkerende thema's, enz.

Een belangrijke controle waar we rekening mee moeten houden, zijn vangrails. Traliewerk is een soort uitvoercontrole voor op LLM gebaseerde systemen. LLM's zijn probabilistische systemen, dus de uitvoer voor een bepaalde invoer kan veranderen. Een typische vangrail is dat de AI de gebruiker niet mag vertellen hoe hij een illegale activiteit moet uitvoeren.

Ontwikkelingsteams besteden de meeste moeite aan de verwachte invoer, omdat die de meeste waarde voor klanten oplevert. Een geldige verwachting is dat een niet-kwaadaardige video een consistente inhoud heeft in elk van de gegevenstypes. Wat zijn de gevolgen van onverwachte gegevens vanuit een LLM-perspectief?

• Waar worden de vangrails toegepast?
• Zijn er componenten die geen vangrails hebben omdat men ervan uitgaat dat de vangrails van een andere component ongewenste inhoud zullen opvangen?
• Wat als de tekst op het scherm, het transcript en de ondertitel totaal verschillende dingen zeggen?
• Als de inhoud van het frame de vangrail passeert, maar het transcript schandalig is en helemaal niet overeenkomt met de visuele inhoud, wordt het transcript dan gecensureerd?
• Omgekeerd, als het transcript of de ondertiteling acceptabel is, worden ongewenste beelden dan geaccepteerd?

Welke LLM injectiescenario's zijn er? De bovenstaande sjabloon is simplistisch en niet bedoeld om een productieklare implementatie weer te geven.

• Wordt ALLE inhoud bewaakt? Kan bijvoorbeeld OCR worden gebruikt voor promptinjectie terwijl het transcript of de ondertitel niet levensvatbaar zijn?
• Is het mogelijk om een visual te maken die een LLM-instructie in het bijschrift produceert?

De lengte van de tekst kan worden gebruikt om de LLM-context te overweldigen en instructies te injecteren. Gangbare tekstgebaseerde ondertitelformaten hebben bijvoorbeeld geen karakterbeperking.

Uitputting van bronnen

Uitputting van hulpbronnen verwijst naar het overweldigen van het geheugen, de schijf en/of de computer van de verwerkingspijplijn om de dienst te verslechteren.

Videobestanden kunnen gemakkelijk honderden megabytes of gigabytes groot worden door normale opnameapparaten. De eerste gedachte om de pijplijn te beschermen tegen uitputting van bronnen is om de geaccepteerde bestandsgrootte te beperken. We zullen echter zien dat dit niet genoeg is.

Er zijn verschillende gebieden waar we de LLM kunnen aanpassen om uitputting van bronnen te voorkomen. Laten we eens kijken naar de voorbeeldsamenvattingssjabloon die hierboven is gegeven.

Ten eerste kan het aantal scènes kunstmatig worden opgeblazen. Scènedetectie kan ingewikkeld zijn. Op een hoog niveau wordt er gekeken naar voldoende verschillen tussen een bepaald videosegment en de voorgaande/volgende segmenten. Audio kan ook worden meegenomen in de detectie door te zoeken naar periodes van stilte en andere merkbare volumeveranderingen. Als we een video kunnen genereren met veel scènewisselingen, kan dit resulteren in uitputting van bronnen. Eén methode is om een diavoorstellingsvideo te maken, waarbij elke scène één beeld is dat gedurende vele frames wordt herhaald. De videocodec zal dit aanzienlijk comprimeren, waardoor we honderden of duizenden scènewisselingen in een video kunnen stoppen die binnen elke bestandsgroottebeperking past die door de pijplijn wordt opgelegd.

Objectdetectie kan misbruikt worden door frames te maken met meer objecten dan waarvoor de pijplijn ontworpen is. Voorbeelden van objecten zijn voertuigen, dieren en gebouwen. Het aantal objecten dat als te veel wordt beschouwd, kan in de tientallen of honderden lopen. Het model dat gebruikt wordt om objecten te detecteren is belangrijk omdat er per object een minimale breedte en hoogte vereist kan zijn.

Zoals eerder gezegd, hebben de meeste op tekst gebaseerde ondertitelformaten geen beperking voor de tekenlengte. Er is een effectieve limiet wanneer de tekst op het scherm wordt weergegeven, maar de LLM prompt heeft niet dezelfde beperking. De pijplijn kan de ondertitel als zodanig extraheren en aan de sjabloon toevoegen. Dit kan erg lange tekst opleveren.

Veel onderdelen in de pijplijn hebben ongecomprimeerde frames nodig om hun werk te kunnen doen. Of de frames nu op schijf of in het geheugen worden opgeslagen, we kunnen proberen de bron uit te putten.

Toenemende videodimensies hebben meestal een exponentieel effect op het gebruik van bronnen. De H.265 (HEVC) codec ondersteunt bijvoorbeeld afmetingen van meer dan 8192x4320 (4K video). Het opslaan van frames van deze grootte zal aanzienlijk meer ruimte en rekenkracht vergen dan een 1080p video.

De framerate kan ook van invloed zijn op het gebruik van bronnen. Als de pijplijn bijvoorbeeld elk 10e frame bemonstert, kunnen we een video met 200 FPS (of meer) genereren. Een ruimte-efficiënte videocodec zoals H.265 zal dit aanzienlijk comprimeren om de totale bestandsgrootte te verminderen. Bij uitbreiding zullen de frames aanzienlijk meer ruimte innemen. Ook hier kunnen computer, geheugen en schijf alle worden beïnvloed.

Onverwachte fouten

Tijdstempels

Tijdstempels zijn essentieel voor de juiste interpretatie van videogegevens. Als de timestamps niet in de juiste volgorde staan, erg groot zijn of mogelijk negatief zijn, kan dit de verwerking negatief beïnvloeden. Dit vereist aangepaste tooling, aangezien videobewerkingssoftware bedoeld is om geldige video's te produceren.

Willekeurige fouten

Wanneer video via USB-kabels of netwerken wordt verzonden, zijn er foutcorrectieprotocollen om ervoor te zorgen dat de gegevens tijdens het transport niet beschadigd raken.

Deze foutloze aanname is geldig in de meeste instellingen. Eén geval waarin dit geen veilige veronderstelling is, is bij het opnemen van uitgezonden televisie. Bij dit medium wordt video via de lucht van de antenne van het station naar de ontvangerantenne kilometers verderop verzonden. Atmosferische omstandigheden kunnen fouten in de stroom introduceren. Er is geen mechanisme om heruitzending aan te vragen, dus de fouten blijven bestaan. We kunnen gebruik maken van de foutloze aanname door kunstmatige fouten in de video te introduceren. De fouten kunnen zich op belangrijke plaatsen of willekeurig voordoen. Sommige containers en codecs zijn ontworpen om bestand te zijn tegen een klein percentage fouten.

Conclusie

Er kan veel informatie uit een video worden gehaald. Dit is gunstig voor gebruikers omdat video gemakkelijk op te nemen is, en diensten manieren bieden om de gegevens snel en grondig te begrijpen. Het aanvalsoppervlak neemt toe met de hoeveelheid verzamelde gegevens. Onze tests moeten deze bedreigingen volledig onderzoeken om onze klanten en gebruikers te beschermen.

In een volgende post zullen we bekijken hoe u open-source tools kunt gebruiken om video's met fuzzed parameters te genereren.