Ich stelle mal zwei Merkwürdigkeiten unter Windows, die mir die letzten Tagen unter die Augen gekommen sind, hier im Blog vor. Microsoft hat den Debugger WinDbg aus der Preview-Phase für den allgemeinen Einsatz freigegeben. Beobachtung ist, dass Benutzer ohne Administratorenberechtigungen WinDbg im Programm-Ordner installieren können. Zudem scheint es, als ob die Berechtigungen für den Ordner system32/de.de unter Windows 11 22H2 von den Berechtigungen für en-us oder andere Sprachen abweichen.
WinDbg-Installation für Standardnutzer
Der Windows-Debugger WinDbg hat die Preview-Phase verlassen und steht allgemein als installierbares MSI-Paket bereit (siehe diesen Microsoft-Beitrag). Mir ist die Tage aber ein Tweet von Sicherheitsforscher Will Dormann unter die Augen gekommen.
Er hat sich den App-Installer angeschaut und festgestellt, dass jeder Nutzer (auch ohne Administrator-Berechtigungen) den Debugger systemweit im Ordner:
C:\Program Files\
installieren kann. Kommt ihm spanisch vor.
Ordnerberechtigungen in Windows 11 22H2
Blog-Leser Martin Feuerstein hat mich vor einigen Tagen mit einer Beobachtung kontaktiert, die ich so bestätigen kann. Windows 11 22H2 wird für deutsche Nutzer mit abweichenden Berechtigungen für den Ordenr system32/de-de ausgeliefert. Martin schrieb mir:
Hallo Günter,
bei den Dateisystemberechtigungen meines neu aufgesetzten Windows 11 22H2 ist mir aufgefallen, dass es in c:\windows\system32\de-de nicht denselben Satz Berechtigungen gibt wie z. B. in c:\windows\system32 oder beispielsweise in c:\windows\system32\en-US oder c:\windows\system32\eu-ES. In einer neu aufgesetzten VM habe ich dasselbe Verhalten beobachtet.
Nachfolgend ist die Berechtigung für den de-DE-Ordner dargestellt.
Für den den en-US-Ordner sieht das Ganze dann so aus:
Diese Abweichung kann ich in einer frisch installierten VM ebenfalls bestätigten. Martin schrieb dazu:
Aufgefallen ist mir das bei der Installation des alten Taschenrechners aus Windows 7 sowie der Windows 7-Spiele – aus dem EXE-Installer von WinAero.com habe ich mir für den eigenen Gebrauch MSI-Installer erstellt, die per Gruppenrichtlinie beim Systemstart installiert werden sollen – nur dass der System-Benutzer keinen Schreibzugriff auf das Verzeichnis de-DE hat. Administratoren nebenbei auch nicht.
Einziger Weg, die Verzeichnisrechte zu übernehmen, ist also im TrustedInstaller-Kontext die Berechtigungen zu ersetzen. Ich habe dazu ExecTI (WinAero) und icacls benutzt, um die Berechtigungen des Verzeichnisses en-US nach de-DE zu klonen.
vielleicht hängt das mit den omimösen virtuellen Verzeichnis Strukturen zusammen mit denen MS versucht auch uralt Programme mit fest einprogrammierten Systempfaden immer noch am laufen zu halten.
Sind nicht wie Apple, die kurzmal das eigene MacOS in due Tonne treten um auf ein BSD Unix umsteigen, weil sie das Speicher Management nicht mehr hinbekommen und dann später kurzmal von Motorola auf Intel Umstiegen…
Unterschiedliche „System32\en-US“ und „System32\de-DE“ Berechtigungen deuten auf unterschiedliche Berechtigungen je nach installierter Landessprache.
Anbei die Berechtigungen einer englischen Installation:
https://i.ibb.co/swxWWnJ/Screen.png
Alle* Sprachordner außer de-DE haben „normale“ Berechtigungen. Nur de-DE als Hauptsprache nicht. Ich hatte unter anderem en-US und eu-ES angeschaut (deswegen auch ein kleiner kleiner Bug mit Zitat/Screenshot ;-)), wo eben erwartete Berechtigungen waren. Und bei dir die gleichen fehlerhaften Berechtigungen mit deiner Install-Sprache – falls das einen Sinn hat, verstehe ich ihn nicht.
PS: Wie schauts bei deinem englischen OS mit den anderen Sprachordnern aus?
Einfach mal lesen was ich geschrieben habe.
Der Screenshot zeigt ein englisches Windows, bei dem „en-US“ Berechtigungen analog der „de-DE“ Berechtigung bei einem deutschen Windows ist. Folglich liegt die Vermutung nahe das die Berechtigung des Verzeichnisses mit der installierten Landesversion zusammen hängt. Was ist daran nicht zu verstehen?!
Wie siehts denn mit den anderen Sprach-Ordnern in deinem englischen OS aus??
Der Sinn, warum der Ordner mit der Haupt-OS-Sprache anders ist, erschließt sich damit immer noch nicht.
Die Andern Ordner, auch de-DE sind auf einem Emglischen Windows analog dem „en-US“ Ordner aus dem Artikel. Daraus scheint für mich zu folgen, das für die „lokale“ Landessprache andere Rechte auf dem Ordner gelten als für andere Landessprachen.
Warum das so ist kann ich auch nicht sagen.
das ist völlig verwirrend Wiel Programme andere Pfade sehen als der Explorer.
Ich könnte mir vorstellen das die bei de-de Ähnlich tricksen mussten.
ModernApps aus dem Store können auch von Usern installiert werden, und laufen dann meines Wissens im Usercontext.
ModernApps laufen meines Wissens in abgeschotteten Sandboxen, für die die erhöhte Sicherheitsberechtigungen aus „> EINSTELLUNGEN > DATENSCHUTZ“ gelten.
Über die klassische Win32-Umgebung hat man mit Userrechten auf die Installationsverzeichnisse keine Zugriffsrechte.
Für mich sieht das also alles recht plausibel aus.
Aber WinDbg ist ein MSI-Paket. Wenn das wirklich so ist, hoffe ich, dass es anderen Personenkreisen nicht gelingt, diesen Trick nachzubauen…
Nein, WindDbg liegt nun als MSIX-Package vor. Hier gelten ganz spezielle Spielregeln mit Packagevolumes, VFS, virtualized registry etc. Details kann man auch unter Understanding how packaged desktop apps run on Windowsnachlesen
„Einziger Weg, die Verzeichnisrechte zu übernehmen, ist also im TrustedInstaller-Kontext die Berechtigungen zu ersetzen. Ich habe dazu ExecTI (WinAero) und icacls benutzt, um die Berechtigungen des Verzeichnisses en-US nach de-DE zu klonen.“
AUTSCH: solche Holzwege beschreiten nur VÖLLIG ahnungslose Tröpfe!
Jeder mit dem Windows-Rechtesystem auch nur MINIMAL vertraute Administrator aktiviert das Privileg „SeRestorePrivilege“ und (über)schreibt dann die ACL.
Siehe https://skanthak.homepage.t-online.de/tidbits.html#process oder https://skanthak.homepage.t-online.de/tidbits.html#twiddler
Es hat doch aber funktioniert?!? Hier gings auch erstmal nur um einen Einzelplatz und Quickfix. Durch den Blog kriegt es vielleicht Aufmerksamkeit in Redmond und es bekommt eine richtige Lösung (auf mich hört dort keiner – auf dich ja auch nicht, wie wir hier schon häufiger erfahren haben ;-)).
Backup-/Restore-Privileg hab ich für ein Projekt per PowerShell auch schon mal genutzt – aber vielleicht ist das ja gar nicht nötig, wenn die Ursache behoben wird.
Wäre vielleicht auch einfacher, die ACL direkt im Image zu beheben, wenn ich schon Win11 ausrollen wollen würde. Mein Laptop ist aber nur der erste Testballon.
Denkst Du denn gar nicht an die Kinder^WNachahmungsübeltäter?!
Es geht NUR um Deinen hier STRUNZDÜMMSTERWEISE und noch dazu als EINZIGEN Holzweg beschriebenen „Fix“ mit Missbrauch ÜBELSTEN überflüssigen Schrotts — oder auf „gut“ Deutsch: „a fool with a tool is still a fool!“
JFTR: zum Kopieren der ACL eines Verzeichnisses könntest Du auch gaaanz einfach ROBOCOPY.exe missbrauchen!
PS: MANCHMAL hören sie in Redmond (nicht nur) auf mich; siehe beispielsweise https://msrc.microsoft.com/blog/2023/04/congratulations-to-the-top-msrc-2023-q1-security-researchers/ bzw. https://msrc.microsoft.com/leaderboard für 2023 Q1
„AbEr DeNk DoCh MaL eInEr An DiE KiNdEr“ :-)
Wie immer rate ich dir, etwas runterzukommen. „Woosah“ sagen und Ohrläppchen reiben.
Ich hab also ein Programm genutzt, um mir Trusted Installer-Rechte zu verschaffen. Und dann ein Microsoft-Programm zur Modifikation von Berechtigungen. Nur das nun 3,5 Skript-Kiddies mehr wissen, wie man sich TI-Rechte verschafft, was sowieso mit 1 Google-Suche im Internet zu finden ist.
Ja, Robocopy wäre vermutlich der elegantere Weg.
Nochmal: total übel(!)flüssiges Zeux wird nur von Lemmingen genutzt, die irgendwelchen Google-Treffern hirnlos hinterherlaufen und den dort gefundenen Mist völlig ahnungslos wiederkäuen.
Also: lass solchen Schrott links liegen, denke kurz nach und nutze die Bordwerkzeuge.
JFTR: das wirrtuelle Benutzerkonto „Trusted Installer“ hat KEINE besonderen Rechte; es hat nur die gleichen Privilegien wie das SYSTEM-Konto.