[English]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. Ein Sicherheitsforscher hat jetzt zum wiederholten Mal darauf hingewiesen.
Anzeige
Ich habe die letzte Offenlegung von @jonasLyk vom 9. Januar 2021 auf Twitter mal herausgezogen – siehe nachfolgender Tweet. Der Zugriff auf einen präparierten Ordner reicht zur Ausnutzung der Schwachstelle. Das Ganze kann remote (z.B. Download einer präparierten Verknüpfungsdatei oder eines ZIP-Archivs) getriggert werden.
Jonas L. hatte bereits im August 2020 sowie im Oktober 2020 öffentlich auf diese NTFS-Schwachstelle aufmerksam gemacht, ohne dass etwas passierte. Daher hat er sich an Bleeping Computer gewandt, die das getestet und dann in diesem Artikel offen gelegt haben.
Ein knapper Befehl reicht
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. Sobald diese Datei gelesen wird, fordert Windows den Benutzer auf, den Computer neu zu starten, um die beschädigten Festplatteneinträge zu reparieren.
Anzeige
Bleeping Computer gibt hier einen Befehl als Beispiel für einen solchen Trigger an, warnt aber davor, dass auf einem System zu testen. Denn das NTFS-Laufwerk ist anschließend möglicherweise nicht mehr lesbar und verloren. Nach dem Ausführen des Befehls in der Windows 10-Eingabeaufforderung wird sofort der Fehler: "Die Datei oder das Verzeichnis ist beschädigt und nicht lesbar." angezeigt. Zum Testen sollte man eine virtuelle Maschine verwenden.
Der gezeigte Befehl greift auf das $130-Attribut eines NTFS-Datenträgers zu. Über dieses $I30-Attribut verwaltet das NTFS-Dateisystem einen Index aller Dateien/Unterverzeichnisse, die zu einem Verzeichnis gehören.
Aktuell ist unklar, warum der Zugriff auf dieses Attribut das Laufwerk beschädigt. Gegenüber Bleeping Computer sagte Jonas L.: 'Ich habe keine Ahnung, warum der Zugriff auf das Attribut die NTFS-Volumes beschädigt. Es wäre eine Menge Arbeit, das herauszufinden, weil der Reg-Schlüssel, der bei Beschädigung einen BSOD auslösen sollte, nicht funktioniert. Also überlasse ich das den Leuten, die den Quellcode haben.'
Es reicht, eine entsprechend präparierte Datei (z.B. .lnk-Datei) auf einem NTFS-Laufwerk abzulegen (die Daten braucht nicht geöffnet zu werden), um den Fehler zu triggern. Denkbar wären auch präparierte ZIP-Archive, die beim Entpacken den Fehler auslösen. Nachdem die Laufwerke beschädigt wurden, erzeugt Windows 10 Fehler im Ereignisprotokoll, die besagen, dass die Master File Table (MFT) für das jeweilige Laufwerk einen beschädigten Datensatz enthält.
Bug ab Windows 10 Version 1803
Wie Jonas L. gegenüber Bleeping Computer angab, konnte er den Fehler in Windows 10 Version 1803 ausnutzen. Der Fehler soll auch bis zur aktuellen Version 20H2 weiterhin ausnutzbar sein. Bleeping Computer schreibt im Artikel, das Quellen aus Kreisen von Sicherheitsforschern sagen, das solche schwerwiegende Sicherheitslücken wie diese schon seit Jahren bekannt sind. Die Bugs wurden Microsoft schon früher gemeldet, wurden aber aber nicht behoben.
Bleeping Computer hat bei Microsoft nachgefragt, um zu erfahren, ob sie bereits von dem Fehler wussten und ob sie den Fehler beheben würden. Die Antwort: "Microsoft hat sich gegenüber seinen Kunden verpflichtet, gemeldete Sicherheitsprobleme zu untersuchen und wir werden so schnell wie möglich Updates für betroffene Geräte bereitstellen." Bilde dir deinen eigenen Reim drauf.
Ergänzung: Es gibt einen inoffiziellen Fix/Workaround, siehe Windows 10 NTFS-Bug erhält inoffiziellen Fix von OSR
Anzeige
Das ist mal wirklich richtig … (mir fällt dazu kein Wort ein, was ich hier schreiben könnte!) Bis Microsoft das gefixt hat, sollte man auf keinen Fall irgendwelche Scripte aus dem Internet ungeprüft bei sich laufen lassen. Auch in Zip-Dateien sollte man erst reinschauen, bevor man sie entpackt (wer macht das schon, rechtsklick, auspacken, fertig…)!!!
diese Konzerne gehoeren zerschlagen. Leider klagt die ganze bevoelkerung nicht gegen solche widerlichen geschaeftspraktiken, daher hat sich die gesamte weltbevoelkerung mit solchen Dingen arrangiert wie keine patches und regelmaessigen updates, elektroschrott en masse, softwarebugs die jahrzehntelang in allen generationen der betriebssysteme relgemaessig wiederkehrend existieren etc pp
Dann nutze doch Linux statt hier zu jammern. Schon an ein beliebiges Distro dieses Jahr gespendet, oder muss alles umsonst sein?
Spannende Sache. Hab das gleich mal auf Server 2012 R2, 2016, 2019 und Windows 10 20H2 probiert. Die letzten beiden melden wie erwartet Fehler und führen nach dem Reboot chkdsk aus. Zumindest scheint die Platte danach aber in Ordnung zu sein.
Wenn die Platte danach in Ordnung ist, wo liegt dann das Problem?
Frag dich das nochmals, wenn einer deiner Server ständig in chkdsk läuft, weil z.B. kontinuierlich präparierte Dateien (z.B. per Mail-Server) einfliegen. Und wer sagt, dass das in allen Fällen gut ausgeht?
Werde das mal wenn ich Zeit habe mal unter einer VM in Windows 8.1 x64 und einer Windows XP SP3 VM ausprobieren.
Es wäre ja untypisch für Microsoft wenn der Fehler nur auf dem neusten Betriebssystemen auftritt.
Der Grund, warum Microsoft bisher nicht auf das Problem reagiert hat, könnte sein, dass dieses vermeintliche Sicherheitsleck bisher noch nicht ausgenutzt wurde.
Wenn man die entsprechenden Suchbegriffe in die Suchmaschine eingibt, findet man nur sehr wenig bis gar nichts zu dem Problem.
Ob dieser Jonas L. die Meldung tatsächlich bereits mehrfach an MS abgesetzt hat, kann man glauben, oder auch nicht. Dass irgendwelche Sicherheitsforscher angeblich auf diese schwerwiegende Sicherheitslücke hingewiesen haben sollen -und das bereits seit Jahren- davon steht aber nichts in dem zu BleepingComputer verlinkten Artikel.
Es behauptet sicher niemand, der halbwegs seriös unterwegs ist, dass es keine unentdeckten Sicherheitslecks in einer Software geben könnte. Das Problem dabei ist aber doch sehr wahrscheinlich, dass Sicherheitslecks erst dann reproduzierbar sind, wenn sie von Angreifern bereits in relativ großer Anzahl aktiv ausgenutzt worden sind.
Erst dann kann man die Lücken schließen.
Grundsätzlich gilt doch aber -und ich denke, da wird man mir zustimmen- dass der effektivste Schutz in erster Linie das halbwegs vernünftige Verhalten der Benutzer, genannt "brain.exe", ist.
Wer unbekannte Dateien oder Anwendungen aus dem Internet herunterlädt und diese dann ungeprüft und arglos ausführt oder öffnet, dem ist sowieso nicht mehr zu helfen.
Hinweise und Warnhinweise zum Thema Sicherheit findet man mehr als genug im Internet.
Aber gut, dieses Thema gibt es schon seit vielen Jahren und es ändert sich nur sehr wenig.
Wieso kann man die Lücke erst schließen, wenn Angriffe darauf bekannt werden? Meiner Meinung nach kann man Lücken schon schließen, wenn sie entdeckt werden.
Weil die Lücke den Entwicklern erst durch Ausnutzung der Schwachstelle bekannt wird? Nachdem sie ihnen gemeldet wurde?
Ob sie tatsächlich gemeldet wurde, ist nicht belegt, sondern steht nur als Behauptung eines Einzelnen im Raum. Wie bereits erwähnt, das kann man glauben, oder auch nicht.
Vielleicht ist es ja auch gar nicht so einfach, die Lücke zu schließen. Könnte doch sein.
Oder das Leck wird, falls die Entwickler darüber in Kenntnis sind, nicht als "schwerwiegend" eingestuft? Nur weil einer bei Twitter behauptet, sie sei schwerwiegend, muss das nicht jeder so sehen.
Ich kann mir beim besten Willen nicht vorstellen, dass ein Entwickler so fahrlässig sein könnte, schwerwiegende Sicherheitslecks auf Dauer nicht zu schließen.
Dieses Thema hier lässt wieder mal sehr viel Raum für Spekulationen und subjektiven Wahrnehmungen.
Jeder Fehler, der zum System-Absturz führt, ist schwerwiegend. Jeder Fehler, der zum Korrumpieren des Dateisystems führt, ist schwerwiegend. Jeder Fehler, der so einfach von einem unpriviligierten Benutzer ausgelöst werden kann, ist schwerwiegend. Noch Fragen?
Eine Lücke, die online beschrieben wird, muss nicht gepatcht werden, bevor sie auch ausgenutzt wird? Was ist das denn?
Wie schwierig die Lücke zu schließen ist, kann nur Microsoft beantworten. Da sie sich per Eingabeaufforderung, Powershell, Link-Datei, URL-Datei, ZIP-Datei, Mailanhang, HTML-Anweisung, usw. ausnutzen lässt, scheint sie wohl tiefer im System vergraben zu sein.
IMHO ist das auf jeden Fall einen außerplanmäßigen Hotfix wert.
Das bestreite ich alles nicht. Es geht nur darum, dass die Entwickler Kenntnis von der Schwachstelle haben müssen. Nur dann kann eine Überprüfung überhaupt stattfinden und ggf. ein Fix auf den Weg gebracht werden.
Der Grund, warum von MS bisher noch kein Fix auf den Weg gebracht wurde, ob dahingehend eine Notwendigkeit besteht und ob das überhaupt (schnell) umsetzbar ist, ist nicht bekannt und deswegen ist alles darüber reine Spekulation. Da beziehe ich mich mit ein.
Man darf aber durchaus davon ausgehen, dass MS ein sehr großes Eigeninteresse daran hat, vorhandene Sicherheitslecks möglichst umgehend zu schließen.
Entwickler erhalten nicht automatisch mit dem Ausnutzen einer Lücke davon Kenntnis. Sieht man an der Solarwinds-Attacke, die hätte noch weiter gehen können, wenn die Einbrecher bei Fire-Eye nicht unvorsichtig geworden wären.
Oh, ein Microsoft-Mitarbeiter ist auch da!
Schön wärs. Die sollen ja angeblich sehr gut bezahlen.^^
Und wie immer verteidigt der gute Micha45 MS. Die Nutzer sind nämlich Schuld. Sollen gefälligst keine Dateien runterladen, die sie nicht selbst erstellt haben. Am Besten gehen sie gar nicht erst ins Internet. Und wer Daten auf einer Festplatte hat, dem ist ohnehin nicht mehr zu helfen. So etwas gehört schließlich in die Cloud. Und bei M$ ist das auch bombensicher. Ein Fix ist daher gar nicht nötig.
Wer die Ironie nicht findet…
Warum überrascht mich dein Kommentar jetzt nicht?
Weil du, außer unqualifizierte Kommentare und persönliche Anfeindungen abzusondern, nichts zu bieten hast.
Du tust mir leid, ernsthaft, und das ist nicht ironisch oder sarkastisch gemeint.
Hier lautet übrigens die Regel: Verbal abrüsten und persönliche Anfeindungen tunlichst unterlassen.
Darauf hatte Günter Born erst kürzlich an anderer Stelle hingewiesen.
Aber das interessiert dich ja nicht, du hast sicher deine eigenen Verhaltensegeln.
Nur ganz kurz – auf den Seromon 'gemeldet oder nicht' mag ich nicht eingehen – ich habe so einige Mails von Sicherheitsforschern, die MSRT auf Schwachstellen hingewiesen haben, als cc bekommen. Oft genug musste das MSRT mehrfach auf das Thema gestoßen werden – und hat manchmal nicht reagiert oder kam in die Pushen, nachdem Blogger und dann größere Seiten etwas aufgegriffen haben.
Zu deinem brain.exe -> Informiere dich über drive by downloads – es reicht, wenn im Browser eine präparierte Datei in den Temp-Ordner einläuft.
Ich mag jetzt keine große Diskussion der Art 'gehört sofort gefixt versus wir können warten' anzetteln. Wenn ich mir viele Blog-Beiträge so ansehe, wo ich auf Probleme hinweise, und allgemein relativiert wird, wird mir persönlich äußerst unwohl. Denn nach wie vor gilt der Spruch unserer Altvorderen: 'Der Krug geht solange zum Brunnen bis er bricht'.
Daumen hoch!
Oder auch: "Der Student geht solange zur Mensa, bis er bricht…"
Hallo zusammen,
auf einem Win10 1909 mit Benutzerrechten(!) wird mit der Eingabe des Befehls zwar das beschriebene Ereignis ausgelöst. Die Maschine bootet, dann erscheint Bluescreen beim Hochfahren, dann erfolgt nochmaliger Boot und dann läuft Filesystemcheck aber durch und behebt aufgetretene Probleme im Dateisystem. NTFS-Filesystem ist dann zum Glück wieder normal. Patchlevel der Maschine inkl. 01/2021 Patches.
Ist aber schon krass… funktioniert auch auf einem völlig zugenagelten Client mit eingeschränkten Benutzerrechten… Wenn's ein Benutzer oft genug wiederholt wird er evtl. die Kiste platt kriegen und dem Admin in Bedrängnis bringen.
Grüße
Wolfgang
Wiedermal lächerlich, wie sich die Leute darüber aufregen.
Leute, wenn ihr einfach so ohne Hirn irgendwelche Fremden programme Startet, runterladed oder entpackt.
Fremde an euren Rechner lasst und sie dort Werkeln lasst, dann habt ihr wirklich andere Probleme als eine Defekte NTFS Platte.
Leute die ohne Hirn am PC Sitzen haben es doch nicht besser Verdient.
Das sind Aufreger auf ComputerBild Niveau !
Mal schauen, wann sich der erste Aufregt, das man Windows ohne Doppelt & Dreifach Absicherung einfach Installieren kann.
Noch ein Microsoft-Mitarbeiter!
Lass gut sein, der Mensch stellt sich durch seine Platitüden selbst in die Ecke. Die Information ist oben im Text zu finden – es mag jeder damit umgehen wie er es für sinnvoll hält. Wenn 'sein Hirn' einen drive-by-Download einer beliebig gehackten Webseite a priori erkennen kann, ist doch super … wäre aber irgendwo Nobelpreis-verdächtig.
Es gibt einfach keinen Grund Panik zu Verbreiten für Probleme die keine sind.
Solche dinge Lernen kinder in der ersten klasse.
Aber, es gibt eben auch Menschen die 100€ Überweisungsgebühren nach Afrika schicken,
um die Millionen $ von Prinz Abuganda zu erhalten.
(Wäre übrigens mal ne News wert, immerhin eine Massive Banking Sicherheitslücke)
Drive-By…oh ja, sehr Gefährlich, und beim Ausführen z.b. der Link Datei klickt wieder ein Unachtsamer benutzer einfach auf Ja.
Also auch dort sitzt das Problem vorm PC.
Kann ja auch nichts schlimmes sein, wenn beim Surfen Plötzlich ein fremdes Programm starten möchte.
Machen wir alle sowieso Täglich !
Na ja, wenn du den Text mal lesen würdest… Es reicht offenbar, wenn die Datei auf die Festplatte gespeichert wird. Und das würde sie wohl zwangsläufig, nämlich im Browsercache. Aber gut, das mit dem Hirn ist halt so eine Sache.
Davon abgesehen sind solche Platitüden generell vollkommen daneben. Wir als Admins großer Umgebungen sind dann die, die es ausbaden dürfen. Die Mehrzahl der Mitarbeiter hat nun mal keine Ahnung und klickt immer wieder irgendwelches Zeug an, auch wenn man es ihnen hundertmal sagt. Die kann man auch nicht alle kündigen, weil Leute wie du tolle Sprüche klopfen.
Es muss gar kein fremdes Programm starten, denn die Explorer-Vorschau reicht aus.
Man muss also nur mit dem Explorer mal den Temp-Ordner öffnen, wo die Drive-by-Datei gespeichert wurde und der Fehler tritt automatisch auf.
@riedenthied
Wie war das mit "den Text mal lesen" ?
"One striking finding shared by Jonas with us was that a crafted Windows shortcut file (.url) that had its icon location set to C:\:$i30:$bitmap would trigger the vulnerability even if the user never opened the file!"
oder den Befehl "CD C:\:……" ausführen.
Nun, um einen Befehl auszuführen, müsste zumindest eine Batch datei ausgeführt werden.
Dabei wird der Benutzer vorher Gefragt.
Ok, nehmen wir die Datei Icon angabe in einer URL Datei.
Passiert ja auch regelmäßig, das die Leute ihren Temp Ordner oder Browser Cache durchstöbern um Verdächtige Dateien zu suchen.
Klar, macht jeder benutzer fast Täglich, weil man das eben so macht.
Die Dateien landen wenn überhaupt irgendwo, wo sie sowieso nie jemand suchen würde.
Dann eben als Zip…. in den Temp oder Cache.
Alles sehr Sinnvoll und Super Gefährlich.
Ja, mein Guter. Beruhige dich. Du hast bestimmt recht und ich hab meine Ruhe.
Besonders interessant in der Twitter-Diskussion ist die Aussage:
Es ist kein Fehler der NTFS Spezifikation, sondern ein Fehler im NTFS-Treiber von Windows. (10 oder auch 8.1?)
Jetzt müsste man das Verhalten unter Ubuntu (Linux) einmal prüfen.
So einen Bug im Treiber sollte Microsoft zügig beheben können.
Windows 10 20H2 Pro Domain joined klappt nicht. Der Befehl sagt zwar, dass evtl. etwas beschädigt ist, aber es ploppt dieses popup nicht auf, nach einem Neustart gibt es noch ein kurzes chkdsk (das wird scheinbar getriggert) das war's dann aber auch schon. Als Admin und ohne Admin probiert gleiches Ergebnis. Wir haben unter anderem die Microsoft Security Baseline umgesetzt…evtl. verhindert da etwas die vollständige Ausführung des Befehls.
Auf Windows 7 erscheint nur eine Fehlermeldung, wenn ich den Befehl in die Konsole eintippe:
"Der Verzeichnisname ist ungültig"
Scheint also nicht zu funktionieren mit Win7.
Wenn es nur ein Fehler im Treiber ist und nicht in der Implementation von NTFS, wie im Twitter-Thread erwähnt, dann dürfte jede Windows-Version (vermutlich) anders reagieren.
Allerdings hat Microsoft chkdsk ab Windows 8 MASSIV verbessert. Auch dort gab es also eine Änderung.
Es steht auch schon geschrieben, dass Windows 10 ab Version 1803 anfällig ist. Vorher nicht. Das bestätigen auch meine Tests mit Server 2012 R2 (Windows 8.1 Kernel) und Server 2016 (Windows 10 1607). Die sind beide nicht anfällig, der Server 2019 ist es (Windows 10 1809 Kernel).
Unter "Windows 10 Version 1909 Home" erscheint sofort nach Eingabe des Befehls in eine Konsole folgende Fehlermeldung:
"Die Datei oder das Verzeichnis ist beschädigt und nicht lesbar."
Rechts unten erschien auch ein Popup bezüglich Beschädigung und Neustart.
Nach dem manuellen Neustart erfolgt dann
1. eine automatische Datenträgerreparatur und
2. anschließend noch eine automatische Diagnose des PC und
3. eine weitere automatische Datenträgerreparatur und
4. ein weiterer automatischer Neustart
Ein weiteres manuelles chkdsk in einer Konsole fand dann keine Fehler mehr.
Der NTFS-Treiber von Windows 10 hat also den Fehler und Windows 7 hat den Fehler nicht.
Für alle, die denken das wäre ja gar kein Problem.
Man muss sich nur bestimmte Szenarien vorstellen.
* Angenommen in einer Schule können die Schüler auf ein Netzlaufwerk Dateien ablegen. Gezielt den Server herunterfahren zu können, kann dann schon recht unangenehm sein.
* Ich gebe zu es kommt seltener vor, dass ein FTP Server ein MS Server ist, aber angenommen jemand kann auf einen MS Server per FTP oder HTTP Upload Dateien hochladen.. na dann viel Spaß…
* Wenn dadurch ein Treiber abstürzt und das System rebootet wird, dann kann eventuell noch ein weiterer exploit passieren, der noch nicht entdeckt ist. D.h. in seiner Verletzbarkeit könnte der Server zusätzlich kompromittiert werden.
Also mal langsam: Im Betreff steht, NTFS-Inhalte könnten zerstört werden? Was lässt auf so etwas schließen? Im Tweet steht, dass ein Popup erscheint – fertig.
Ich habe gerade getestet in einer Windows-10-VM nach Snapshot:
Der Zugriff via cd in einer nicht-administrativen Konsole zeigt bei mir gar nichts an, außer dass es das Verzeichnis so nicht gibt bzw. es ggf. beschädigt ist. So schön, so gut. Eine weitere Meldung erschien nicht.
Danach habe ich eine administrative Konsole geöffnet und chkdsk ausgeführt. Ergebnis: "Es wurden keine Probleme gefunden".
Nach einem manuellen Neustart wurde dann allerdings eine offensichtlich geplante Datenträgerüberprüfung ausgeführ – ob ein Defekt oder effektive Reparatur durchgeführt wurde, mutmaßich hier hier mal: NEIN. Bis zum Beweis des Gegenteils. Denn mein chkdsk (ohne /f) zeigte ja, dass – ebenso mutmaßlich – nichts zerstört wurde. Der Ausgabe von chkdsk traue ich zunächst mal.
Letzendlich hat der nicht-administrative Zugriffsversuch quasi lediglich die Notwendigkeit (Empfehlung?) zu einer Datenträger-Überprüfung gesetzt. Da mag man jetzt von Übervorsichtigkeit sprechen, aber einen Schaden kann ich hier nicht erkennen.
Oder habe ich etwas übersehen? Daher scheint hier auch keine übertriebene Dringlichkeit bei Microsoft vorzuherrschen.
Noch problematischer könnte es werden, wenn man nicht sofort neustartet und die Fehler durch checkdsk reparieren lässt, sondern weiter versucht Dateien zu schreiben, während der NTFS-Treiber bereits als abgestürzt gilt bzw in einem undefinierten Zustand ist.
Wer weiß, wo der dann überall rein schreibt und Dateien erstmal unbemerkt mit irgend welchem Datenmüll überschreibt.
Das merkt man dann evtl erst viel später, dass die Daten in den Files inkorrekt sind.
Falls man genau die Stelle im NTFS-Treiber findet, wo der Fehler auftritt, dann könnte man hinter diese Stelle im RAM evtl auch beliebigen Code schreiben, der dann alles mögliche anstellen kann, etwa Rechte erhöhen und neues Admin-Konto einrichten und Daten rausleiten etc.
Bezüglich ZIP gab es auch mal einen üblen Trick, nämlich ein sich rekursiv auspackendes ZIP.
So ein ZIP kann sehr klein sein, aber da es in einer rekursiven Schleife läuft, schreibt es endlos die Platte voll bis nichts mehr geht.
Siehe 42.zip Archivbombe.
Wenn man in so ein rekursives ZIP noch zusätzlich so einen NTFS-Killer reinpackt, dann hat checkdsk ordentlich was zu tun, sofern überhaupt noch was zu retten ist.
Was lässt dich mutmaßen, dass außer dem fsck-Flag etwas beschädigt wurde oder der NTFS-Treiber abgestürzt ist? In meinem Test habe ich dafür keine Hinweise. chkdsk – gestartet vor dem Windows-Neustart – hat auch alles überprüft und keine Fehler festgestellt.
Aktuell stellt es sich für mich lediglich so dar, dass bei einem ungewöhnlichen Aufruf die Entwickler des NTFS-Treibers einen möglichen Strukturfehler nicht ausschließen möchten und daher eine Strukturüberprüfung anordnen für den nächsten Neustart. Ob eine Reparatur nötig war/ist/durchgeführt wurde, bezweifele ich zunächst, bis ich dafür Hinweise habe.
Ich beschränke mich auf Fakten und eigene Testergebnisse und lasse Mutmaßungen lieber mal weg. Ansonsten erbitte ich Links auf entsprechende Tests/Szenarien, in denen etwas passiert ist, was noch nicht mal im Tweet erwähnt wurde, jedoch hier in der Beitrags-Überschrift und im Text.
Super das funktioniert sogar auf dem Netzlaufwerk oder einer Freigabe. Einfach und gemütlich in der Kommandozeile mit dem copy Befehl!
Spannend ein Online Test mit Checkdisk vor dem Neustart sagt aber das das Volume fehlerfrei sei! Eine Schattenkopie kann ich auch noch erstellen. Der Offline Test beim Neustart sagt das bei mir dann aber auch. Das sind erstmal meine Ergebnisse mit zwei Windows Server 2019 VMs und Patchstand Dezember 2020. Für mich sieht es erstmal so aus als würde das Volume auf Grund des Fehlers im Treiber als dirty makiert. Das sollte aber erstmal kein Problem sein. Bzw. nur insofern das der nächste Reboot länger oder vielleicht sehr viel länger dauert ;) Gab es nicht vor kurzem aber einen Fehler der dafür sorgte das Checkdisk das Volume zerstörte? Das würde dann für mich auch die Probleme erklären. Denn durch das dirty flag wird die Prüfung erzwungen aber zerstört wird das Volume dann eigentlich erst beim Prüfen!
Das chkdsk-Problem bezog sich nur auf die 20H2: Windows 10 2004/20H2: Microsoft fixt chkdsk-Problem in Update KB4592438
Klingt übel, hoffe alle habe den Patch zu diesen Problem installiert:
https://www.borncity.com/blog/2020/12/18/windows-10-20h2-achtung-chkdsk-beschdigt-das-dateisystem/
Welchen Patch soll ich da bitte installieren?
So wie ich das verstanden habe, führt dies Microsoft automatisch über irgendeinen "Remote-Zugriff" aus.
Wenn ich das ganze auf einer VM mit Windows XP mache erscheint die Meldung.
"Die Datei oder das Verzeichnis ist beschädigt oder nicht lesbar"
Im Ereignisprotokoll steht:
Ereigniskennung: 55
"Die Dateisystemstruktur auf dem Datenträger ist beschädigt und unbrauchbar. Führen Sie chkdsk auf Volume "C:" aus."
Beim Neustart wird dann chkdsk auf Volume C:\ ausgeführt. Nach erfolgreichen Abschluss von chkdsk starte die Windows XP VM nochmal neu. Sie fährt ohne Probleme wieder hoch. Die letzten Updates wurden auf der XP VM am 15.06.2017 Installiert. Es handelt sich also um einen halben "Bankautomaten"
Ein Windows 2000 Professional ohne Servicepack meldet:
"Zugriff verweigert"
Bei Windows 8.1 Pro x64 wird diese Meldung ausgegeben:
"Der Verzeichnisname ist ungültig"
Jedes Windows scheint den Zugriffsversuch also anders zu handhaben.
Wenns mit Win 2K kein Problem gibt, hab ich ja dann ab sofort eine neue Empfehlung für die Win 10 Skeptiker! Dankeschön!
Hier geht es wohl munter weiter
https://www.bleepingcomputer.com/news/security/windows-10-bug-crashes-your-pc-when-you-access-this-location/
Der Bug (initial von Walied Assar gemeldet) hat jetzt übrigens ein CVE Eintrag und ist von Microsoft in den Februar Patches gefixed https://www.bleepingcomputer.com/microsoft-patch-tuesday-reports/Feb-2021.html#CVE-2021-24098
I know, bin Freitag nicht dazu gekommen, das und weitere Sachen in der Patchday-Nachlese zusammen zu klempnern. Danke für den Hinweis.