{"id":29474,"date":"2022-11-08T11:32:38","date_gmt":"2022-11-08T09:32:38","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=29474"},"modified":"2022-11-08T11:32:38","modified_gmt":"2022-11-08T09:32:38","slug":"sqlite-vulnerability-22yo","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/sqlite-vulnerability-22yo\/29474\/","title":{"rendered":"Die Folgen einer jahrealten SQLite-Schwachstelle"},"content":{"rendered":"

Im Oktober 2022 ver\u00f6ffentlichten<\/a> Forscher von Trail of Bits eine detaillierte Aufschl\u00fcsselung der Schwachstellen im SQLite-DBMS. Dieser Artikel beschreibt einen potenziellen Angriff \u00fcber CVE-2022-35737<\/a>, dessen Folgen von einem einfachen Anwendungsabsturz bis hin zur Ausf\u00fchrung willk\u00fcrlichen Codes reichen. Der eher triviale Bug im SQLite-Code ist aus zwei Gr\u00fcnden interessant und potenziell gef\u00e4hrlich. Erstens schlummert er seit Oktober 2000 in SQLite \u2013 fast seit Beginn der Entwicklung dieser Open-Source-Software. Zweitens machen es die Funktionen von SQLite theoretisch m\u00f6glich, eine Vielzahl von Programmen anzugreifen, die SQLite enthalten.<\/p>\n

Features von SQLite<\/h2>\n

SQLite ist ein kompaktes, eingebettetes Open-Source-DBMS<\/a>, das erstmals vor 22 Jahren (August 2000) ver\u00f6ffentlicht wurde. Die Schl\u00fcsseldefinition hier ist \u201eeingebettet\u201c. Denn SQLite wird nicht als eigenst\u00e4ndige Software installiert. Stattdessen wird es als Bibliothek f\u00fcr Softwareentwickler verwendet, die mit Datenbanken arbeiten m\u00fcssen. Beispielsweise ist SQLite standardm\u00e4\u00dfig 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\u00e4ssigkeit und Sicherheit an Popularit\u00e4t gewonnen. Bisher wurden nur sehr wenige schwerwiegende Schwachstellen im DBMS-Code gefunden.<\/p>\n

Details \u00fcber CVE-2022-35737<\/h2>\n

Die Experten fanden einen Fehler im Code der Funktion sqlite3_snprintf<\/em>, die von in C\/C++ geschriebenen Programmen verwendet wird, um mit der Datenbank zu interagieren. Das \u00dcbergeben einer sehr gro\u00dfen Zeichenfolge (gr\u00f6\u00dfer als 2 GB) an diese Funktion f\u00fchrt zum Absturz des Programms und erm\u00f6glicht somit einen Denial of Service (DoS)-Angriff. Der sqlite3_snprintf<\/em>-Code verwendete eine Integer-Variable, um die Gr\u00f6\u00dfe der \u00fcbergebenen Zeichenfolge zu berechnen. Die Variable kann einen negativen Wert annehmen, wenn der \u00fcbergebene String zu gro\u00df ist. Dadurch wird ein Speicherpuffer zugewiesen, der zu klein ist, um die resultierende Zeichenfolge zu schreiben. Als Resultat tritt ein \u00fcblicher Puffer\u00fcberlauffehler auf.<\/p>\n

Dieser Fehler wurde h\u00f6chstwahrscheinlich vor 22 Jahren in den Code eingef\u00fchrt. Dies liegt daran, dass die \u00dcbergabe von Gigabyte-Parametern an eine Funktion aufgrund von Ressourcenbeschr\u00e4nkungen 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\u00fccksichtigt wurden. Der Testprozess ist in erster Linie darauf ausgelegt, neu hinzugef\u00fcgten oder ge\u00e4nderten Code zu testen, der sich seit mehr als 20 Jahren nicht ge\u00e4ndert hat. Das Auffinden solcher Schwachstellen mittels Fuzzing (mit zuf\u00e4lligen Parametern als Funktionseingaben) ist sehr schwierig. Herk\u00f6mmliche Fuzzing-Verfahren erzeugen keine so gro\u00dfen Zeichenfolgen. Die Autoren dieser Studie kommen deshalb zu dem Schluss, dass Fuzzing die statische Codeanalyse, auch die manuelle, nicht vollst\u00e4ndig ersetzen kann.<\/p>\n

Unklare Folgen<\/h2>\n

Durch sorgf\u00e4ltige Manipulation des Inhalts und der Gr\u00f6\u00dfe der \u00fcbergebenen Parameter war Trail of Bits in der Lage, den urspr\u00fcnglichen DoS-Angriff zu \u201emodernisieren\u201c, um beliebigen Code auszuf\u00fchren. Obwohl die Autoren des Papers Angriffsbeispiele verwendeten, um einen funktionierenden Proof-of-Concept zu demonstrieren<\/a>, sind dies rein theoretische \u00dcbungen zum Angriff auf SQLite selbst. Aber wie bereits erw\u00e4hnt, ist SQLite ein eingebettetes DBMS. Jemand m\u00fcsste also eine Anwendung mit eingebettetem SQLite-Code angreifen, um wirklichen Schaden anzurichten.<\/p>\n

Wie sich herausstellt, basiert die Studie auf ziemlich vielen Annahmen, und die tats\u00e4chliche M\u00f6glichkeit, die Schwachstelle auszunutzen, wurde noch nicht belegt. Daten<\/a> der Entwickler von SQLite zufolge ist dieser Bug nur f\u00fcr 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\u00f6glich ist, wenn SQLite per Stack Canaries kompiliert wird. Im Wesentlichen ist dies eine zus\u00e4tzliche Schutzmethode gegen Puffer\u00fcberlaufangriffe, die verhindert, dass willk\u00fcrlicher Code ausgef\u00fchrt wird, selbst wenn ein \u00dcberlauf m\u00f6glich ist.<\/p>\n

Die Schwachstelle wurde in SQLite 3.39.2, ver\u00f6ffentlicht<\/a> im Juli 2022. Geschlossen. Dennoch hatte der Patch wenig Erfolg. Software-Entwickler, die SQLite als Teil ihres eigenes Codes verwenden, m\u00fcssen 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\u00fctzt werden.<\/p>\n

Es ist noch nicht klar, wie gef\u00e4hrlich diese Schwachstelle ist und ob sie aktiv ausgenutzt werden kann. Basierend auf der Definition der SQLite-Entwickler ist die Wahrscheinlichkeit eines tats\u00e4chlichen Angriffs gering, aber nicht null. Inzwischen reiht sich dieser Bug in eine langj\u00e4hrige Sammlung<\/a> von Fehlern ein, die Softwareentwicklern Kopfschmerzen bereiten k\u00f6nnen.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Ein interessanter Bug in einem der beliebtesten eingebetteten DBMS.<\/p>\n","protected":false},"author":665,"featured_media":29477,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6],"tags":[963,1498,4013],"class_list":{"0":"post-29474","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"tag-entwicklung","9":"tag-schwachstellen","10":"tag-sql"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/sqlite-vulnerability-22yo\/29474\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/sqlite-vulnerability-22yo\/24829\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/20329\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/27364\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/sqlite-vulnerability-22yo\/25166\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/25501\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/sqlite-vulnerability-22yo\/28057\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/sqlite-vulnerability-22yo\/34205\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/sqlite-vulnerability-22yo\/46029\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/sqlite-vulnerability-22yo\/19702\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/sqlite-vulnerability-22yo\/20389\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/sqlite-vulnerability-22yo\/25570\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/sqlite-vulnerability-22yo\/31214\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/sqlite-vulnerability-22yo\/30921\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstellen\/","name":"Schwachstellen"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29474","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=29474"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29474\/revisions"}],"predecessor-version":[{"id":29479,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29474\/revisions\/29479"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/29477"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=29474"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=29474"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=29474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}