WebP mit kritischer Zero-Day-Schwachstelle: So erkennen und beheben Sie CVE-2023-4863

In Zusammenarbeit mit The Citizen Lab von der Munk School an der Universität Toronto konnte Apple Security Engineering & Architecture (SEA) im September 2023 die beiden kritischen Schwachstellen CVE-2023-4863 und CVE-2023-5129 aufdecken. Ihren Ausgangspunkt bilden Dateien im WebP-Bildformat, über die anhand von Schadcode ein Exploit von Chromium-basierten Browsern und der Bibliothek webmproject/libwebp von Google möglich wird. Über die Schwachstelle und die jüngsten Entwicklungen rund um diese haben wir bereits in diesem Artikel berichtet.

Insbesondere die Schwachstelle in libwebp wirkt sich nicht nur auf Browser aus, sondern auch auf Dev-Ökosysteme, Betriebssysteme und Container. Im nachfolgenden Überblick zeigen wir, welche Ökosysteme und Container im Einzelnen von libwebp betroffen sind:

An dem hier illustrierten Wirkungsradius dieser Schwachstelle wird deutlich, dass sie sich als Abhängigkeit direkter wie auch transitiver Art über diverse Dev-Ökosysteme erstreckt. Als transitive Abhängigkeit ist sie dabei in erster Linie in Cocoapods-, Swift- und Python-Projekten anzutreffen. Für Entwickler gestaltet es sich daher mitunter schwierig, ihre Exposition festzustellen. Mit Snyk Container und Snyk Open Source lassen sich die relevanten Pakete jedoch gezielt ausmachen. Zudem können Sie Snyk jetzt kostenlos nutzen, um Ihre Projekte dahingehend auszuleuchten.

Wir haben bereits umfassend analysiert, inwieweit sich libwebp auswirkt. In der Security-Community sind jedoch noch weitere Untersuchungen zu den verschiedenen Nutzungsszenarien von libwebp in Anwendungen, Ökosystemen und Betriebssystemen im Gange. Die Schwachstelle betrifft Software-Komponenten, die WebP-Codecs zum Rendering des Bildformats verwenden (also Browser, Design-Tools etc.). Ihr Wirkungsradius dürfte sich also noch weiter vergrößern. Daher ist es unerlässlich, aktuelle Entwicklungen rund um libwebp aufmerksam zu verfolgen.

Neben den Auswirkungen, die diese Schwachstelle auf Software-Ökosysteme hat, beleuchten wir im vorliegenden Artikel auch Ad-hoc-Strategien für eine adäquate Reaktion darauf.

Stand 3. Oktober 2023 wird diese libwebp-Schwachstelle unter folgenden CVEs geführt:

• CVE-2023-4863: Erfasst am 11. September 2023 mit einem CVSS-Wert von 9,6 und einem EPSS-Wert von 31,86 % (97. Perzentil). Hinweis: Ursprünglich wurde dieser CVE mit 8,8 ein hoher Schweregrad zugewiesen, der nach Bekanntwerden weiterer Details angepasst wurde. 

• CVE-2023-5129: Erfasst am 25. September 2023 mit dem höchstmöglichen CVSS-Wert von 10, von Google als verantwortliche CVE Numbering Authority jedoch am 27. September 2023 als Duplikat verworfen.

Über die Schwachstelle und die jüngsten Entwicklungen rund um diese haben wir bereits in diesem Artikel berichtet. Im vorliegenden Artikel beleuchten wir nun folgende Strategien zur Behebung:

1. Bestimmung der Punkte, an denen libwebp genutzt wird

2. Upgrade auf libwebp Version 1.3.2 oder höher

3. Projekt-Monitoring anhand automatischer Pull-Requests

1\. Bestimmung der Punkte, an denen libwebp genutzt wird

