Cisco-Sicherheitsforscher Einzelheiten () in der Implementierung der von Glibc bereitgestellten memcpy()-Funktion für die 32-Bit-ARMv7-Plattform. Das Problem wird durch eine falsche Behandlung negativer Werte des Parameters verursacht, der die Größe des kopierten Bereichs bestimmt, aufgrund der Verwendung von Assembly-Optimierungen, die vorzeichenbehaftete 32-Bit-Ganzzahlen manipulieren. Der Aufruf von memcpy() auf ARMv7-Systemen mit einer negativen Größe führt zu einem falschen Wertevergleich und schreibt in einen Bereich außerhalb der Grenzen des angegebenen Puffers.
Die Sicherheitslücke kann ausgenutzt werden, um Code in einer Situation auszuführen, in der der Angreifer die Bildung eines negativen Werts der Variablen organisieren kann, über die die Größe der kopierten Daten übertragen wird (z. B. wird sie negativ, wenn mehr als 2 GB übertragen werden). Daten, aber während des Angriffs müssen Sie mindestens 4 GB übertragen, um die Puffergrenzen zu überschreiten. Die memcpy()-Funktion wird häufig in Anwendungen verwendet, und ARMv7-Prozessoren kommen häufig in Automobilsystemen, Mobil-, Industrie-, Verbraucher-, Kommunikations- und eingebetteten Geräten vor, die potenziell Angriffen über Bluetooth, HD-Radio/DAB, USB, CAN-Bus usw. ausgesetzt sind. WLAN und andere externe Datenquellen (z. B. über das Netzwerk zugängliche Dienste und Anwendungen, die Eingabedaten ohne Größenbeschränkung akzeptieren) können angegriffen werden.
Ein Beispiel ist die Erstellung eines funktionierenden Exploits zum Angriff auf einen in Fahrzeuginformationssysteme integrierten HTTP-Server, auf den über das WLAN-Netzwerk des Fahrzeugs zugegriffen werden kann. Ein externer Angreifer könnte eine Memcpy-Schwachstelle auf diesem Server ausnutzen, indem er eine sehr große GET-Anfrage sendet und sich Root-Zugriff auf das System verschafft.
Auf 32-Bit-x86-Systemen tritt das Problem nicht auf, da die Memcpy-Implementierung für diese Architektur die Größenvariable korrekt als vorzeichenlosen ganzzahligen Wert vom Typ size_t (in Assemblersprache) interpretiert für ARMv7 wird es als vorzeichenbehaftete Ganzzahl statt size_t behandelt. Der Fix ist derzeit verfügbar als , das im Glibc 2.32-Update vom August enthalten sein wird.
Der Fix läuft darauf hinaus, die Verwendung von Assembleranweisungen, die mit vorzeichenbehafteten Operanden (bge und blt) arbeiten, durch vorzeichenlose Gegenstücke (blo und bhs) zu ersetzen.
Das Problem ist noch nicht gelöst (in Debian 8 nicht sichtbar), , , OpenEmbedded, Tizen (von glibc verwendet). и Das Problem ist nicht betroffen, da sie keine 32-Bit-ARMv7-Systeme unterstützen. Android ist von der Sicherheitslücke nicht betroffen, da es eine eigene libc-Implementierung (Bionic) verwendet. IN Standardmäßig verwenden die meisten Builds Musl, aber glibc ist auch im Repository verfügbar.
Source: opennet.ru