Beim Ende-zu-Ende-Fuzzing von Web RTC, das für Videokonferenzen zum Einsatz kommt, hat eine Sicherheitsforscherin aus Googles Project Zero diverse Bugs gefunden.
Natalie Silvanovich, Mitarbeiterin in Googles Project Zero, widmet sich wie ihre Kollegen der Suche nach unentdeckten Zero-Day-Sicherheitslücken in weit verbreiteter Software. In Teil 1 einer Reihe von Blogposts zum Thema Videokonferenzsoftware hat sich Silvanovich mit Web RTC beschäftigt, Facetime und Whatsapp sollen folgen.
Laut ihrem Post haben sich inzwischen fast alle Videolösungen auf eine Architektur geeinigt, die es zwei Peers erlaubt, auch bei schwacher Bandbreite und trotz Servern dazwischen, sicher miteinander zu kommunizieren. Peers nehmen dabei wahlweise über das Session-Description-Protokoll (SDP) eine erste Verbindung auf, was Signalling heißt.
Allerdings kommt SDP nicht immer zum Einsatz und stimmen die meisten Implementierungen nicht mit der Spezifikation überein. Webseiten, die Videokonferenzen unterstützen, bauen diese meist über Websockets oder einen Webserver über HTTPS auf, Mobiles Apps wählen für Signalling dieselben Nachrichten wie später für die Textnachrichten.
Die Verbindung wird dann über die STUN-, TURN- und ICE-Protokolle initiiert, danach etablieren die Peers für die Kommunikation UDP-, UDP-over-STUN- oder TCP-Verbindungen. Die Daten selbst verschicken sie über das Real-time Transport Protocol (RTP), das es auch als Secure RTP (SRTP) mit Verschlüsselung gibt. Alternativ lassen sich die Streams mit DTLS chriffrieren.
RTP erlaubt es, mehrere Streams und Datenformate simultan zu verwenden, und dann die Daten an den passenden Videocodec weiter zu reichen. Zusätzlich kommt häufig noch eine Fehlerkorrektur zum Einsatz, und lassen sich Codecs abhängig von der verfügbaren Bandbreite on the Fly ändern.
Signalling ok, Parsen weniger
Im Web RTC SDP-Parser hat Silvanovich keine Bugs gefunden. Und selbst wenn welche dort wären: Die Browser Chrome, Safari und Firefox nutzen verschiedene Web-RTC-Implementierungen, ein Bug hätte laut der Forscherin also nur begrenzte Auswirkungen.
Als nächstes hat sie die RTP-Implementierung von Web RTC untersucht. Dazu hat sie mit einigem Aufwand ein Ende-zu-Ende-Fuzzing etabliert und die Funktion “srtp_protect()” in Chromes Libsrtp so angepasst, dass ein Fuzzer über jedes Paket der Kommunikation lief.
Ein Web-RTC-Anruf bei einer unveränderten Chrome-Instanz führte im folgenden etwa alle 30 Sekunden zu Abstürzen. Meist waren Divisionen durch Null die Ursache, aber drei Crashes stachen heraus. Das CVE-2018-6130 ist ein Speicherüberlauf, den der Einsatz von “std::map::find” im Zusammenspiel mit dem V9-Codec produziert. Das CVE-2018-6129 liest den Index eines Feldes in einem RTP-Paket aus und will diesen dann als Vektor einsetzen, ohne ihn zu verifizieren. Das CVE-2018-6157 beschreibt ein Problem das auftritt, wenn das manipulierte Paket wie ein VP8-Paket aussieht und an den H264-Parser geschickt wird, ohne zuvor ein paar Checks zu absolvieren.
Hilfe von “video_replay”
Aus dem Web-RTC-Team kam dann der Vorschlag, zum Reproduzieren der Fehler das “video_replay”-Tool zu verwenden, womit sich die Fehler mit Hilfe aufgezeichneter RTP-Streams nachstellen ließen. Mit dem Tool ließ sich RTP über Dump-Files weiter fuzzen, wodurch vier weitere Lücken zutage traten.
Die Sicherheitslücke CVE-2018-6156 hält Silvanovich für am wahrscheinlichsten ausbeutbar. Es handelt sich um einen großen Buffer Overflow in der Fehlerkorrektor (FEC). CVE-2018-6155 und CVE-2018-16071 sind zwei Use-after-Free-Lücken im Videocodec VP8 respektive im VP9-Processing. Mit CVE-2018-16083 gibt es dann noch ein Out-of-Bounds Leseproblem in der Fehlerkorrektur. Das Ende-zu-Ende-Fuzzing brachte also einige Fehler zutage, laut Silvanovich sind sie bereits alle behoben.
