Sicherheitsforscher von Cisco Details () in der von Glibc bereitgestellten Funktion memcpy() für 32-Bit ARMv7-Plattformen. Das Problem wird durch die fehlerhafte Handhabung negativer Werte des Parameters, der die Größe des zu kopierenden Bereichs bestimmt, verursacht, was auf die Verwendung von assembleroptimierungen zurückzuführen ist, die mit signierten 32-Bit-Ganzzahlen manipulieren. Ein Aufruf von memcpy() auf ARMv7-Systemen mit einer negativen Größe führt zu einem fehlerhaften Vergleich von Werten und zu Schreibvorgängen außerhalb der Grenzen des angegebenen Puffers.
Eine Schwachstelle könnte ausgenutzt werden, um Code auszuführen, wenn ein Angreifer negative Werte in einer Variablen generieren kann, über die die Größe der zu kopierenden Daten übergeben wird (zum Beispiel kann ein negativer Wert entstehen, wenn über 2 GB Daten übertragen werden, aber um den Puffer zu überlaufen, müssen mindestens 4 GB übertragen werden). Die Funktion memcpy() wird häufig in Anwendungen verwendet, und ARMv7-Prozessoren sind weit verbreitet in Automobilsystemen, Mobilgeräten, Industrieanlagen, Verbraucherelektronik, Kommunikation und Embedded-Systemen, 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önnen netzwerkbasierte Dienste und Anwendungen angegriffen werden, die Eingaben ohne Größenbeschränkung akzeptieren).
Ein Beispiel zeigt die Erstellung eines funktionierenden Exploits für einen Angriff auf einen in automobile Informationssysteme eingebetteten HTTP-Server, der über das Auto-WLAN zugänglich ist. Ein unbefugter Angreifer kann eine Schwachstelle in memcpy auf diesem Server ausnutzen, indem er eine zu große GET-Anfrage sendet und root-Zugriff auf das System erhält.
Auf 32-Bit-Systemen (x86) tritt das Problem nicht auf, da die Implementierung von memcpy für diese Architektur die Variable korrekt als vorzeichenloses Ganzzahliges mit dem Typ size_t interpretiert (in der in Assembler geschriebenen Implementierung). Für ARMv7 wird es jedoch als vorzeichenbehaftete Ganzzahl behandelt. Das Update ist bisher verfügbar als , das im August-Update von Glibc 2.32 enthalten sein wird.
Die Lösung besteht darin, die Verwendung von assemblerbasierten Anweisungen, die mit vorzeichenbehafteten Operanden arbeiten (bge und blt), durch vorzeichenlose Alternativen (blo und bhs) zu ersetzen.
Das Problem wurde bisher nicht behoben in (in Debian 8 tritt es nicht auf), , , OpenEmbedded, Tizen (verwenden glibc). und Das Problem betrifft nicht, da sie 32-Bit ARMv7-Systeme nicht unterstützen. Android ist nicht anfällig für die Schwachstelle, da es eine eigene libc-Implementierung (Bionic) verwendet. In der Regel wird in den meisten Builds Musl verwendet, es gibt jedoch auch glibc im Repository.
Quelle: opennet.ru
