Die Folgen einer jahrealten SQLite-Schwachstelle

Im Oktober 2022 veröffentlichten Forscher von Trail of Bits eine detaillierte Aufschlüsselung der Schwachstellen im SQLite-DBMS. Dieser Artikel beschreibt einen potenziellen Angriff über CVE-2022-35737, dessen Folgen von einem einfachen Anwendungsabsturz bis hin zur Ausführung willkürlichen Codes reichen. Der eher triviale Bug im SQLite-Code ist aus zwei Gründen interessant und potenziell gefährlich. Erstens schlummert er seit Oktober 2000 in SQLite – fast seit Beginn der Entwicklung dieser Open-Source-Software. Zweitens machen es die Funktionen von SQLite theoretisch möglich, eine Vielzahl von Programmen anzugreifen, die SQLite enthalten.

Features von SQLite

SQLite ist ein kompaktes, eingebettetes Open-Source-DBMS, das erstmals vor 22 Jahren (August 2000) veröffentlicht wurde. Die Schlüsseldefinition hier ist „eingebettet“. Denn SQLite wird nicht als eigenständige Software installiert. Stattdessen wird es als Bibliothek für Softwareentwickler verwendet, die mit Datenbanken arbeiten müssen. Beispielsweise ist SQLite standardmäßig in vielen Release-Paketen von Google Chrome, Firefox und Safari, Android-Browsern, Netzwerkanwendungen und Betriebssystemen auf Basis des Linux-Kernels enthalten. SQLite hat aufgrund seiner Open-Source-Lizenz, Zuverlässigkeit und Sicherheit an Popularität gewonnen. Bisher wurden nur sehr wenige schwerwiegende Schwachstellen im DBMS-Code gefunden.

Details über CVE-2022-35737

Die Experten fanden einen Fehler im Code der Funktion sqlite3_snprintf, die von in C/C++ geschriebenen Programmen verwendet wird, um mit der Datenbank zu interagieren. Das Übergeben einer sehr großen Zeichenfolge (größer als 2 GB) an diese Funktion führt zum Absturz des Programms und ermöglicht somit einen Denial of Service (DoS)-Angriff. Der sqlite3_snprintf-Code verwendete eine Integer-Variable, um die Größe der übergebenen Zeichenfolge zu berechnen. Die Variable kann einen negativen Wert annehmen, wenn der übergebene String zu groß ist. Dadurch wird ein Speicherpuffer zugewiesen, der zu klein ist, um die resultierende Zeichenfolge zu schreiben. Als Resultat tritt ein üblicher Pufferüberlauffehler auf.

Dieser Fehler wurde höchstwahrscheinlich vor 22 Jahren in den Code eingeführt. Dies liegt daran, dass die Übergabe von Gigabyte-Parametern an eine Funktion aufgrund von Ressourcenbeschränkungen zu diesem Zeitpunkt unwahrscheinlich war. Heute ist dies nicht mehr der Fall. Ein weiterer interessanter Aspekt des Trail of Bits-Berichts ist der Vorschlag, warum solche Fehler beim Standardtest des Codes nicht berücksichtigt wurden. Der Testprozess ist in erster Linie darauf ausgelegt, neu hinzugefügten oder geänderten Code zu testen, der sich seit mehr als 20 Jahren nicht geändert hat. Das Auffinden solcher Schwachstellen mittels Fuzzing (mit zufälligen Parametern als Funktionseingaben) ist sehr schwierig. Herkömmliche Fuzzing-Verfahren erzeugen keine so großen Zeichenfolgen. Die Autoren dieser Studie kommen deshalb zu dem Schluss, dass Fuzzing die statische Codeanalyse, auch die manuelle, nicht vollständig ersetzen kann.

Unklare Folgen

Durch sorgfältige Manipulation des Inhalts und der Größe der übergebenen Parameter war Trail of Bits in der Lage, den ursprünglichen DoS-Angriff zu „modernisieren“, um beliebigen Code auszuführen. Obwohl die Autoren des Papers Angriffsbeispiele verwendeten, um einen funktionierenden Proof-of-Concept zu demonstrieren, sind dies rein theoretische Übungen zum Angriff auf SQLite selbst. Aber wie bereits erwähnt, ist SQLite ein eingebettetes DBMS. Jemand müsste also eine Anwendung mit eingebettetem SQLite-Code angreifen, um wirklichen Schaden anzurichten.

Wie sich herausstellt, basiert die Studie auf ziemlich vielen Annahmen, und die tatsächliche Möglichkeit, die Schwachstelle auszunutzen, wurde noch nicht belegt. Daten der Entwickler von SQLite zufolge ist dieser Bug nur für C-Anwendungen relevant und auch nur dann, wenn der Code mit bestimmten Parametern kompiliert wird. Die Forscher von Trail of Bits weisen eigens darauf hin, dass der Angriff unmöglich ist, wenn SQLite per Stack Canaries kompiliert wird. Im Wesentlichen ist dies eine zusätzliche Schutzmethode gegen Pufferüberlaufangriffe, die verhindert, dass willkürlicher Code ausgeführt wird, selbst wenn ein Überlauf möglich ist.

Die Schwachstelle wurde in SQLite 3.39.2, veröffentlicht im Juli 2022. Geschlossen. Dennoch hatte der Patch wenig Erfolg. Software-Entwickler, die SQLite als Teil ihres eigenes Codes verwenden, müssen ihre Entwicklungen wahrscheinlich aktualisieren und die neue Software-Version verteilen. Solange bleibt die Schwachstelle bestehen. Dabei sollte man nicht vergessen, dass viele Programme mit integriertem SQLite nicht mehr unterstützt werden.

Es ist noch nicht klar, wie gefährlich diese Schwachstelle ist und ob sie aktiv ausgenutzt werden kann. Basierend auf der Definition der SQLite-Entwickler ist die Wahrscheinlichkeit eines tatsächlichen Angriffs gering, aber nicht null. Inzwischen reiht sich dieser Bug in eine langjährige Sammlung von Fehlern ein, die Softwareentwicklern Kopfschmerzen bereiten können.