Der wohl komplizierteste Schritt bei der Reaktion auf Zero-Day-Schwachstellen besteht in der Ermittlung, ob und an welchen Punkten Sie von ihr betroffen sind. So auch bei libwebp\: In Ihrem Projekt kann libwebp als Abhängigkeit sowohl direkter als auch indirekter (transitiver) Art eingebunden sein. Dies zu ermitteln ist daher unerlässlich, um das Problem adäquat adressieren zu können. Denn sehr wahrscheinlich sind Sie wenigstens zu einem gewissen Grad betroffen, ohne überhaupt davon zu wissen. Ob dies der Fall ist, lässt sich an folgenden Szenarien festmachen: 

• Die Bibliothek libwebp ist in Ihr Software-Projekt entweder direkt oder indirekt als transitive Abhängigkeit eingebunden.

• Sie nutzen Software, die WebP-Bildformate codiert oder decodiert.

• In Ihre Betriebssysteme oder Container-Images ist Tooling zur Verarbeitung von WebP-Bilddateien eingebunden.

Der hohe Verbreitungsgrad der libwebp-Schwachstelle innerhalb von Dev-Ökosystemen ist nicht zuletzt auch darauf zurückzuführen, dass die zugrunde liegende Bibliothek in ausgedehntem Maße Anwendung in höheren Programmiersprachen findet. So ist libwebp etwa als Abhängigkeit in der Godot-Engine eingebunden, die eine kostenlose Entwicklungsumgebung für 2D- und 3D-Games bietet. Gleiches gilt für das weit verbreitete Tool FFmpeg.

Erkennung der libwebp-Schwachstelle mit Snyk

Mit Snyk lässt sich aus diversen Blickwinkeln ausleuchten, ob Sie von derlibwebp-Schwachstelle betroffen sind – dies zum Einstieg sogar kostenlos. So können Sie über die Snyk CLI lokale Scans Ihrer Projekte durchführen:

• Für App-Scans geben Sie in der Snyk CLI den Befehl snyk test --scan-all-unmanaged ein. Damit gleichen Sie nicht verwaltete Abhängigkeiten mit Ihrem Repository ab, um einzelne Packages mit Schwachstellen auszumachen.

• Innerhalb von Containern ermitteln Sie anhand des Befehls snyk container test Betriebssystem-Packages, die Abhängigkeiten mit anfälligen Versionen von libwebp aufweisen.

Ebenfalls möglich ist ein umfassender Scan aller Ihrer in Git-Repositories abgelegten Projekte, um sämtliche direkten und transitiven Abhängigkeiten auszumachen. Der dabei generierte Report zeigt nicht nur auf, ob Sie libwebp nutzen, sondern auch in welchen und wie vielen Pfaden Ihrer Abhängigkeiten. Zudem können Sie auch einfach einen projektübergreifenden Suchlauf nach „CVE-2023-4863“ durchführen. 

2a. Upgrade auf libwebp Version 1.3.2 oder höher (Open Source)

• Automatischer Fix: Binden Sie Snyk an Ihre Git-Repositories an. Updates spielen Sie dann via Pull-Request direkt bei Verfügbarkeit in die betroffenen Repositories ein. Im Anschluss daran erstellen Sie einfach einen neuen Build Ihrer Anwendung.

• Manueller Fix: Bei Nutzung als direkte Abhängigkeit innerhalb Ihrer Anwendung können Sie libwebp im Dependency-File auf Version 1.3.2 oder höher aktualisieren. Im Anschluss daran erstellen Sie einfach einen neuen Build Ihrer Anwendung.

• Manueller Fix: Erfolgt die Nutzung innerhalb Ihrer Anwendung transitiv, ermitteln Sie eine Version einer direkten Abhängigkeit zu libwebpj1.3.2 oder höher, über die Sie die aktuelle Version in die entsprechende transitive Abhängigkeit einspielen. Im Anschluss daran erstellen Sie einfach einen neuen Build Ihrer Anwendung.

2b. Upgrade auf libwebp Version 1.3.2 oder höher (Container)

