[English]Zum 8./9. April 2025 hat Microsoft zahlreiche Sicherheitsupdates für die unterstützten Windows-Versionen ausgerollt, die auch die Symlink-Schwachstelle CVE-2025–21204 schließen sollte. Wellen schlug dies durch den auf allen Windows-Systemen per Patch angelegten Ordner Inetpub. Nun wird bekannt, dass durch die Sicherheitsupdates eine neue Schwachstelle aufgerissen wurde. Jeder lokale Nutzer kann die Update-Installation dauerhaft unterbinden.
Anzeige
April 2025-Updates und der Inetpub-Ordner
Zum 8. April 2025 (und für manche Windows-Versionen zum 9. April 2025) wurden die Sicherheitsupdates für Windows veröffentlicht. Diese schließen verschiedene Schwachstellen (siehe auch Microsoft Security Update Summary (8. April 2025)).
Unter anderem wurde die Windows Symlink Schwachstelle CVE-2025–21204 mit einem Fix bedacht. Eine unsachgemäße Linkauflösung vor dem Dateizugriff ("Link Following") im Windows Update Stack ermöglichte es einem autorisierten Angreifer, seine Rechte lokal zu erweitern, heißt es bei Microsoft. Die Schwachstelle ist mit einem CVSS 3.1-Wert von 7.8 als "Important" bewertet worden.
Im Supportbeitrag zur Schwachstelle CVE-2025–21204 heißt es, dass nach Installation des April 2025-Updates unter Windows ein neuer Ordner %systemdrive%\inetpub erstellt werde. Dieser Ordner sollte nicht gelöscht werden, unabhängig davon, ob die Internetinformationsdienste (IIS) auf dem Zielgerät aktiv sind, schrieb Microsoft. Denn dieses Verhalten sei Teil der Änderungen, die den Schutz von Windows erhöhen sollen. Es seiten keine Maßnahmen von IT-Administratoren und Endbenutzern erforderlich, hieß es. Ich hatte im Blog-Beitrag Windows 10/11: April 2025-Updates legen Ordner "inetpub" an über den Sachverhalt berichtet.
Neue Schwachstelle durch Patches aufgerissen
Das Patchen der Symlink Schwachstelle CVE-2025–21204 im April 2025 durch Microsofts Sicherheitsupdates ist aber wohl in die Hose gegangen. Sicherheitsforscher Kevin Beaumont weist in nachfolgendem BlueSky-Post darauf hin, dass Microsofts Fix für eine Symlink-Schwachstelle eine weitere Symlink-Schwachstelle aufreißt.
Anzeige
Durch die neue Schwachstelle können alle Benutzer (auch Nicht-Administratoren) alle zukünftigen Windows-Sicherheitspatches stoppen. Beaumont hat die Details in seinem Beitrag Microsoft's patch for CVE-2025–21204 symlink vulnerability introduces another symlink vulnerability auf DoublePulsar offen gelegt (Martin ist das hier aufgefallen).
Jeder Benutzer (Administrator oder Standard-Nutzer) kann mit dem Befehl mklink in einer Eingabeaufforderung mit dem Befehl:
mklink /j c:\inetpub c:\windows\system32\notepad.exe
einen neuen Symlink (junction point) vom Ordner %systemdrive%\inetpub auf eine andere Ressource anlegen. Beaumont hat das in obigem Screenshot durch einen Symlink auf den Windows Editor Notepad.exe demonstriert.
Ist der Junction Point auf %systemdrive%\inetpub angelegt, lässt sich laut Beaumont das Windows-Update vom April 2025 nicht mehr installieren. Bei der Update-Installation tritt ein Fehler auf und/oder die Installation wird zurückgerollt.
Diese Update-Blockade gilt auch für alle künftigen Updates, sofern Microsoft nicht nachbessert. Beaumont hat Microsoft vor 2 Wochen auf das Problem hingewiesen, bisher aber keine Antwort erhalten.
Ähnliche Artikel:
Microsoft Security Update Summary (8. April 2025)
Patchday: Windows 10/11 Updates (8. April 2025)
Patchday: Windows Server-Updates (8. April 2025)
Patchday: Microsoft Office Updates (8. April 2025)
Windows 10/11: Preview Updates 22. April 2025
Outlook 2016: Kalender-Zugriff nach April 2025-Update KB5002700 gesperrt
Word/Excel 2016: Abstürze nach April 2025 Update KB5002700?
Windows 10/11: April 2025-Updates legen Ordner "inetpub" an
Windows NTLM-Schwachstelle CVE-2025-24054 wird ausgenutzt
Anzeige
ok gerade was getestet unter Windows 11 24h2
auf meiner D Platte einen Ordner TEST erstellt und ebenso eine Datei test.txt jeweils unter \
beim Aufruf von mklink /j D:\TEST D:\test.txt kommt
Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist.
Also kann das beschriebene ja nur funktionieren wenn auf c:\ noch kein inetpub ordner existiert. Ich probiere jetzt aber nicht aus ob ein non Admin diesen löschen kann, wenn er durch den Patch bereits angelegt wurde.
Also Probleme bekommt man nur wenn kein Ordner da ist und jemand Unfug macht.
Wenn der User dort schreiben darf – was leider im Default möglich ist – hat man halt durchaus noch andere/weitere Probleme. Per GPO kriegt man das bspw. so in den Griff: https://www.gruppenrichtlinien.de/artikel/rootsecinf-keine-ordner-auf-c-erstellen
Warum sollte man das verbieten? Das Ding heißt "Personal" Computer und nicht "Admins" Computer. Man kann ein System auch bis zur Unbrauchbarkeit kastrieren. Die User haben dann zu Recht keinerlei Verantwortung für "ihren" Rechner. Und sie werdem massiv in ihrer Produktivität behindert. Eine Lösung, die dem Unternehmen, neben dem vermeintlichen Vorteil der Security, einen gravierenden Nachteil einbringt. Kann man natürlich so und so sehen. Leider gibt es bei vielen Admins nur ihre eigene Sicht der Dinge. Ein immanent unsicheres System wie Windows, kann man nur dadurch absichern, das es nicht mehr benutzt werden kann / wird.
Hier ist es schlicht verboten, Dateien auf dem eigenen Rechner abzulegen.
Dateien sind grundsätzlich auf einem Dateiserver abzulegen.
Einer der Gründe:
Arbeitsplätze werden nicht gesichert, sondern nur die Server.
Legt jemand Dateien auf seinem Rechner ab und z.B. die Festplatte/SSD stirbt, hat er seine dort abgelegten Dateien verloren.
Bei Ablage auf dem Server sind die Dateien dagegen immer im täglichen Backup mit drin.
Deshalb liegt z.B. auch das Homeverzeichnis (Dokumente, Bilder, Videos, etc.) auch auf dem Server und nicht auf dem lokalen Rechner.
Eine Einschränkung in der Produktivität ist nicht feststellbar.
"Eine Einschränkung in der Produktivität ist nicht feststellbar". Eine miserable Produktivität ist feststellbar, besonders wenn das home Verzeichnis irgendwo in der Azure Cloud liegt. Auch gehören sensible Daten grundsätzlich nicht in die Cloud! Tägliches vollautomatisches Backup ist auch von Clients möglich. Dazu braucht es aber eine vernüftige Backup Lösung und keinen Spielkram. Die Änderungen sind meist nicht umfangreich und ein guter Agent erledigt das in Null Komma Nichts. Du hast bestimmt schon versucht 3D Modelle aus der Cloud zu öffnen? Soviel Kaffee (oder Tee bzw. ClubMate) kanst Du gar nicht trinken. Wenn es denn klappt (weil das Modell 136 Komponenten lädt) kannst Du gleich wieder Feierabend machen, denn deine Arbeitszeits ist inzwischen um. Das funktioniert selbst unter NFS nicht optimal und mit CIFS praktisch gar nicht. Ich sagte es bereits: eingeschränkte Sichtweise.
Wo hat er was von Cloud geschrieben? Er sprach von "Fileserver" und das die Homeverzeichnisse auf dem Server liegen und nicht lokal. Das gibt's auch On-Prem, da brauchts keine Cloud für. Clients werden bei uns auch nicht gesichert, wofür auch, falls einer ausfallen sollte habe ich in spätestens 30 Minuten einen neuen da stehen und die Daten sind dank Server trotzdem alle noch da. Und was 3D-Modelle angeht: Bei uns liegen die CAD-Zeichnungen auch auf dem Fileserver (lokal, nicht Cloud) und das braucht zum öffnen nicht länger als wenn sie lokal auf Platte liegen.
> Tägliches vollautomatisches Backup ist auch von Clients möglich. Dazu braucht es aber eine vernüftige Backup Lösung und keinen Spielkram. Die Änderungen sind meist nicht umfangreich und ein guter Agent erledigt das in Null Komma Nichts.
Schon vor 30 Jahren hat man keine Clients mehr gesichert. Sondern alles auf dem File-Server abgelegt. Und diesen gesichert. Den es geht auch um Lizenzkosten. Und diese waren auch damals bei IBM Tivoli Storage zum Beispiel oder HP Data Protector kein Pappenstiel. Und das sind vernünftige Backuplösungen.
> Auch gehören sensible Daten grundsätzlich nicht in die Cloud! Tägliches vollautomatisches Backup ist auch von Clients möglich. Dazu braucht es aber eine vernüftige Backup Lösung und keinen Spielkram.
Clients hat man vor 30 Jahren schon schon nicht mehr gesichert. Sondern die Daten werden auf dem File Server angelegt. Das hat auch mit Lizenzkosten zu tun. Und diese waren bei IBM Tivoli Storage Manager bzw. HP Data Protector kein Pappenstiel.
An welcher Stelle wurde denn – außer in deinem eigenen Kommentar – die (Azure) "Cloud" erwähnt?
Wo habe ich irgendetwas von Cloud geschrieben?
In meiner Firma ist alles On-Prem.
Und fällt ein Client aus, nehme ich einen Rechner aus dem Regal, und in 10 Minuten kann der Benutzer arbeiten.
Und dank Roaming Profile ist auch sein Benutzerprofil nicht verloren, sondern wird auch mitgesichert.
Da muß ich absolut gar nichts einrichten, installieren, konfigurieren.
Ein normaler User hat fernab von seinem Homeverzeichnis oder die für ihn vorgesehene Ablage für Daten nirgendwo Daten abzulegen. Es ist eine unart wenn User dann meinen direkt unter C Ordner anlegen zu müssen, weil sie ihren Mist dann schneller finden. Deswegen auch sehr sinnvoll das gleich im Keim zu ersticken.
Wahrscheinlich ähnlicher Ansatz, aber so habe ich das bei uns umgesetzt:
https://administrator.de/forum/ordner-erstellen-auf-c-unterbinden-1318480641.html
Ein normaler User sollte im Firmenumfeld nicht das Recht haben direkt unter C:\ selber Ordner oder Dateien anzulegen. Hab ich hier bei uns eingeschränkt.
Ob das nun unter C:\ ist oder unter C:\home\ ist egal, wenn dieses Verzeichnis denn da ist. Das Benutzerverzeichnis von Windows ist aber völliger Murks, solange es keinen wirklich für alles funktionierenden symlink auf einen kurzen Pfad gibt. BTW: Poweruser benutzen eher nicht den Explorer um Datein zu öffnen, sondern die shell.
%userprofile%
…und ich blende C komplett aus… (verhindert nicht, dass man trotzdem über rechten Mausklick auf eine Verknüpfung rein kommt). Aber der normale DAU User macht da schonmal weniger Müll.
Auf diese (mit Windows 2000 eingeführte und seit Windows Vista trivial ausnutzbare) Schwachstelle habe ich das MSRC vor 15 (in Worten: FÜNFZEHN) Jahren aufmerksam gemacht (nachdem M$FT sie in der "Siebten Todsünde" NICHT behoben hat) und sie vor einigen Jahren auf meiner Web-Seite "Quirks" offengelegt. Aktuell ist sie unter https://skanthak.hier-im-netz.de/blunder.html#blunder59 sowie https://skanthak.hier-im-netz.de/comspec.html#fault20 zu finden.
Finde nur ich, dass diese "Schwachstelle" einen Nährwert nahe Null hat?
Alles worum es hier geht, ist: wenn das April-Update NOCH NICHT (!) installiert ist, kann ich durch Anlegen der Junction die Installation des Updates verhindern.
Tolle Sache, aber wenn das April-Update tatsächlich noch nicht installiert ist, bin ich auch schon durch CVE-2025–21204 angreifbar, womit ein Angreifer SYSTEM-Rechte erhält. Dass damit ebenfalls die Installation weiterer Updates verhindert werden kann, ist dann noch das kleinste Problem…
Ein normaler Benutzer hat auf das vom April-Update angelegte Verzeichnis C:\inetpub keine Schreibrechte, womit die neue "Schwachstelle" also vom April-Update gleich mit behoben wird.
Dass man das Schreibrecht auf C:\ sowieso entfernen sollte, wurde ja schon erwähnt. Kann ich nur nochmal bekräftigen.
Tja… "High-Performer" vs "Low-Performer". Die performen so high, daß da keine Zeit mehr für Tests ist.
Es ist grundsätzlich eine dumme Idee, überhaupt irgendwelche Daten auf c: abzulegen. Es ist zwar seit Windows XP besser geworden, aber es kann immer noch theoretisch passieren, dass bei einem Systemabsturz das Laufwerk c: beschädigt wird und man zumindestens nicht mehr davon booten kann. Möglicherweise sind dann auch die abgelegten Daten korrupt und können nicht mehr gerettet werden.
Außerdem kann es passieren, dass c: mit den Eigenen Dateien irgendwann mal voll läuft, und dann funktionieren zunächst keine Updates mehr, weil die Dateien nicht mehr abgelegt werden können, und irgendwann funktioniert Windows garnicht mehr, weil es keinen Speicher auslagern kann, keine temporäre Dateien mehr anlegen kann, usw.
Privat gehe ich immer her und reduziere die Partitionsgröße von C: auf 512 GB und lege auf dem freien Platz oder auf einer Extra-Platte/SSD ein Laufwerk D: an. Dann erstelle ich einen Ordner "Daten", und darunter die Ordner "Bilder", "Dokumente", usw., eben all denen die es unter %userprofile% auch gibt, soweit ich sie verwende. Dann öffne ich im Explorer %userprofile%, klicke den Ordner Dokumente mit der rechten Maustaste an, wähle den Tab "Pfad" und wähle dort "Verschieben" und klicke mich nach "d:\daten\dokumente" durch und lege somit fest, dass alle Programme per Standard ihre Daten dort hin speichern. Dann kann all das nicht mehr passieren. Außerdem ist jetzt die Datensicherung ganz einfach, ich brauche nur noch d:\daten per Robocopy abzuziehen und eine Neu-Installation des PC wäre auch machbar, ohne dass ich meine Daten erst retten und dann irgendwie wieder restoren muss.
C: ist für das Betriebssystem und die Anwendungsprogramme und sonst nichts.