Entwickler des mobilen Betriebssystems AuroraOS (eine Abzweigung des Sailfish-Betriebssystems, entwickelt von der Open Mobile Platform Company) hat ein Update für eine Sicherheitsanfälligkeit freigegeben dass sie in memcpy entdeckt. Beseitigung kritischer Schwachstellen (CVE-2020-6096) in Glibc, die sich nur auf der ARMv7-Plattform manifestiert.
Informationen über die Sicherheitsanfälligkeit wurden im Mai veröffentlicht, aber bis zu den letzten Tagen waren die Korrekturen nicht verfügbar, obwohl der Sicherheitsanfälligkeit ein hohes Maß an Gefahr zugewiesen wurde und Es gibt einen funktionierenden Prototyp des Exploits Dadurch kann die Ausführung des Codes organisiert werden.
Der Exploit vorbereitet wirkt während der Verarbeitung in den Funktionen memcpy () und memmove () für bestimmte formatierte Daten.
Die Bedeutung von Glibc besteht darin, dass diese Bibliothek Systemaufrufe und andere Grundfunktionen definiert und nicht nur von fast allen Programmen verwendet wird.
Über das Problem
Sicherheitslücke manifestiert bei der Implementierung von memcpy () und memmove () in Assemblersprache für ARMv7 und es wurde durch falsche Verarbeitung negativer Werte des Parameters verursacht, der die Größe des Bereichs bestimmt.
Probleme mit der Patch-Entwicklung haben begonnen als SUSE und Red Hat bekannt gaben, dass ihre Plattformen nicht betroffen waren Aufgrund des Problems wurden sie nicht für 7-Bit-ARMv32-Systeme kompiliert und waren nicht an der Erstellung des Patches beteiligt.
Die Entwickler vieler eingebetteter Distributionen vertrauten offenbar dem Glibc-Team und beteiligten sich auch nicht aktiv an der Vorbereitung des Patches.
Lösungen
Huawei bot eine Option an für einen Patch das Problem fast sofort zu blockieren, die versuchten, Assembler-Anweisungen, die mit vorzeichenbehafteten Operanden (bge und blt) arbeiten, durch vorzeichenlose Analoga (blo und bhs) zu ersetzen.
Glibc-Betreuer entwickelten eine Testsuite verschiedene Bedingungen für das Auftreten eines Fehlers zu testen, nach was sich herausstellte, dass Huawei Patch nicht passt und es werden nicht alle möglichen Kombinationen von Eingabedaten verarbeitet.
Da AuroraOS verfügt über einen 32-Bit-Build für ARM, Seine Entwickler haben beschlossen, die Sicherheitsanfälligkeit selbst zu schließen und der Gemeinde eine Lösung vorschlagen.
Die Schwierigkeit bestand darin, dass eine effektive Implementierung geschrieben werden musste Assembler der Funktion und berücksichtigen Sie mehrere Optionen für die Eingabeargumente.
Die Implementierung wurde mit nicht signierten Anweisungen neu geschrieben. Der Patch erwies sich als klein, aber das Hauptproblem bestand darin, die Ausführungsgeschwindigkeit beizubehalten und Leistungseinbußen bei den Funktionen memcpy und memmove zu beseitigen, während die Kompatibilität mit allen Kombinationen von Eingabewerten erhalten blieb.
Anfang Juni wurden zwei Lösungen vorbereitet: Bestehen des Wartungstest-Frameworks von Glibc und der internen Testsuite von Aurora. Am 3. Juni wurde eine der Optionen ausgewählt und eingereicht zur Glibc Mailingliste.
Eine Woche später wurde ein anderer ähnlicher Ansatz vorgeschlagen, der das Problem in der Multiarch-Implementierung behebt, das Huawei zuvor zu beheben versucht hatte. Ein Monat dauerte Tests und Legalisierung angesichts der Bedeutung des Patches.
Am 8. Juli wurden Korrekturen in der Hauptniederlassung akzeptiert der kommenden Veröffentlichung von glibc 2.32. Die Anwendung enthält zwei Patches:
- Die erste für eine Multiarch-Anwendung zur Speichereinrichtung für ARMv7
- Die zweite für eine allgemeine Assembler-Implementierung von memcpy () und memmove () für ARM.
Das Problem betrifft Millionen von ARMv7-Linux-Geräten Ohne ein ordnungsgemäßes Update besteht für die Eigentümer die Gefahr, dass sie mit dem Netzwerk verbunden werden (im Netzwerk verfügbare Dienste und Anwendungen, die Eingaben ohne Größenbeschränkungen akzeptieren, können angegriffen werden).
Zum Beispiel ein vorbereiteter Exploit von Forschern, die Die Sicherheitsanfälligkeit zeigt, wie ein http-Server angegriffen werden kann Integration in das Fahrzeuginformationssystem durch Übermittlung einer sehr großen GET-Anfrage und Erhalt des Root-Zugriffs auf das System.
Paketlösungen für Debian und Ubuntu wurden noch nicht veröffentlicht y Sicherheitslücke bleibt unkorrigiert für fast zwei Monate ab dem Zeitpunkt der Veröffentlichung und fünf Monate ab dem Zeitpunkt der Benachrichtigung der Glibc-Entwickler.