Sicherheitsforscher von Cisco Details () in der Implementierung der in Glibc bereitgestellten Funktion memcpy() für 32-Bit ARMv7-Plattformen. Das Problem resultiert aus der fehlerhaften Verarbeitung negativer Werte des Parameters, der die Größe des zu kopierenden Bereichs bestimmt, aufgrund von Assembler-Optimierungen, die mit 32-Bit vorzeichenbehafteten Ganzzahlen arbeiten. Der Aufruf von memcpy() auf ARMv7-Systemen mit einer negativen Größe führt zu fehlerhaften Vergleichen von Werten und Schreibvorgängen außerhalb der Grenzen des angegebenen Puffers.
Die Schwachstelle kann ausgenutzt werden, um Code auszuführen, wenn ein Angreifer ein negatives Wert für die Variable, die die Größe der zu kopierenden Daten überträgt, erzeugen kann (zum Beispiel ein negativer Wert wird übertragen, wenn mehr als 2 GB Daten übergeben werden; um jedoch außerhalb des Puffers zu gelangen, müssen mindestens 4 GB übergeben werden). Die Funktion memcpy() wird häufig in Anwendungen verwendet, und ARMv7-Prozessoren sind in Automobilsystemen, mobilen, industriellen, Verbraucherelektronik, Kommunikations- und Embedded-Geräten verbreitet, die potenziell Ziel von Angriffen über Bluetooth, HD Radio/DAB, USB, CAN-Bus, Wi-Fi und andere externe Datenquellen werden können (zum Beispiel könnten netzwerkbasierte Dienste und Anwendungen angegriffen werden, die Eingaben ohne Größenbeschränkung akzeptieren).
Als Beispiel wird die Erstellung eines funktionierenden Exploits zur Angreifung des in Automobilsysteme integrierten HTTP-Servers angeführt, der über das Auto-Wi-Fi-Netzwerk zugänglich ist. Ein externer Angreifer kann die Schwachstelle in memcpy auf diesem Server ausnutzen, indem er eine sehr große GET-Anfrage sendet und Root-Zugriff auf das System erhält.
Auf 32-Bit x86-Systemen tritt das Problem nicht auf, da die Implementierung von memcpy für diese Architektur die Variable für die Größe korrekt als vorzeichenloses Ganzzahlwert des Typs size_t interpretiert (in der Assemblerimplementierung für ARMv7 wird es als vorzeichenbehaftete Ganzzahl behandelt). Der Fix ist derzeit verfügbar in Form von , der im August-Update von Glibc 2.32 enthalten sein wird.
Der Fix besteht darin, die Verwendung von Assemblerbefehlen, die mit vorzeichenbehafteten Operanden arbeiten (bge und blt), durch vorzeichenlose Alternativen (blo und bhs) zu ersetzen.
Das Problem ist bisher nicht behoben in (zeigt sich nicht in Debian 8), , , OpenEmbedded, Tizen (verwendet glibc). und Das Problem betrifft sie nicht, da sie 32-Bit-ARMv7-Systeme nicht unterstützen. Android ist nicht von der Schwachstelle betroffen, da es eine eigene Implementierung von libc (Bionic) verwendet. In den meisten Builds wird standardmäßig Musl verwendet, aber im Repository ist auch glibc vorhanden.
Quelle: opennet.ru
