Im mitgelieferten Dienstprogramm e2fsck , (), die die Ausführung von Schadcode bei der Überprüfung eines Dateisystems mit speziell formatierten Verzeichnissen ermöglicht. Die Sicherheitslücke wurde in den Versionen 1.43.3 bis 1.45.4 bestätigt. Die Sicherheitslücke wurde im Update behoben. . In Distributionen bleibt das Problem ungelöst (, , , , ).
Die Sicherheitslücke wird durch einen Fehler in der Funktion mutate_name() der Datei rehash.c verursacht. Diese dient zum Neuaufbau verzeichnisbezogener Hash-Tabellen, die alle Dateien eines Verzeichnisses abgleichen. Eine Beschädigung der verzeichnisbezogenen Hash-Eintragsstruktur kann dazu führen, dass Angreiferdaten außerhalb des zugewiesenen Puffers schreiben. Werden in der Hash-Tabelle eines Verzeichnisses mehrere Dateien mit gleichem Namen gefunden, benennt das Dienstprogramm e2fsck die doppelten Dateien um, indem es ~0, ~1 usw. an den Namen anhängt. Im Stack wird ein 256-Byte-Puffer reserviert, um den neuen Namen während der Umbenennung vorübergehend zu speichern.
Die Größe der kopierten Daten wird durch den Ausdruck „entry->name_len & 0xff“ bestimmt. Der Wert von „entry->name_len“ wird jedoch aus der Datenträgerstruktur geladen und nicht anhand der tatsächlichen Namensgröße berechnet. Bei einer Größe von null wird der Array-Index auf -1 gesetzt. Dies führt zu einem Integer-Unterlauf und überschreibt andere Daten im Stack mit dem Wert „~0“. Bei 64-Bit-Systemen gilt die Ausnutzung der Schwachstelle als unwahrscheinlich und erfordert keine Stackgrößenbeschränkung (ulimit -s unlimited). Bei 32-Bit-Systemen gilt die Ausnutzung als möglich, das Ergebnis hängt jedoch stark von der Kompilierung der ausführbaren Datei durch den Compiler ab.
Um einen Angriff durchzuführen, muss ein Angreifer die Daten einer Partition mit einem ext2-, ext3- oder ext4-Dateisystem beschädigen. Da dieser Vorgang Superuser-Rechte erfordert, stellt die Sicherheitslücke eine Bedrohung dar, wenn externe Laufwerke oder extern erstellte Dateisystem-Images mit dem Dienstprogramm e2fsck überprüft werden.
Source: opennet.ru
