Die Entwickler des mobilen Betriebssystems Aurora (eine Abzweigung des Sailfish-Betriebssystems, das vom Unternehmen Open Mobile Platform entwickelt wurde) erzählten eine aufschlussreiche Geschichte über die Beseitigung () in Glibc, das nur auf der ARMv7-Plattform erscheint. Informationen über die Sicherheitslücke wurden bereits im Mai veröffentlicht, aber bis vor Kurzem waren trotz der Tatsache, dass die Sicherheitslücken bestehen, keine Korrekturen verfügbar ein hohes Maß an Gefahr und es gibt einen funktionierenden Prototyp eines Exploits, der es Ihnen ermöglicht, die Codeausführung zu organisieren, wenn Daten verarbeitet werden, die in einer bestimmten Weise in den Funktionen memcpy() und memmove() formatiert sind. Paketkorrekturen für и wurden noch nicht veröffentlicht und die Schwachstelle bleibt seit der Veröffentlichung fast zwei Monate lang und nach der Benachrichtigung der Glibc-Entwickler fünf Monate lang nicht behoben.
Die Sicherheitslücke manifestierte sich in der Implementierung von memcpy() und memmove() in der Assemblersprache für ARMv7 und wurde durch eine fehlerhafte Verarbeitung negativer Werte des Parameters verursacht, der die Größe des kopierten Bereichs bestimmt. Probleme mit der Patch-Entwicklung begannen, als Unternehmen и gab bekannt, dass ihre Plattformen von dem Problem nicht betroffen sind, da sie nicht für 32-Bit-ARMv7-Systeme bauen und sich nicht an der Erstellung eines Fixes beteiligt haben. Die Entwickler vieler eingebetteter Distributionen haben sich offenbar auf das Glibc-Team verlassen und waren auch nicht aktiv an der Vorbereitung des Fixes beteiligt.
Option Um das Problem zu beheben, schlug Huawei fast sofort vor, Assembleranweisungen, die mit vorzeichenbehafteten Operanden (bge und blt) arbeiten, durch vorzeichenlose Analoga (blo und bhs) zu ersetzen. Glibc-Betreuer entwickelten eine Reihe von Tests, um verschiedene Fehlerbedingungen zu überprüfen. Anschließend stellte sich heraus, dass der Huawei-Patch nicht geeignet war und nicht alle möglichen Kombinationen von Eingabedaten verarbeitete.
Da Aurora OS über eine 32-Bit-Version für ARM verfügt, beschlossen die Entwickler, die Schwachstelle selbst zu schließen und der Community eine Lösung anzubieten. Die Schwierigkeit bestand darin, dass eine effiziente Assembler-Implementierung der Funktion geschrieben und verschiedene Optionen für Eingabeargumente berücksichtigt werden mussten. Die Implementierung wurde mit nicht signierten Anweisungen neu geschrieben. Es stellte sich als klein heraus, aber das Hauptproblem bestand darin, die Ausführungsgeschwindigkeit aufrechtzuerhalten und Leistungseinbußen der Funktionen memcpy und memmove zu vermeiden und gleichzeitig die Kompatibilität mit allen Kombinationen von Eingabewerten aufrechtzuerhalten.
Anfang Juni wurden zwei Versionen des Fixes vorbereitet, die das Test-Framework der Glibc-Betreuer und die interne Testsuite von Aurora bestanden haben. Am 3. Juni wurde eine der Optionen ausgewählt und zur Glibc-Mailingliste. In einer Woche
war ein weiterer Patch mit ähnlichem Ansatz, der ein Problem in der Multiarch-Implementierung behebt, das Huawei zuvor zu beheben versucht hatte. Der Test dauerte einen Monat und aufgrund der Wichtigkeit des Patches.
Korrekturen vom 8. Juli zum Hauptzweig der kommenden Glibc-Version 2.32. Die Implementierung umfasst zwei Patches − für die Multiarch-Implementierung von memcpy für ARMv7 und für die allgemeine Assembler-Implementierung von memcpy() und memmove() für ARM.
Das Problem betrifft Millionen von ARMv7-Geräten, auf denen Linux läuft, und ohne das entsprechende Update sind Besitzer gefährdet, wenn sie sie mit dem Netzwerk verbinden (über das Netzwerk zugängliche Dienste und Anwendungen, die Eingabedaten ohne Größenbeschränkung akzeptieren, können angegriffen werden). Der von den Forschern, die die Schwachstelle identifiziert haben, vorbereitete Exploit zeigt beispielsweise, wie man einen in ein Fahrzeuginformationssystem integrierten HTTP-Server angreift, indem man eine sehr große GET-Anfrage sendet und Root-Zugriff auf das System erhält.
Source: opennet.ru