[English]Noch ein Nachtrag zum Patchday (13. Juni 2023), bei dem Microsoft auch eine Sicherheitslücke im Windows-Kernel adressiert hat. Über die Schwachstelle CVE-2023-32019 können Informationen abgegriffen werden. Redmond hat zwar Updates für die betroffenen Windows-Systeme veröffentlicht. Um die Schwachstelle abzudichten, müssen Administratoren aber einen Registrierungseintrag aktiv unter Windows setzen.
Die Schwachstelle CVE-2023-32019
Die Schwachstelle CVE-2023-32019 wurde Microsoft von Mateusz Jurczyk vom Google Project Zero gemeldet und betrifft den Windows-Kernel. Ein Angreifer könnte diese Schwachstelle ausnutzen, um von einem privilegierten Prozess, der auf dem Server läuft, den Heap-Speicher auszulesen. Der Angreifer benötigt dazu keine Admin- oder andere erhöhte Rechte, muss aber authentifiziert sein.
Für die erfolgreiche Ausnutzung dieser Sicherheitsanfälligkeit muss ein Angreifer den Angriff aber mit einem anderen privilegierten Prozess koordinieren, der von einem anderen Benutzer im System ausgeführt wird. Daher stuft Microsoft die Sicherheitslücke zwar als “important” ein, sieht aber die praktische Ausnutzbarkeit als gering an.
Registrierungseingriff erforderlich
Microsoft hat zum 13. Juni 2023 diese Schwachstelle in den für die diversen Windows-Versionen ausgerollten Updates adressiert, wie man auf der Microsoft-Seite zur Schwachstelle CVE-2023-32019 sehen kann. In den Support-Beiträgen zu diesen Updates findet sich folgender Hinweis:
Dieses Update behebt ein Problem, das den Windows-Kernel betrifft. Dieses Problem bezieht sich auf CVE-2023-32019. Weitere Informationen finden Sie unter KB5028407.
Im betreffenden Support-Artikel KB5028407 (englisch hier) findet sich dann der Hinweis, dass der Patch wirkungslos ist, weil dieser Fix standardmäßig deaktiviert sei. Der betreffende Text lautet:
Um die Sicherheitsanfälligkeit im Zusammenhang mit CVE-2023-32019 zu beheben, installieren Sie das Windows-Update vom Juni 2023 oder ein späteres Windows-Update. Standardmäßig ist die Behebung dieses Sicherheitsrisikos deaktiviert. Um die Korrektur zu aktivieren, müssen Sie einen Registrierungsschlüsselwert basierend auf Ihrem Windows-Betriebssystem festlegen.
Microsoft gibt dann im betreffenden Support-Artikel an, dass ein Betriebssystem-spezifischer 32-Bit-DWORD-Name mit dem Wert 1 unterschiedlichen Registrierungsschlüssel zu setzen ist, um den Fix zu aktivieren. Für die nachfolgenden Windows-Versionen gilt der Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrideswobei nachfolgende 32-Bit-DWORD-Werte gefordert werden:
- Windows Server 2022: DWORD-Wert 4137142924 = 1
- Windows 11 22H2: DWORD-Wert 4237806220 = 1
- Windows 11 21H2: DWORD-Wert 4204251788 = 1
- Windows 10 20H2 – 22H2: DWORD-Wert 4103588492 = 1
Bei Windows 10 Version 1607 (gilt meiner Meinung nach, auch für Server 2016) und Windows 10 Version 1809 (gilt meiner Meinung nach, auch für Server 2019) ist im folgenden Registrierungsschlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Managerder 32-Bit-DWROD-Wert LazyRetryOnCommitFailure = 0 zu setzen, um den Fix zu aktivieren. Warum Microsoft Windows Server 2016 und 2019 (sind laut CVE-Artikel betroffen) nicht erwähnt und warum der Fix nicht bei der Update-Installation über den Registrierungseintrag aktiviert wird, bleibt an Hand des KB-Artikels aber im Dunkeln.
Ähnliche Artikel:
Microsoft Security Update Summary (13. Juni 2023)
Patchday: Windows 10-Updates (13. Juni 2023)
Patchday: Windows 11/Server 2022-Updates (13. Juni 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (13. Juni 2023)
Microsoft Office Updates (6. Juni 2023)
Microsoft Office Updates (13. Juni 2023)
Exchange Server Sicherheitsupdates (13. Juni 2023)
wird nach setzen des Eintrags ein Reboot benötigt?
Immer dieses händische Nachgefrickel.
Der verantworliche Mensch gehört gefeuert!
Wenn ein Patch zusätzlich das Setzen eines Registryschlüssels erfordert, dann hat das automatisch bei der Patchinstallation zu erfolgen und nicht nachträglich durch den Anwender.
Zudem muß der Registryeintrag zwischen allen Betriebssystemversionen und allen Builds identisch sein.
Was bei diesem Durcheinander passieren kann:
Wenn man jetzt z.B. Windows 11 21H2 hat und den Registryschlüssel setzt und evtl. in 1/2 Jahr auf 22H2 updatet, wird die Sicherheitslücke wieder aufgerissen, da 22H2 einen anderen Registryschlüssel erfordert als 21H2.
Wer denkt denn da noch daran, das er mal einen Registryschlüssel setzen musste?
Microsoft: Setzen: 6
Das automatische Einschalten des Patches kommt später. Der Patch wird wahrscheinlich wieder in Wellen ausgeliefert und MS beobachtet, ob es da Probleme gibt. Kernel-Änderungen sind nicht Ohne und mit Printnightmare hat MS hoffentlich gelernt, dass man gravierende Änderungen nicht auf einen Schlag macht. Mit den Regkeys kannst du nun selbst steuern, ob du den Patch schon vor deiner Welle aktivieren willst.
Ich kann mich übrigens auch noch an diverse Linux-Updates erinnern, wo man danach noch händisch in den Init-Scripten rumfrickeln musste, damit es so läuft, wie man das will. Ist noch garnicht so lange her.
Was für ein unsägliches Gefrickel …
Aber 1ST1 hat wieder einmal nichts anderes zu tun, als seinen unsäglichen Whataboutism auszuleben.
@Günther Born: ich würde mich freuen, wenn Sie das Forum wieder stärker moderieren würden. Warum wird so ein Kommentar freigegeben? Reicht doch, wenn Heise etc ihre Foren den Trollen überlässt :(
Fakten und Erfahrungen in Foren sind viel wert. Meinungen sind ok (sofern höflich vorgetragen). Aber nichts beizutragen und dabei noch andere anzugreifen, das ergibt für mich kein Sinn.
Herzlichen Dank, vor allem für die vielen guten Artikel täglich.
Du befindest Dich hier nicht in einem Forum, sondern in einem Blog. Wenn Dir die Kommentare nicht passen, lies sie nicht.
@Joachim
Im Gegensatz zu einem Forum wird ein BLOG (zumeist) von nur einer Person geleitet und diese Person bestimmt auch dann (alleine) in wie weit sie reguliert! G.B. macht das schon richtig, er löscht auch wirklich schon hin und wieder mal etwas (bei meinen Kommentaren auch schon passiert). Bitte nicht allzu persönlich nehmen und ansonsten gilt nach wie vor: „Don’t feed the trolls!“ oder auch „Trolle bitte nicht füttern!“ Einfach nicht darauf reagieren, dann erledigt sich das (zumeist) von selbst…
@Joachim: was soll der wiederholt völlig unpassende und unnötige Verweis des Users auf Linux denn bitte hier, auf den ich mich bezog?
Welcher qualitiativ hochwertige Fakt ist das? Oder ist es doch bloß Whataboutism, um das Thema mal wieder ein wenig kleinzureden („andere sind ja genauso schlimm“)?
Kann ich verstehen – werde ich aber nicht leisten können. Erstens stehe ich immer vor der Frage „was lösche ich“? Bisher sorge ich nur dafür, dass SPAM (automatisiert) und absolute Trollerei aus den Kommentaren rausgehalten wird. Ich möchte halt auch Gedanken in Kommentaren zulassen, die vielleicht nicht auf meiner Linie liegen. Wenn Moderationsteams von Facebook & Co. überfordert sind, wie soll ich als Einzelblogger das stemmen?
Und es gibt noch einen Grund, warum ich das nicht leisten kann: Meine Zeit ist mir schlicht zu schade, jeden Kommentar auf die Goldwaage zu legen und zu entscheiden „ist das hilfreich“ – es gibt Tage, das kommen > 100 Kommentare. Ich versuche noch eine Weile etwas Zeit in Blog-Beiträge zu stecken – werde mich aber mehr darauf fokussieren, mein Dasein als Ruheständler zu fristen (bin das seit 1. März 2023, ist aber mein erster Ruhestand und ich übe noch – bisher konnte ich mir Loriot’s Papa Ante Portas noch verkneifen und bin – dank des Blogs – noch nicht im Supermarkt mit „mein Name ist Born, ich kaufe künftig hier ein und richte mal schnell eure IT“ aufgeschlagen).
Gut erklärt. Der Registry Eintrag wird bei einem der nächsten Updates automatisch gesetzt, ist aber für „Early Adopters“ bereits jetzt verfügbar. Das kann ich nach meiner Recherche auch so bestätigen.
Damit ist eigentlich alles darüber gesagt. Emotionen und persönliche Angriffe auf andere „Whataboutism“ hier im Forum machen es nur schwerer für alle, die mit diesen System arbeiten (müssen), und schnell Infos finden wollen.
Bei einem fähigen Hersteller muss ich gar nicht erst bei irgendwelchen Drittquellen nach Infos suchen über das, was da so verbrochen wird, weil mir die Informationen mitgeliefert werden. Freiwillig.
Ich wüsste im übrigen auch nicht, warum die Kommentare es schwerer machen sollten, Günters in der Regel detaillierte und gut lesbare Artikel zu finden.
Ist dies tatsächlich so oder eine Vermutung? Ich frage danach, weil ich bisher nichts außer Spekulationen darüber gefunden habe. Early muss nicht sein, wenn dabei das Risiko besteht, dass die Geräte danach möglicherweise Probleme bekommen.
Wenn MS diesen Patch in Wellen aktiviert, werden sie schon ihre Gründe dafür haben und ich bin ehr dafür, diese Aktivierung dann auch abwarten zu wollen. Wenn diese aber tatsächlich nicht stattfindet und dafür eine GPO herhalten muss, erledige ich dies und verteile in Wellen…
„Ich kann mich übrigens auch noch an diverse Linux-Updates erinnern“
Echt? Da wüsste ich gern mehr drüber. Vor allem, welche Distribution(en) das wohl so gehandhabt haben sollen.
Derzeit rätselt jeder darüber, welche Seiteneffekte die Aktivierung per Reg-Key hat und warum MS nicht den Arsch in der Hose hat, den Patch (jetzt) zu aktivieren (was geht kaputt). Bleepingcomputer hat den „konkretesten“ Hinweis, den ich bislang gefunden habe:
„While Microsoft didn’t provide additional details on why this fix is turned off by default, a spokesperson told BleepingComputer that „the update should be enabled by default in a future release.“
Also abwarten?!
https://www.bleepingcomputer.com/news/security/microsoft-windows-kernel-cve-2023-32019-fix-is-disabled-by-default/
Ja, wer sich nicht an die Registry traut, sollte einfach abwarten. Wer ein höheres Schutzniveau umsetzen möchte, kann jetzt schon tätig werden. Ist besser wie bei Printnightmare, wo MS und viele Anwender fett auf die Schnauze gefallen sind.
…besser ALS…
nicht …besser wie…
Das ist doch der gleiche Käse wie beim AD Ende 2021 KB5008380—Authentication updates (CVE-2021-42287)
oder 2020 beim LDAP Signing and Channel Binding https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a oder bei den letzten Exchange Patches…
Bei MS ist vieles MANUELL nach den Updates von Nöten (zumindest bisher im Server-Bereich)…
mMn nicht ganz der gleiche Käse, denn bei deinem Beispiel gibt/hab es einen Fahrplan anhand dessen man sich entscheiden konnte. ob man manuell eingreift oder abwartet.
Diesen Fahrplan gibt es hier (CVE-2023-32019) nicht, noch nicht oder ich habe ihn nicht gefunden.
Wir werden definitiv abwarten bis nähere Infos veröffentlicht werden und mehr Erfahrungen vorliegen bevor wir die Registry Keys setzen.
Merkwürdig….
Habe die Registrierungsänderung gerade wieder gelöscht und nochmal neugestartet und jetzt funktioniert es wieder.
Jedes mal wenn ich einen Browser schließe bereinige ich kurz mein System CCleaner portable + Bitdefender Ein-Klick-Optimierung.
Drei versteckten Einträge in C:Benutzer/***/AppData/Local/Microsoft/Windows/WebCache ließen sich nicht mehr löschen bzw. bereinigen.
Während der Opera Browser geöffnet ist finden sich dort übrigens gerade sieben Einträge, die sich auch nach der Browsersitzung wieder via Bitdefender Ein-Klick-Optimierung löschen ließen.
Ich warte dann doch nochmal auf das nächste Update ;-)
—Grüße—
Bist du beim Geheimdienst oder in der Matrix? ;)
Das Thema Webcache (C:Benutzer/***/AppData/Local/Microsoft/Windows/WebCache) hat aber einen anderen Hintergrund.
Es hat sich schon jemand die Mühe gemacht das mit Filter für eine GPO zusammenzupacken: https://pastebin.com/gh1N7KPG
Hier gefunden: https://www.reddit.com/r/sysadmin/comments/148geic/patch_tuesday_megathread_20230613/
Dann fangen wir mal vorsichtig an zu testen!
bis jetzt keine Fehler
Nun, die Einträge für die älteren Windows 10 Versionen (LazyRetryOnCommitFailure=0) legen nahe, dass es sich um ein Feature handelt das mal eingeführt und generell scharf geschaltet wurde, man aber per GPO abschalten konnte. Später wollte man das verhindern und man hat das Feature mit einer ID verschleiert welche zudem mit jeder Version/Build ändert damit man es nicht mehr generell deaktivieren kann nur weil man die ID mal gelesen hat. (Würde mich mal interessieren was es da sonst noch so gibt…)
Klingt für mich nach einem Performance-Schalter wo man nun festgestellt hat, dass er ein Sicherheitsproblem darstellt. Wie so oft =)
Neu von MS eingefügt:
„WICHTIG Die in diesem Artikel beschriebene Lösung führt einen potenziellen Breaking Change ein. Daher veröffentlichen wir die Standardmäßig deaktivierte Änderung mit der Option, sie zu aktivieren. In einer zukünftigen Version wird diese Auflösung standardmäßig aktiviert. Es wird empfohlen, diese Auflösung in Ihrer Umgebung zu überprüfen. Sobald sie überprüft wurde, aktivieren Sie die Auflösung so bald wie möglich.“
> KB5028407: Verwalten der Sicherheitsanfälligkeit im Zusammenhang mit CVE-2023-32019
Mann oh mann oh mann…. Microsoft at its best…
Ist doch lustig formuliert, oder? Deren Translator kann dies eigentlich viel besser. Wer weiß schon, wer dies verfasst hat…und in welcher Sprache.. :-)
Es ist, wie ich vermutet habe, der eigentliche Patch ist noch nicht reif für eine breite Verteilung, und es ist wohl ein tiefgreifender Eingriff in den Windows-Kernel.
https://www.golem.de/news/windows-microsoft-verschweigt-details-zu-zerstoererischem-patch-2306-175103.html
„Zerstörerisch“ finde ich aber jetzt etwas reißerisch formuliert, die Formulierung würde (inzwischen leider) besser zu diesen Blog passen.