• Automatischer Fix: Binden Sie Snyk an Ihre Git-Repositories an. Updates spielen Sie dann via Pull-Request direkt bei Verfügbarkeit in Ihre Dockerfile-Base-Images ein. Ob der Vorschlag für das Base-Image die Schwachstelle aufweist, können Sie mittels Preview über https://snyk.io/test/docker/<image_name> feststellen. Wiederholen Sie dies so lange, bis Sie einen sicheren Upgrade-Pfad ermittelt haben. Erstellen Sie dann einen neuen Container-Build.

• Manueller Fix: Ist ihr Base-Image aufgrund einer unsicheren Version von libwebp anfällig, ein entsprechendes Image-Upgrade aber nicht verfügbar oder nicht für Sie geeignet, können Sie das Upgrade über die Fixing-Vorschläge vonSnyk Container manuell vornehmen.  Beispiel: Über die CLI gibt Snyk Container auf einem Debian-basierten Image Folgendes aus:

✗ High severity vulnerability found in libwebp/libwebpdemux2
  Description: Out-of-bounds Write
  Info: https://security.snyk.io/vuln/SNYK-DEBIAN12-LIBWEBP-5918869
  Introduced through: imagemagick@8:6.9.11.60+dfsg-1.6, imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6, libwebp/libwebp-dev@1.2.4-0.2, libwebp/libwebp7@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-dev@8:6.9.11.60+dfsg-1.6 > librsvg/librsvg2-dev@2.54.7+dfsg-1~deb12u1 > gdk-pixbuf/libgdk-pixbuf-2.0-dev@2.42.10+dfsg-1+b1 > tiff/libtiff-dev@4.5.0-6 > libwebp/libwebp-dev@1.2.4-0.2 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpmux3@1.2.4-0.2
  and 4 more...
  Fixed in: 1.2.4-0.2+deb12u1

Für ein manuelles Upgrade der Bibliothek können Sie hier etwa wie folgt vorgehen:

…
RUN apt-get update && \
    apt-get install -y libwebp-dev=1.2.4-0.2+deb12u1 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*
…

3\. Projekt-Monitoring anhand automatischer Pull-Requests

Bei Zero-Day-Schwachstellen wie dieser werden von einem Tag auf den nächsten neue Bedrohungskontexte bekannt. Umso wichtiger ist es daher, für Ihre Projekte aktiv und in regelmäßigem Turnus nach neuen Empfehlungen zur Behebung Ausschau zu halten. Voraussetzung hierfür: Durchgängiges Projekt-Monitoring, wie dies etwa mit Snyk möglich ist. Beim Import eines Repository in die Snyk App ist das entsprechende Feature standardmäßig aktiviert, durch das Ihre Projekte einmal pro Tag automatischen Scans unterzogen werden. Zudem führt es auch bei Updates Ihrer Projekte direkt eine Reihe weiterer Checks durch.

Snyk ermittelt so jeden Tag automatisch, ob neue Security-Fixes verfügbar sind und an welchen Stellen diese implementiert werden können. So würden Sie etwa bei Nutzung von libwebpj über eine transitive Abhängigkeit in Package A ein Release von Package A benötigen, das libwebp in Version 1.3.2 oder höher nutzt. Diese mag gegenwärtig vielleicht noch nicht verfügbar sein, womöglich aber am darauf folgenden Tag oder in einer Woche. Genau dies prüft snyk monitor täglich nach und übermittelt direkt beim Release des entsprechenden Upgrades ein Pull-Request an Sie, über das die anfällige Version von libwebp aktualisiert und so die Schwachstelle behoben wird.

Ebenfalls via Pull-Request, aber auch über andere Mechanismen, werden Sie von Snyk zudem auch benachrichtigt, wenn für diese Schwachstelle weitere Fixes verfügbar oder neue Angriffsvektoren bekannt werden, durch die sich neue Einfallstore auftun. So sind Sie frühzeitig im Bilde und können direkt die nötigen Korrekturmaßnahmen einleiten.