[English]In Windows 10 gibt es einen netten Bug, mit dem nach durch bestimmte Pfadeingaben (z.B. im Browser) einen Blue Screen of Dead (BSOD) auslösen kann. Sicherheitsforscher Jonas Lykkegaard hat auch diesen Bug im Herbst 2020 beschrieben.
Anzeige
Zum Wochenanfang ein neuer Hammer in Form eines Bugs in diesem modernen 'Windows 10', welches ja allseits 'über den grünen Klee gelobt wird'. Sicherheitsforscher Jonas Lykkegaard hat vorige Woche zwei Windows 10-Bugs mit denen er sich seit Monaten 'an Microsoft abarbeitet', zu Bleeping Computer gespült, um mehr Öffentlichkeit zu bekommen. Den ersten Bug hatte ich vorige Woche im Blog-Beitrag Windows 10: Schwachstelle ermöglicht NTFS-Medieninhalte zu zerstören angesprochen. Nun folgt der zweite Streich, ein Bug, der nichts mit der obigen NTFS-Schwachstelle zu tun hat.
Seit Oktober 2020 öffentlich, keine Reaktion
Jonas Lykkegaard hat die Information wohl letzte Woche den Kollegen von Bleeping Computer zugespielt, da seine Tweets, die er diesbezüglich seit Oktober 2020 veröffentlicht hat, ohne Resonanz blieben. Jonas L. weist in nachfolgendem Tweet darauf hin, dass Bleeping Computer es dann Sonntag Abend aufgegriffen hat.
Ungewöhnliche Pfadangabe führt zu BlueScreen
Kurzer Hintergrund: Entwickler können einen Pfad im Win32-Geräte-Namespace als Argument an verschiedene Windows-API-Aufrufe übergeben, um direkt mit Windows-Geräten zu interagieren. Dies ermöglicht z.B. den direkten Zugriff auf eine physische Festplatte, unter Umgehung der Dateisystem-API-Funktionen. Jonas L. ist dann auf den nachfolgenden Pfad gestoßen:
Anzeige
\\.\globalroot\device\condrv\kernelconnect
Der Pfad zeigt auf den Gerätenamen des "Konsolenmultiplexer-Treibers", wobei Jonas L. glaubt, dass der Pfad für die Kernel- / Usermode Interprozesskommunikation (IPC) verwendet wird. Aber das interessiert hier allenfalls als akademische Information am Rande. Der springende Punkt ist, dass man mit dieser Pfadangabe unter Windows 10 einen BlueScreen auslösen kann.
Ich habe mal meine Testmaschine mit Windows 10 20H2 (das 'Beste', was momentan in Sachen Windows 10 von Microsoft zu bekommen ist) gebootet. Dann habe ich den Google Chrome-Browser gestartet und den obigen Pfad im URL-Feld des Browsers eingetippt. Sobald ich die Eingabetaste drücke, um den Pfad ausführen zu lassen, stürzt Windows 10 mit einem veritablen BlueScreen ab.
Windows 10 BSOD
Es gibt zahlreiche Möglichkeiten, diesen Absturz zu provozieren, denn die URL lässt sich im Explorer, in einer Eingabeaufforderung (z.B. beim Login) und so weiter eingeben. Die Ausnutzung dieses Bugs hängt nicht von den Privilegien eines Benutzers ab, es funktioniert auch mit einem Standard-Nutzer. Ich habe den Test aus Faulheit per RDP-Sitzung von Windows 7 durchgeführt, die Testmaschine mit Windows 10 20H2 lag anschließend mit einem BlueScreen auf dem Kreuz.
Bleeping Computer hat die letzten Tage wohl eine Reihe Tests durchgeführt und schreibt, dass man den Bug von Windows 10 Version 1709 bis zur aktuellen 20H2 gefunden habe – ältere Builds hatte man nicht zur Verfügung. Der Bug betrifft natürlich nicht nur die Windows 10-Clients, sondern auch die Server, die auf diesen Builds aufbauen. Ist natürlich eine nette Möglichkeit, Maschinen Remote über solche Befehle kontinuierlich in eine BlueScreen-Schleife zu zwingen. Jonas L. hat Bleeping Computer eine Windows-URL-Verknüpfungsdatei (.url) geschickt, die auf \\.\globalroot\device\condrv\kernelconnect verweist. Wird eine solche Datei heruntergeladen, versucht Windows 10 den URL-Pfad aufzurufen und endet in einem BlueScreen.
Bleeping Computer schreibt, dass man inzwischen zahlreiche weitere Möglichkeiten gefunden habe, diesen Fehler auszunutzen. Darunter sind auch Methoden, um BSODs automatisch bei der Windows-Anmeldung auszulösen. In einem realen Szenario könnte dieser Fehler von Bedrohungsakteuren missbraucht werden, die Zugang zu einem Netzwerk haben und ihre Spuren während eines Angriffs verwischen wollen.
Ergänzung: Inzwischen ist mein Artikel bei heise zum Thema erschienen. Interessant ist diese Leser-Rückmeldung, dass der Befehl:
ls -l '//./globalroot\device\condrv\kernelconnect'
aus Cygwin die BSOD ebenfalls auslöst. Unterschiedliche Rückmeldungen gibt es, ob es in HTML mit einem img-Tag und der URL klappt.
In diesem Kommentar bestätigt jemand, dass auch Remote Desktop Hosts mit Windows Server 2019 betroffen sind. Es wurde erfolgreich mit Windows Server 2019 Version 1809 getestet, während Windows Server 2016 nicht betroffen zu sein scheint.
Dagegen gibt es in diesem Kommentar die Aussage, dass der BSOD unter Windows 10 Enterprise LTSC, Version 1809, OS Build 17763.1697 nicht auftrete. Es kommt der Fehler "Windows can't find '\\.\globalroot\device\condrv\kernelconnect'. Check the spelling and try again." Probiert wurde das mit dem Datei-Explorer und dem Internet Explorer. Dürfte aber an dieser Kombination hängen, da ich damit unter 1709 ebenfalls erfolglos war. Falls jemand die Kombination hat, wäre die Frage, ob sich der BlueScreen mit Chrome oder dem copy-Befehl in einer Eingabeaufforderung auslösen lässt. Ergänzung: In einem nachfolgenden Kommentar wird bestätigt, dass der copy-Befehl den BSOD auslöst. Beachtet zudem den Nachtrag, dass das Ganze auch mit einer lokalen HTML-Datei, die den Pfad als Link-Ziel aufweist, getriggert werden kann.
Ähnliche Artikel:
Windows 10: Schwachstelle ermöglicht NTFS-Medieninhalte zu zerstören
Fix für kaputte Windows 10 ‚PC zurücksetzen'-Funktion bestätigt
Windows 10 20H2: lsass-Absturzfehler 0xc0000374 behoben (7.1.2021)
Windows 10-Upgrade: Apps und Store verschwunden
Windows 10: Achtung, Treibersignierung ändert sich 2021, Alt-Treiber nicht mehr nutzbar
Anzeige
Grad getestet … funktioniert auch auf einem Server 2019
Bitte mal unter Windows 7 ausprobieren, und falls verfügbar auch unter XP.
Das andere Ding da mit NTFS "funktioniert" auch mit Windows 7 und XP. Daher wird hier 10 nicht über den grünen Klee für was gelobt, was sogar mit XP abstürzt.
Kann an meiner Unfähigkeit liegen. Unter Windows 7 bekomme ich beim Explorer und IE 11 eine Fehlermeldung, wenn ich diesen Pfad eingebe. Es sieht so aus, als ob das nicht unterstützt wird.
Auf Facebook habe ich von einem Blog-Leser die Rückmeldung bekommen, dass mit Edge unter Windows 10 der BSOD nur einmal auftritt. Erst wenn der Snapshot zurückgerollt wird, gibt es einen neuen BSOD. Aber ich stecke jetzt mal die Testerei auf … hab noch anderes zu tun. Die Infos liegen auf dem Tisch und ihr könnt ggf. testen. Hinterlasst einfach einen Kommentar bei neuen Ergänzungen.
Ergänzung: Wird noch mysteriöser – ich hatte noch eine alte VM mit Windows 10 1709 und Legacy Edge, ohne Chrome. Dort konnte ich weder im Edge noch im IE 11 den BSOD provozieren. Möglicherweise ist das Problem durch eines der Updates rein gekommen, da Bleeping Computer die V1709 als betroffen angibt.
Hab es jetzt in einer älteren VM mit Windows 10 V1709 – kein aktueller Patchstand, daher noch Legacy Edge, getestet. Ich kann den BSOD auf der Maschine nicht erzeugen (weder Edge noch IE 11). Chrome ist dort nicht vorhanden.
Selbiges unter Win8.1 ohne Edge. Pfad wird nicht gefunden, nichts passiert. Patchstand ist Januar 2021.
Windows 7 spricht darauf nicht an. Ich hab's über die Eingabeaufforderung versucht. Da kommt nur die Meldung: „Das System kann den angegebenen Pfad nicht finden." Windows 10 schmiert dagegen sofort ab. Krasses Fehlerbild.
2012 R2 zeigt sich vom Pfad unbeeindruckt. Völlig gleich ob CMD, PowerShell, Explorer oder der legendäre Internet Explorer.
Windows 8.1 x64 hat damit auch keine Probleme.
In der Eingabeaufforderung und im Internet Explorer 11 wird ausgegeben:
"Element nicht gefunden."
Der Windows Explorer meldet:
"konnte nicht zugegriffen werden"
Kann ich (leider) bestätigen:
HyperV-Test-VM: W10 Pro 20H2 (64bit deu)- komplett gepatched.
condrv.sys wird noch als Modul mit angezeigt.
Bei mir reicht es, die Zeile zu kopieren und in einer RDP-Session auch nur einfügen zu wollen…BSOD. Developer, Developer, Developer!
Aber wer braucht schon ein funktionierendes OS? Gerade in diesen Zeiten?!
Mit ultraVNC kann man den Link im Clipboard auf die Remote Maschine (z.B. in CMD-Fenster) kopieren. Das BSODed erst, wenn man die "return"-Taste drückt.
Vermutlich denkt MS:
Wenn der Client eh als ersts abstürzt sind die Server ja sicher….?
BSOD aus condrv.sys scheinen nicht wirklich neu zu sein…
Anno 2016:
https://answers.microsoft.com/en-us/windows/forum/windows_10-power-winpc/windows-10-gets-bluescreen-and-autorestarts/c5e69f7e-96b7-475d-89fd-13d95f00a4a6
Da hatt zwar "einfach so" BDOSed, aber schon seltsam.
Emm, was passiert eigentlich, wenn ein Linux-User eine .lnk mit
dem o.g. Pfad auf den "zentralen"-Firmen-Server hochlädt, und
dort der Virenscanner das File checken will?
BSODed der Client vor dem Server wenn man es irgendwie geschaft hat das .lnk auf den Windows-Client zu bekommen?
Oder BSOD der Server erst wieder, wenn der Virenscanner/das Backup vorbei kommt?
Es wäre schon sehr unangenehm, wenn der Virenscanner den "bösartigen" Path nicht erkennen würde und das .lnk auf dem Server landet, oder?
Kann gut sein dass der scanner links nicht folgt (warum sollte er) und es kann auch sein dass er den string als malware signatur erkennen wird und löschen. Aber kann natürlich auch sein das passiert was du vermutest – ich probiere es mal nicht aus :)
"Zum Wochenanfang ein neuer Hammer in Form eines Bugs in diesem modernen ‚Windows 10', welches ja allseits ‚über den grünen Klee gelobt wird'."
Schon etwas reißerisch und ein super Hammer, das ein Benutzer mit zugriff auf ein Windows einen BSOD erzeugen kann.
Wenn ich meinen Arbeitsrechner Abstürzen lassen möchte, kann ich ihn auch einfach runterfahren.
Sicher ist es ein Bug und kann behoben werden.
Und wenn er nicht behoben wird, was dann ? Reihenweise Bank mitarbeiter die ihren PC Abschiessen und dann einfach neu starten.
Oder Administratoren die Absichtlich die PCs ihrer Mitarbeiter Abschiessen, damit sie Arbeit bekommen und die Rechner neu Starten müssen.
WOW !
Ich neige dazu, dir Recht zu geben.
Doch natürlich muss das gefixt werden, damit Deppen nicht noch mehr Spielzeug in die Hand bekommen und einem die Arbeit schwer machen können.
Doch der Tenor in den Kommentaren*) ist irgendwie gruselig.
Ein 'Sicherheitsforscher' hat einen abstrusen Pfad gefunden?
Das dümmste Betriebssystem der westlichen Hemisphäre?
Du und ich sind jetzt sicher MS-Mitarbeiter…
Oh Mama, wo ist diese Sachlichkeit, wenn man sie mal braucht?
*) inkl. meinem
Der Ruf nach Sachlichkeit ist sicherlich angebracht. Polemik ist höchstens für die einen amüsant und für die anderen eine Provokation, die ihre eigene Entscheidung Windows zu benutzen in Frage stellt – letztendlich also nicht hilfreich.
ABER: Es ist gefährlich, solche Sicherheitsvorfälle rein subjektiv und aus dem Blickwinkel der Blase, in der man selbst lebt (Home-PC-User oder höchstens Arbeitsplatzrechner-User), zu betrachten.
Server-Betriebssysteme sind ebenfalls von der Lücke betroffen, der Browser ist nicht das einzige Einfalltor (im Gegenteil, es ist eine tiefliegende API im Windows Kernel, die letzendlich von allen Programmen benutzt wird, die mit Dateien arbeiten) und es gibt zig Konstellationen (auf Arbeitsplatzrechnern und Servern), die dazu führen, dass eine Datei automatisch geöffnet wird (z.B. durch den Virenscanner). Und wenn ein Server durch ständige Reboots aufgrund von BSODs quasi nicht mehr funktionsfähig ist, kann das je nach Einsatzbereich des Servers sehr wohl schwere Konsequenzen haben.
Von daher ist es völlig unangebracht, den Vorfall als nichtig oder überzogen dargestellt abzutun. Schlimm ist ja auch nicht die Tatsache, dass der Fehler existiert (ich bin selbst Entwickler und weiß, dass kein Code, der länger als ein paar Zeilen lang ist, als fehlerfrei angesehen werden kann) sondern die Ignoranz mit der Microsoft mit dieser und anderen Fehlermeldungen umgeht.
Man kommt sich da als Leser durch diese Polemik auch verarscht vor, das ist hier ja kein Spaß, unsereins muss mit Windows 10 leben und arbeiten, privat und/oder beruflich. Linux oder Windows 7 ist keine wirkliche Alternative, auch ESU wird nicht ewig weiter laufen, ich könnte mich damit nicht bis zur Rente retten, ohne nochmal was neues lernen und gewöhnen zu müssen. Und dann wird einem letztich an den Kopf geworfen, man sei doof, blöd oder sonst sowas, weil man das nutzt. Nein, es ist eine Abwägung der Anforderungen und Möglichkeiten. Ein polemischer Tritt in den Hintern ist da völlig unangebracht.
Es ist schon verständlich, wenn man auf Polemik verstimmt reagiert. Aber es ist auch notwendig, sich eine dicke Haut dagegen zuzulegen. Im Netz mit krassen Äußerungen aufzufallen ist halt sehr leicht und ebendiese zu verfassen auch, obendrein befriedigt das viele Leute auch noch. Daran wird man auch durch zurück beißen nichts ändern.
Die beste Waffe gegen Polemik ist ein besonnen formuliertes Statement, das auf messerscharfen rationalen Argumenten aufbaut. Polemik persönlich zu nehmen führt auch zu nichts.
Diese Polemik hat ihren Grund. Solche Meldungen gibt es im Wochentakt und fast immer ist nur Win10 davon betroffen. Es sollte jedem klar sein, dass das aktuelle System von MS nicht funktioniert und auch nie funktionieren wird. Nur weil du damit leben musst, musst du das nicht gut finden. Das ist ein weiterer kritischer Bug und da muss man sich auch mal was anhören. Wenn man damit Probleme hat, ist man offensichtlich ein Fanboy. Nur dann fragt man sich, warum sich nicht bei Dr. Windows tummelt, dort sieht man so etwas weitaus weniger kritisch.
Nein, Polemik ist nicht angebracht. Und es ist klar, dass momentan immer Windows 10 betroffen ist. Denn das ist das aktuelle Betriebsyystem von MS, mit dem auch die Mehrzahl arbeitet bzw. arbeiten muss. Lohnenswertes Ziel. So hat das natürlich die größte Aufmerksamkeit, bei den Benutzern, bei den Hackern, bei den Sicherheitsexperten, und hoffentlich auch bei Microsoft selbst. Es ist gut und wichtig, über solche Fehler zu reden, aber Polemik muss deswegen nicht sein. Das sind vielleicht ganz einfache Programmierfehler, und wer von uns hat noch nie eine fehlerhafte Arbeit abgeliefert? Bei einem so komplexen Werk wie einem modernen Betriebssystem – und da schließe ich Linux mit ein – wir reden hier über millionen Programmzeilen, passieren Fehler. Das ist völlig normal, sie müssen nach Identifikation nur zeitnah behoben werden. Dann ist alles gut.
Wenn ich mir die Diskussion so ansehe, hätte ich die Formulierung im Sinne der Zielführung besser weggelassen! Nur …
Der Artikel umfasst 567 Wörter, und zwei kleine Sätze löse hier eine solche Diskussion aus. Finde den Fehler …
Es liegt mir persönlich ferne, jemanden, der seine Brötchen als Admin im Windows-Umfeld verdienen muss als doof, blöd oder was ich darstellen zu wollen. Jeder dieser Personen hat ein Wissen, dass ich nicht erreichen werde (und auch nicht muss). Ergo könnte jeder Admin locker über der Sache stehen …
Zu den zwei Sätzen an sich: Die mussten an dieser Stelle sein, weil …
es andernfalls an der Zeit wäre, den Griffel weg zu legen. Denn …
ich blogge ja nun schon eine Weile und kann auch ganz gut hier im Blog in alte Artikel rein gehen. Seit 2012 begleite ich die (aus meiner Sicht) Exzerpte Redmond, von Windows 8 bis 10. Am Anfang, wenn nur wenige Randbedinungen bekannt waren, kann ich helle Begeisterung in meinen Blog-Beiträgen erkennen. Da war eine Idee, das war eine Hoffnung auf einen großen Wurf … nur kippte bei W8, W8.1 und W10 diese Begeisterung bei mir ziemlich schnell, sobald ich erste Betas (heute Insider Previews) in die Finger bekam.
Wir haben 5 1/2 Jahre Windows 10, es ist erkennbar, dass die Theorien des Microsoft Managements zur Entwicklung nicht so funktionieren, wie gedacht. Es gibt Fehler über Fehler, manche wiederholen sich …
Da ich über ein Jahrzehnt Software-Entwicklung betrieben habe, würde ich ja sagen 'geschenkt'. Wenn ich dann aber aus dieser Ecke höre 'alles great', bei einem genaueren Blick in die Details aber oft nur gequirlten Mist finde, sehr klar erkennen kann, dass das alles in eine Richtung läuft, die niemand guten Gewissens im Businessumfeld einsetzen kann, und ich dann noch lese 'wer nicht begeistert auf Windows 10 hüpft und mit einem modernen Betriebssystem mitgeht, geht mit der Zeit', tja, da löckt ganz einfach der Stachel.
Nix für ungut.
PS: Ich habe ja bei heise einen Artikel zum gleichen Thema veröffentlicht. Da wird alles aus meinem Rohtext rausgefiltert und weichgespült (kann ich mit leben). Das ist dann der Ort, wo man sich beim Lesen nicht ärgern muss …
wobei ich immer noch meine, dass solche Spitzen sportlich gesehen werden könnten.
Letzter Satz: Es gibt einen Blog-Leser, von dessen Wissen ich sehr viel profitiere und auch manchen Artikel deriviert habe. In privaten Twitter-Unterhaltungen kam immer 'ja, die ersten Windows 10-Builds waren Schrott, aber die neuen Build sind ja viel besser' und es folgten Details … Zum Wochenende las ich von dieser Person 'Es macht keinen Spaß mehr, in der IT zu arbeiten …'. Macht mich nachdenklich, spricht aber Bände.
Ich lehne mich an dieser Stelle jetzt zurück und beobachte das soziologische Experiment, was aktuell läuft (eine ganze Generation ITler wird in ein Monopol gezwungen und findet das sogar auch noch gut, verstehe einer die Welt).
Das Monopol Microsoft ist schon gefühlt immer da, seit mindestens 1981 mit der Vorstellung des IBM PCs, im Prinzip schon seit 1976 mit dem Altair 8080 und Micro-Soft Basic, das war ja bis weit in die 80er, nein, der C64 wurde ja sogar bis Anfang der 1990er noch verkauft, schon damals war Micrsoft in den Kinderzimmern Standard. Wir haben uns lange gewehrt, mit Commodore Amiga, Atari ST, Arcorn Archimedes, Sinclair QL, pipapo, ja und manche wehren sich mit Macs und Linux immer noch, aber letztlich macht es die Anwendung, die bestimmt das Betriebssystem. Ich sehe, wie sich manche Kollegen unter Linux abmühen, um das konzernweit genutzte OneNote, Teams und Outlook zu benutzen und kämpfe öfters mit von den Kollegen unter Linux geschriebenen LibreOffice Dokumenten, um die unter Office 365 genauso formatiert zu sehen und zu drucken, wie die Kollegen. Bei denen ist ja alles gut, bis sie ein DOCX von mir öffnen und umformatieren müssen. Es ist wie es ist, und neben dem ganzen Frust, den man auch als Windows Nutzer so erlebt, und der Haue die man dafür von Schlaumeiern aus dem Internet fürs Benutzen des Redmondschen Systems, gibts doch immer wieder Erfolgserlebnisse. "Das haben wir schon immer so gemacht, und bisher ist es gut gegangen." Man sieht da auch ein bischen Galgenhumor und Selbstkritik. Das muss einem kein anderer auf die Brust latzen, das ist letztlich gar blöder als der Fehler an sich.
Und im Prinzip stimmt das mit der hellen Begeisterung noch, Win 10 ist im großen und ganzen toll, auch ältere Windows Versionen, sogar 7, haben Macken – die neuliche NTFS-Sache wird für Benutzer ohne ESU, und vielleicht auch für Nutzer mit ESU, sicher nicht mehr gefixt. Ich würde Win 7 nicht wieder haben wollen, 10 ist in vielem Besser, auch wenn man manchmal, ach, lassen wir das… . Und wie zu anderen Artikeln schon öfters geschrieben, es wurde über das Neue schon immer gejammert, egal ob Dampflokomotiven durch Diesel- oder E-Loks abgelöst wurden, oder ob die Leute vom MS-DOS basierten Windows 98 auf 2000 oder XP wechseln mussten. Dabei war Windows mal Klickbunti für unfähige Mausschubser, command.com aber das Ultima und Pferdekutschen waren besser als Züge.
Im großen und Ganzen funktioniert Windows 10, und wenn man Fehlerreports in die richtigen Kanäle reinkippt, werden sie auch beachtet. Twittern ist da nicht unbedingt der richtige Weg, es sei denn, man hofft, bekanntere Medien grefen das Monate später auf, und letztlich kippt die Presseabetilung in Redmond das in die Entwicklungsabteilung rein. Ich habe schon ein paar Bugreports in den dafür vorgesehenen Feedback-Hub reingekippt, hat zwar bis zum Fix auch Wochen/Monate gedauert, aber z.B. inzwischen wurde z.B. mein TVKarten-Dienst-BSOD zum zweiten Mal gefixt, erst unter 2004, jetzt wieder unter 20H2.
Und ja, IT macht heute vielfach keinen Spaß, aber das war früher auch nicht besser, wer erinnert sich noch an mit ISA-Karten vollgestopfte PCs und den unermüdlichen Kampf mit IRQ, DMA und io-Adressen? Oder Speicher-Probleme uter DOS, bis endlich alle Treiber ins UMB geladen waren und man 639 kb unten rum frei hat, und dann meckert irgend ein Programm, was man mit so viel freien Speicher starten will, dass es den Prozessor unbedingt selbst in den erweiterten 386 Modus umschalten muss, statt dass das (Q)EMM386 schon vorher erledigt hat. Bis das endlich mal lief, dann war man der Held. Den ganzen Mist muss man sich heutzutage aber nicht noch durch Polemik versauern lassen. Da drüber zu stehen, ist oft nicht leicht.
Mit dem Mist müssen wir leben, und sehen wie wir die schlimmsten Klippen umschiffen und Ritzen abdichten können. Da hilft einem auch so ein Blog wie dieser hier dabei, wenn er das sachlich tut. Aber vom einem Misthaufen (Windows) zum anderen Misthaufen (Linux) zu springen, oder vom aktuellen Misthaufen zum Vorgängermisthaufen zurückspringen, bringt auch nix, da hat man wieder andere Probleme (siehe z.B. oben die Kollegen). Man will dann aber auch nicht lesen, dass das alles Mist ist, denn sonst ist einem der Tag versaut, im Odenwald und im Taunus liegt noch Schnee, man könnte statt dem ganzen Mist doch im Schnee wandern gehen, oh wie wunderschön! Aber das wärs dann mit dem Brötchenverdienst gewesen.
Schade, dass wenn man so einen direkten Draht nach Redmond hat(te), dass man sich den durch Polemik absichtlich kaputt macht.
"1ST1 sagt:
19. Januar 2021 um 10:09"
/signed und zwar mit jedem geschriebenen Wort und ich will noch mal sagen, das ich der Q(EMM)-König war ^^
Bei den ganzen Fehlern über die man täglich so ließt kann man ja echt froh sein das man länger als 20 Minuten am Stück ohne Abstürze arbeiten kann :) Meine Workstation läuft teils mehrere Monate am Stück durch und dabei zocke ich sogar noch auf der Kiste.
Mit dem Bug könnte man aber bestimmt Spaß haben. Dem Kollegen mal eine Mail im HTML Format schicken und im Quelltext den Pfad als Ort für ein bild angeben. Bei aktivierter Vorschau, ja soll man nicht juckt aber keinen, führt das dann vielleicht auch direkt zum Crash :)
Auf einem Server selber sollte sowas weniger kritisch sein. Wer auf dem Server ein Browser öffnet gehört meiner Meinung nach eh erschossen und was man da ausführt sollte man vielleicht auch nochmal vorher ansehen. Ich habe aber auch schon "Admins" den Internet Explorer auf einem Hyper-V Clusternode öffnen sehen. Für mich gehört auf einen Server nur das absolut nötigste für den täglichen Betrieb.
Ein Terminalserver ist auch ein Server und da ist es absolut nicht ungewöhnlich einen Browser drauf zu haben.
Von daher sehe ich das ganze schon kritisch.
Wer meint sein Win10 Session abschiessen zu müsssen, der soll das machen.
Wer aber einen Terminalserver crasht zieht gleichzeitig unzählige andere aktive Logins auf diesen Server mit in den Crash.
Oh Dreck, an den hatte ich gar nicht gedacht, sowas braucht man aktuell ja auch eher nicht ;)
Wenn ich solche Fehler-auslösende Pfade direkt nach dem Login direkt aufrufen würde, würde ich nicht mal 1/10 der genannten 20 Minuten Laufzeit hinbekommen. Doch wer tut sowas absichtlich? Schon einen Commodore 64 konnte man mit einfachen Befehlen zum Absturz bringen, aber trotzdem laufen die Dinger heute noch in der Classic-Computing Szene. Ein DOS-Rechner hindert einen auch nicht, einen "format c:" einzugeben. Von daher herrscht überhaupt kein Grund zu einer Massenpanik. Es ist jetzt mal doof, aber der dafür fällige Patch wird kommen, und dann ist es erstmal wieder gut, bis zur nächsten Entdeckung.
Viel interessanter wäre eigentluch mal eine genaue Beschreibung des Zwecks dieser komischen Pfade, vielleicht sind die ja auch irgendwie nützlich, wenn man sie richtig benutzt? Dass es die gibt, und da irgendwas passiert, kann ka doch kein Zufall sein.
> Ein DOS-Rechner hindert einen auch nicht, einen „format c:" einzugeben.
Ach herrje, da wird doch noch mehrfach nachgefragt, also wenn schon dann:
format c: /q /u /autotest
War im BNC-Bus-Netzwerk des "Computerlabors" am Gymnasium immer der Hit in Tüten. Pluspunkte wer es über den sehr schlecht gesicherten Novellserver an alle Clients verteilen konnte, was keine Schwierigkeit darstellt, da das Administratorpasswort aus 3 Kleinbuchstaben bestand, die als Hersteller-Modell-Bezeichnung auf dem Gehäuse standen, ach ja die 90er :c)
/q ist Quick, also ohne Daten wirklich zu löschen. Also alles wieder herstellbar. /u verhindert nur, zu prüfen wie die Disk vorher formatiert war und bei Platten eher sinnlos, sondern nur bei Disketten wo man statt 9 auch mal nur 8 oder gar 10 Sektoren pro Spur formatieren konnte. Und selbst heute, trotz wiederholtem Nachfragen, willst du Macros aktivieren, willst du das wirklich runterladen, willst du wirklich dem Word-DOC per UAC Adminrechte geben, tippe mal das Passwort zum ZIP ein um das so durch den Antivirus durchgeschleuste Schadprogramm zu entpacken werden die Schadprogramme aus dem Mailanhang immer noch installiert. Da fällt mir immer der Spruch vom ollen Einstein und der Größe des Universums ein.
>"Schon einen Commodore 64 konnte man mit einfachen Befehlen zum Absturz bringen, "
Was offenbar auch für W10 gilt…30 Jahre später….
Beim C64 war es kein Problem mit einem Poke z.B. den Programcode oder register zu ändern. Und wenn ein Programmierer nicht den Wert von "Malloc" überprüft hat(naja …), hat er halt lustig seine Daten in der Interrupvector-Table des Systems abgelegt. Das hat u.U. sogar eine zeitlang funktioniert…
Ebend deshalb haben alle modernen Betriebsysteme "Speicher Schutz" mechanismen.
Und verbieten i.d.R. den Zugriff ins RAM bei 0.
Hier aber versucht comdrv.sys Daten von 0 zu lesen.
Das darf nicht passieren. Da ist der Code nicht sauber programmiert und enthält möglicherweise weitere Fehler.
Unter Windows 10 Pro 2004 bekommt man diesen Absturz auch durch Eingabe des Pfades im Windows-Explorer hin.
Dabei muss Chrome nicht installiert sein.
Im Firefox muss ich nicht mal die Adresse per Enter in der Adresszeile bestätigen, um den BSOD auszulösen :-O
Könnte mit den Optimierungen der Browser zusammen hängen, wo Sachen vorab von der Rendering-Engine geladen werden, um bei einem Ausführungsbefehl schneller liefern zu können. Browser lesen und bearbeiten ja auch auch die von Stefan Kanthak auf seiner Seite in Data-Elemente eingebettete Meta-Tags mit dem Eicar-Virus, obwohl eigentlich erst dann die Notwendigkeit bestände, wenn im HTML-Code auch Gebrauch von diesen Inhalten gemacht wird. Ist der Grund, warum beim Besuch der Kanthak-Seiten der Defender sofort anschlägt und etwas in Quarantäne schiebt – sozusagen der 'Elch-Test' von Stefan, und alle Browser kippen zuverlässig um ;-).
Ich hätte das eicar pattern gerne genutzt um festzustellen, ob der Defender (Echtzeit) wirklich aktiviert ist.
Hat nicht funktioniert, da eicar eine 16bit-"com"-Application ist, sowieso nicht mehr unter 64-Bit lauffähig wäre… auch sei das pattern zu oft mißbraucht worden…
Insofern verstehe ich die Aussage nicht.
Kann es sein, das das noch 2019 funktioniert hat, jetzt aber nicht mehr?
Wenn der Echtzeit-Scanner aktiv ist reagiert er ja schon, wenn man böse Pattern in den Speicher lädt, ganz egal welche Applikation man nutzt.
Interessant – gerade die Seite unter 64-Bit-Windows 7 SP1 im 'Ungoogled'-Browser aufgerufen. Die MSE haben sofort den Eicar in Quarantäne geschickt. Bin jetzt zu faul, eine Win 10 Testmaschine zu booten – teste das bei Gelegenheit mal.
Es sei darauf hingewiesen das Windows bei Windows 10 vor "kurzem" massiv am Defender (oder wie das zur Zeit heißt) "geschraubt" hat.
Leider finde ich die Stelle mit dem "Wir ignorieren Eicar jetzt, weil es ja eh kein Virus ist/nicht funktionieren würde" nicht.
Ja, ich kann dieser Logik auch nicht folgen und sehe mich schon einen echten Virus zum testen der Installation einzusetzen :-), Danke MS! Ihr seit die Besten der Besten, Sir!
Ganz dunkel meine ich auch mich an was zu erinnern. Zumindest Microsoft hat aber am 15.1.2021 noch diesen Artikel publiziert, in dem man beschreibt, wie man mit Eicar Ausschlusslisten testen könnte. Aber vielleicht habe ich was falsch verstanden.
Also, ich kann mir nicht vorstellen, dass ein Normaluser mal aus Versehen so einen Pfad eintippt…
Und die bösen Buben bringt man doch durch solche Artikel erst auf dumme Gedanken, oder?
Security by obscurity funktioniert auf Dauer nicht.
Auf den ersten Satz des Kommentars passt schon mein Kommentar weiter oben.
Hab das mal bei heise veröffentlicht: Bug in Windows 10: Pfadangabe kann Bluescreen verursachen.
Zur Info: In den Kommentaren gibt jemand folgenden Befehl in der Eingabeaufforderung an, wo der BSOD auch ausgelöst wird:
Also ich kann das auch einfach ohne copy Befehl in die Kommandozeile hämmern dann macht der 2019er Server den Reboot!
Ich bin heute gescheitert, den obigen Pfad direkt in eine Adresszeile des Explorers oder in die Eingabeauforderung per Copy& Paste zu übernehmen – die Win 10 20H2 wollte keinen BSOD auslösen. Vielleicht habe ich einen Fehler gemacht oder die VM war einfach zu lahm – ist auf jeden Fall interessant, diese Beobachtung.
Man braucht noch nicht mal ein "copy" um die BSOD aus zulösen.
Einfach den Pfad auf die Commando Zeile setzen, return drücken und boom.
Der BSOD entsteht anscheinend durch eine Null-Pointer referenz in dem Treiber comdrv.sys beim umkopieren der Daten in den Userspace,
schon wenn man z.B. versucht die Attriute des bösen Pfades auszulesen. Es scheint da ein "Missverständnis" zugeben, wie lang der Stream sein soll…
condrv!CdpDispatchCleanup+0x1f:
fffff801`950eb23f 488b01 mov rax,qword ptr [rcx] ds:002b:00000000`00000000=????????????????
Siehe auch:
https://docs.microsoft.com/en-us/answers/questions/235907/windows-crash-when-navigate-39globalrootdevicecond.html
C-code:
WCHAR fileName[] = L"\\\\.\\globalroot\\device\\condrv\\kernelconnect";
WIN32_FILE_ATTRIBUTE_DATA data;
GetFileAttributesEx(fileName, GetFileExInfoStandard, &data);
Auf die Schnelle hilft es im Chrome via GPO folgenden Eintrag auf die URLBlockList zu setzten: file://*
Damit parst er die URL nicht weiter und fliegt somit nicht ab. Hilft aber auch nur im Browser…
Ich weis nicht wie es beim Chrome ist aber beim Firefox brauche ich kein File:// vor dem Pfad anhängen für den BSOD. Heißt das würde nicht funktionieren :)
Beim Chrome brauchte ich den Prefix auch nicht.
file://* würde aber den Zugriff auch auf legitim auf der Platte liegende HTML-Dateien sperren, ich könnte mir dann z.B. nicht mehr die HTML-Ausgabe von gpresult oder eine als GTML exportierte GPO ansehen.
Ich konnte den Crash mit Windows Server 2019 (1809 – Januar 2021 Security Update) nachvollziehen. Beide Bugs lassen sich z.B. aus Java heraus triggern (der Korruptionsbug nur mit java.io nicht mit java.nio.Path, aber der BSOD geht mit beiden APIs): https://mail.openjdk.java.net/pipermail/security-dev/2021-January/023984.html
Gruss
Bernd
Wir konnten in unseren Tests die Ausnutzung der Schwachstelle per HTML-Link erfolgreich testen.
Bis auf eine Virenschutzlösung ließen die AV-Installationen die Ausführung und den BSOD zu.
Einzig mit der neuen Acronis Cyber Protect wurde das Ausführen verhindert und somit erfolgreich geschützt, was uns im Vergleich zu z.B. Windows Defender sowie eine aktuelle Avast Cloud Care Lösung positiv überraschte.
Ergänzende Hinweise: Ich habe Jan von der CSG Systemhouse GmbH auf Facebook kontaktiert, und um ergänzende Informationen gebeten. Hier eine Zusammenstellung.
Der BlueScreen (BSOD) konnte mit einer lokal abgelegten HTML-Datei, die einen Link gemäß obigem Bild enthält, provoziert werden. Die gleiche Datei auf einem Webserver abgelegt, löst mit aktuellen Browsern keinen BSOD aus – deckt sich mit Rückmeldungen aus dem heise-Forum.
Dann kam noch die Information: Im aktuellen Mailclient von Microsoft (Outlook), mit aktuellen Browsern bzw. hinter entsprechenden Firewall-Systeme scheint man zumindest vor simplen externen Angriffen geschützt zu sein.
Danke an Jan für die zusätzlichen Tests und die Erlaubnis, die Screenshots hier einzubinden.
"Dagegen gibt es in diesem Kommentar die Aussage, dass der BSOD unter Windows 10 Enterprise LTSC, Version 1809, OS Build 17763.1697 nicht auftrete. "
Die Aussage mag da stehen ist aber so nicht richtig. Der Kollege hat es nur mit File-Explorer, Internet-Explorer probiert. Die scheinen den Pfad abzufangen.
Mit der CMD.exe knallt es auch bei 1809.
Das Problem steckt ja tief in in einem Treiber.
Vielleicht findes Du Zeit das unzuformulieren?
Geht doch eigentlich aus dem Kontext meiner Ergänzung hervor. Ich weise darauf hin, dass es an IE und Explorer liegen dürfte und das man den copy zur Ausnutzung verwenden kann. Hab aber einen Satz nachgetragen.
windows xp und vista nicht betroffen