[English]Entwickler von OSR haben einen Open-Source-Filtertreiber veröffentlicht, der verhindert, dass der kürzlich öffentlich gewordene NTFS-Bug, mit dem sich NTFS-Datenträger beschädigen lassen, ausgenutzt werden kann. Damit ist eine temporärer Absicherung der betroffenen Windows 10- und Server-Systeme möglich, bis Microsoft endlich mit einem Fix um die Ecke kommt.
Anzeige
Worum geht es bei NTFS-Bug?
In der von Windows 10 benutzten Implementierung des NTFS-Dateisystem gibt es eine bisher ungepatchte Schwachstelle. Über diese Schwachstelle ist es Angreifern möglich, den Inhalt eines unter Windows 10 verwendeten NTFS-Datenträgers zu zerstören. Es reicht, eine entsprechend präparierte Datei auf einem NTFS-Datenträger abzulegen, um den Fehler auszulösen. Sicherheitsforscher @jonasLyk hatte wiederholt auf diese Schwachstelle hingewiesen. Erst als Medien das im Januar 2021 aufgriffen, gab es ein größeres Echo.
Ich hatte die Details dieser Schwachstelle im Blog-Beitrag Windows 10: Schwachstelle ermöglicht NTFS-Medieninhalte zu zerstören aufbereitet. Einem Angreifer, der diese Schwachstelle ausnutzt, reicht ein einzeiliger Befehl, um eine NTFS-formatierte Festplatte zu beschädigen. Dazu kann eine präparierte Datei (auch remote) auf dem betreffenden Laufwerk in einem Ordner abgelegt werden.
Im günstigsten Fall wird nur eine Fehlerprüfung des NTFS-Volumens ausgeführt und der Datenträger repariert. Es gibt aber auch Fälle, wo die Maschine anschließend nicht mehr booten konnte. Eigene Tests und Rückmeldungen aus der Leserschaft ergaben, dass so gut wie alle Windows 10-Versionen und auch die Server Pendants betroffen sind. Nur in älteren Windows-Versionen lässt sich der Bug nicht ausnutzen.
Open-Source-Filtertreiber von OSR als Fix
OSR ist eine auf Windows-Interna spezialisierte Software-Entwicklungsfirma, die sich des Problems angenommen hat. Die Entwickler schreiben, dass das NTFS-Dateisystem (oder die Datei oder das Verzeichnis) zum Zeitpunkt wo die Warnung auf eine Beschädigung angezeigt wird, sicherlich nicht beschädigt sei. Die ausgelöste Warnung ist unschön und erzwingt ein chkdsk beim nächsten Booten. Die Entwickler schreiben, dass sie ein System bei OSR haben, das nach Tests nicht mehr bootet, nachdem ein zweites chkdsk ausgeführt wurde.
Anzeige
Daher haben die Entwickler einen Filtertreiber als temporäre Lösung entwickelt, der die kritischen $I30:$Bitmap-Befehle, die an den NTSF-Gerätetreiber geschickt werden können, abfängt. Das Ganze wurde als Open-Source-Lösung als Release v1.0.0 · OSRDrivers/i30Flt (github.com) auf Githib freigegeben.
Laut OSR gibt es keine Möglichkeit, dieses Problem ohne ein Update für Windows vollständig zu beheben. In der Zwischenzeit können Nutzer aber den obigen Mitigationsfilter von GitHub herunterladen und verwenden. Signierte Binärdateien für x86 und x64 stehen für Sie zur Installation bereit. Weitere Details sind diesem OSR-Blog-Beitrag zu entnehmen. (via)
Anzeige
"Eigene Tests und Rückmeldungen aus der Leserschaft ergaben, dass so gut wie alle Windows 10-Versionen und auch die Server Pendants betroffen sind. Nur in älteren Windows-Versionen lässt sich der Bug nicht ausnutzen."
Ich lese das bei Bleeping anders:
"BleepingComputer later learned that this bug also affected older versions of Windows, including Windows XP."
Außerdem hilft der Fix scheinbar nur gegen die ":$i30:" Stream-Pfade, nicht aber gegen die zweite Variante mit "\\.\globalroot".
Da ich immer noch nicht rausbekommen habe, für was diese Pfade normalerweise gut sind, kann ich allerdings nicht abschätzen, ob durch Installation dieses Filtertreibers nicht auch was kaputt gemacht wird, sprich, ob irgendwelche Software dann auf einmal nicht mehr funktioniert, deswegen installiere ich diesen Patch nicht. Lieber vorsichtig sein, im doppelten Sinne.
@1ST1 :
"Da ich immer noch nicht rausbekommen habe, für was diese Pfade normalerweise gut sind" (ich habe danach auch erfolglos gesucht)
Hm..grübel..paranioa=ON
Warum baut MS den Fehler nicht einfach aus, ja ignoriert die Meldung über Monate?
Bei einem voll reproduzierbaren Fehler?
Seltsam…wer mag ein Interesse daran haben den Zustand einer Platte einzufrieren
oder sie in einem Sekundenbruchteil unbrauchbar zu machen?
(die Daten bleiben ja auf der Platte, sind nur nicht so leicht runterzuholen)
Ist die Platte danach noch mit "format" noch erreichbar?
Wenn nicht, fielen mir da schon ein paar Institutionen ein, die da ein gewisses Interesse haben könnten. ;)
Ich würde vermuten das man die Platte danach noch "roh" mounten kann und mit tools wie photorec die Daten teilweise runter kratzen kann. MS hat ja inzwischen den Unfug gelassen, dass man SSDs nicht defragmentieren darf. Die Daten liegen also meist schön geordnet auf der Platte.
Was ihr alles so vermutet… Zugriff auf den Pfad mit \\.\globalroot führt nur zu Abstürzen, danach kann, muss aber das Dateisystem nicht defekt sein, und – ihr wisst es aus eigener Erfahrung – chkdsk schafft es meistens, das zu reparieren. Bei den Zugriff auf :$i30: wird anscheinend nur ein Checkdisk-Flag gesetzt, worauf Windows dann einen Neustart für Filesystemcheck anfordert. Normalerweise geht da – nach jüngsten Erkenntnissen – nichts weiter kaputt. Die Horror-Meldungen dass das System danach nichtr mehr hoch kommt, konnte ich bei eigenen Tests bisher nicht nachstellen, ich vermute daher momentan, dass bei den Fällen das Dateisystem schon vorher einen massiven Knacks hatte, der noch nicht bemerkt wurde.
Übrigens melden sich erste Antivirus-Hersteller bei Supportanfragen, dass sie inzwischen solche Dateizugriffe abfangen können.
Die Daten gehen ja in den meisten Fällen dadurch nicht verloren, chkdsk muss ja eigentlich nur den Check-Flag wieder zurück setzen, dann ist alles gut, jedenfalls meistens. Eine Verschwörungstheorie sollte man also dahinter nicht vermuten. Nur einen ärgerlichen dummen Bug, den MS hoffentlich zum nächsten Patchday schließt, ohne irgendwelche Inkomatiblitäten zu verursachen.
Das ist wohl eine Art Zeitbombe.
Erst wenn der Rechner bootet zerlegt chkdsk u.U. das Filesystem?
Wer probiert denn endlich mal aus, was da kaputt geht?
4GB Bootplatte
Booten
image erstellen
Die böse Datei anlegen
chkdsk machenn lassen
image erstellen
Images vergleichen… :-)
Ich habe es schon weiter unten aufgeführt aber in einer Windows Server 2019 Gen2 VM auf einem Windows Server 2019 Hyper-V konnte ich das Dateisystem auch mit mehreren Versuchen nicht zerlegen! Das heißt nicht das es allgemein keinen Fehler gibt aber bis jetzt sehe ich hier noch keinen Beweis für Dateisystemschäden. Ich konnte sogar noch Volumenschattenkopien anlegen, da ist Windows bei Dateisystemproblemen manchmal etwas penzig.
Spannend aber ich hätte nicht den Mut das auf dem Fileserver meines Arbeitgebers zu installieren und privat brauche ich das nicht ;)
Ist meiner Meinung nach vorallem eine rechtliche Frage. Was ist wenn mit dem Filertreiber doch irgendwas schief läuft und Schaden entsteht. Oder es passiert etwas und dann wird behauptet man hätte da manipuliert und das wäre die Ursache für den Fehler auch wenn dies vielleicht nicht stimmt. Ja das klingt schon ziemlich nach Paranoia aber ich habe leider schon den einen oder anderen etwas seltsamen Chef erleben dürfen.
"Was ist wenn mit dem Filertreiber doch irgendwas schief läuft und Schaden entsteht"
Kann man MS dafür haftbar machen, dass das auch ohne Open Source Treiber passieren kann (sic!)?
Wenn der Fehler nachweislich ohne den Filterteriber nicht passiert?
Es braucht ja nur gleichzeitg ein anderer Fehler auftreten, wie soll ich denn beweisen das das nicht der von mir eingesetzte Filtertreiber war? Kann ich nicht und damit ist diese Lösung für mich nicht einsetzbar. Ohne den Filtertreiber ist der Schuldige Microsoft ohne Wenn und Aber. Mit Filtertreiber bin unter Umständen ich der Schuldige, Danke Nein.
Noch ist nicht bewiesen das überhaupt ein Schaden am Dateisystem entsteht. Meine Tests mit Windows Server 2019 haben zwar eine Fehlermeldung und einen erzwungenen Checkdisk beim beustart ergeben aber wenn man weiß wie kann man den auch verhindern. Was dieser hier angebotene Filtertreiber aber für eventuelle Spätfolgen hat weiß ich nicht. Ich glaube das es keine Probleme geben dürfte aber im Fall der Fälle muss man gegen Menschen argumentieren die den IT-Sachverstand einer Bananenschale haben :) Recht haben und Recht bekommen sind zwei große Unterschiede. Ich war auch leider schon als Dritter in solchen Verfahren involviert und meine Lehre daraus ist extrem vorsichtig zu sein. Solche Risken gehe ich nicht ein.
Dann ließ mal die EULA durch :-)
"Wir sichern nicht zu das diese Software für irgendeinen Zweck geeignet ist.".
Ja, ist schon seltsam, was sich alle Software-Hersteller
legal leisten können.
Aber:
Wenn man sich einen Hammer kauft und der Kopf fliegt ab,
ist der Benutzer haftbar für die Beule, nicht der Hammer hersteller, wenn dieser die Norm eingehalten hat.
Welche Norm muß bei Software eingehalten werden?