Magellan: SQLite-Schwachstelle gefährdet viele Apps

Sicherheitsforscher haben eine kritische Schwachstelle (Magellan) in der weit verbreiteten SQLite-Datenbanksoftware entdeckt. Diese könnte es Angreifern ermöglichen, remote beliebigen oder bösartigen Code auf betroffenen Geräten auszuführen.


Anzeige

SQLite, was ist das?

SQLite ist ein weit verbreitetes, relationales Datenbankmanagementsystem, das nur minimale Anforderungen durch Betriebssysteme oder externe Bibliotheken erfordert. Daher ist es mit fast allen Geräten, Plattformen und Programmiersprachen kompatibel und wird in der App- und Anwendungsentwicklung auf breiter Basis zur Speicherung von Daten eingesetzt.

Die Schwachstelle in SQLite

The Hacker News berichtet hier über die Entdeckung einer Schwachstelle mit dem Namen Magellan durch das Tencent Blade-Sicherheitsteam. Der in älteren Versionen entdeckte SQLite-Fehler könnte es Angreifern ermöglichen, per Internet oder per Netzwerk beliebigen Code auf betroffenen Geräten auszuführen. 

Problem ist, dass SQL nicht nur von Millionen Apps und Anwendungen, sondern auch auf Chromium basierenden Browsern verwendet wird. Wer also eine App, Anwendung oder einen Chromium-basierenden Browser einsetzt, ist möglicherweise angreifbar.

Bisher sind den Entdeckern der Schwachstelle aber keine Fälle bekannt geworden, in denen diese ausgenutzt wurde. Aus Sicherheitsgründen veröffentlichen die Sicherheitsspezialisten keine Details der Schwachstelle.

Wann wird die Schwachstelle gefixt?

Von SQLite wurde die Version 3.26.0 freigegeben, in der der Fehler behoben ist. Nutzer können nur darauf bauen, dass Entwickler, die SQLite in ihren Apps und Anwendungen einsetzen, ein Update der verwendeten SQLite-Bibliotheken auf diese Version erstellen und ausliefern.

Beim Google Chrome-Browser und allen anderen Browsern, die auf Chromium aufsetzen, sollte die SQLite-Schwachstelle mit der Chromium-Version 71.0.3578.80 (Release am 4. Dezember 2018) geschlossen sein.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter App, Sicherheit abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu Magellan: SQLite-Schwachstelle gefährdet viele Apps

  1. Ralf sagt:

    Immer wieder schön, wenn die Originalseite der Software (hier SQLite) selbst keinen Hinweis auf die Dringlichkeit des Updates auf die aktuelle Version gibt. Und zum Beispiel System.Data.SQLite (die Zugriffs-Bibliothek zum Zugriff auf SQLite in Dotnet-Programmen) noch auf dem Stand von August 2018 mit 3.24.0 ist.

    Da fragt man sich immer öfter, ob nur die Sensibilität für Sicherheit so erschreckend niedrig ist oder man auch Rückschlüsse auf die Qualität der eigentlichen Funktion der Software ziehen muss …

    • Windoof-User sagt:

      Die Softwareentwickler, die SQLite in eigenen Applikationen einbinden, kennen den Quellcode und wissen schon seit Wochen, wie die Schwachstelle beseitigt wurde. Ebenso kann jeder Softwareentwickler, der System.Data.SQLite nutzt, den Quellcode mit der aktuellen SQLite Version aktualisieren und durch den Compiler schieben. Wer mehr erwartet, kann sich mit einer Geldspende (wird das SQLite Projekt sicherlich nicht ablehnen) Gehör verschaffen.

      • Ralf sagt:

        Dann müssen Sie hellseherische Fähigkeiten besitzen. Ich kann aktuell auf der Seite von SQLite keinen Hinweis auf eine behobene Sicherheitslücke und die Dringlichkeit zu einem Update erkennen. Was denn auch kaum einer tut, wenn ich mir mal die vielen Anwendungen ansehe, die SQLite verwenden und zwar teilweise in abenteuerlich alten Versionen. In den meisten Fällen sogar, ohne dass man erkennen kann, welche Version verwendet wird, da die DLL speziell für die Anwendung erstellt wurde, ohne Versionsangaben mit zu verwenden. Zu den Anwendungen, die SQLite verwenden, gehören zum Beispiel auch bekanntere Anwendungen wie iTunes, Acronis True Image oder LibreOffice.

        Und mal eben den Wrapper System.Data.SQLite neu zu erstellen, ist auch nicht so ohne, weil er durch die Build-Prozedur mit dem C-Compiler muss. Was in der Vergangenheit mit den verschiedenen VS-Versionen schon zu einigen Überraschungen im späteren Einsatz geführt hat (weil einzelne Konfigurationsoptionen dann doch nicht in der DLL eincompiliert waren). Und was die Geldspende betrifft, da gebe ich lieber das Geld für die kommerzielle Version des Wrappers für C# von DevArt aus. Da ist wird die offizielle DLL von SQLite verwendet und kann bei Versionswechsel einfach ausgetauscht werden. Was im übrigen auch nicht das eigentliche Problem trifft. Da System.Data.SQLite auf der offiziellen Downloadseite von SQLite verlinkt ist, sollte dort zumindest ein Hinweis auf die aktuelle Sicherheitslücke stehen. (Egal ob eine neue Version bereits verfügbar ist.)

        Wenn man bei Microsoft-Produkten oder den Produkten anderer kommerzieller Hersteller von Fehlern nur aus den Medien erfährt und der Hersteller beflissen schweigt, bricht regelmäßig ein Sturm der Entrüstung aus. Nur bei kostenfreier Software wird das aus unerfindlichen Gründen toleriert. Obwohl Fehler in dieser Software genauso die Integrität von Daten und Systemen gefährden. Das bedeutet ja nicht, dass man die Arbeit dieser Entwickler nicht schätzt oder nicht unterstützt. Aber auch diese Entwickler sind für eine Information Ihrer AnwenderInnen verantwortlich.

        Gerade gestern habe ich wieder die Empfehlung gelesen, dass man alle Anwendungen deinstallieren sollte, die man nicht unbedingt braucht. Um die Gefahr von Sicherheitslücken und des Datenmissbrauchs zu verringern. Dann werden gerade diese Entwickler betroffen sein, die bislang mit ihrer freien Software oder Open-Source-Software für tolle und interessante Software und Alternativen zu kommerziellen Produkten gesorgt haben.

Schreibe einen Kommentar zu Ralf Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.