[English]Am 13. August 2024 (zweiter Dienstag im Monat, Patchday bei Microsoft) wurden verschiedene kumulative Updates für die unterstützten Windows 10 Builds (von der RTM-Version bis zur aktuellen Version) sowie für die Windows Server-Pendants freigegeben. Hier einige Details zu den jeweiligen Sicherheitsupdates für Windows 10 und die Server Pendants.
Anzeige
Eine Liste der Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen. Seit März 2021 integriert Microsoft die Servicing Stack Updates (SSUs) für neuere Windows 10 Builds in das kumulative Update.
Updates für Windows 10 Version 21H1-22H2
Für die oben Windows 10 Versionen Windows 10 Enterprise LTSC 2021, Windows 10 IoT Enterprise LTSC 2021 und Windows 10 Version 22H2 stellt Microsoft nur ein Update-Paket, welches nachfolgend genannt wird, bereit.
Update KB5041580 für Windows 10 Version 21H1 – 22H2
Das kumulative Update KB5041580 hebt die OS-Build bei allen Windows 10-Varianten auf 1904x.4780. Das Update enthält nur Sicherheitsfixes, aber keine neuen Betriebssystemfunktionen. Für das kumulative Update wird das Bitlocker-Problem adressiert (siehe Windows 10/11 Updates (z.B. KB5040442) triggern Bitlocker-Abfragen (Juli 2024)). Hier die Fixes:
- [BitLocker (known issue)] A BitLocker recovery screen shows when you start up your device. This occurs after you install the July 9, 2024, update. This issue is more likely to occur if device encryption is on. Go to Settings > Privacy & Security > Device encryption. To unlock your drive, Windows might ask you to enter the recovery key from your Microsoft account.
- [Lock screen] This update addresses CVE-2024-38143. Because of this, the "Use my windows user account" check box is not available on the lock screen to connect to Wi-Fi.
- [NetJoinLegacyAccountReuse] This update removes this registry key. For more information refer to KB5020276—Netjoin: Domain join hardening changes.
- [Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.
Microsoft weist auch darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Beachtet die im Support-Beitrag beschriebene Hinweise zur Installation und zu bekannten Problemen.
Updates für Windows 10/Server 2019
Für Windows 10 Enterprise 2019 LTSC und Windows Server 2019 stehen folgendes Updates zur Verfügung.
Anzeige
Update KB5041578 für Windows 10 Enterprise 2019 LTSC /Windows Server 2019
Das kumulative Update KB5041578 (wird unter Windows 10 v1809 einsortiert, bezieht sich aber auf die 2019er-Versionen und) und beinhaltet Qualitätsverbesserungen aber keine neuen Betriebssystemfunktionen. Dieses Update steht nur für Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC (die restlichen Varianten sind am 11. Mai 2021 aus der Versorgung mit Sicherheitsupdates herausgefallen) sowie Windows Server 2019 bereit. Microsoft führt eine Reihe an Korrekturen auf.
- [Protected Process Light (PPL) protections] You can bypass them.
- [Windows Kernel Vulnerable Driver Blocklist file (DriverSiPolicy.p7b)] This update adds to the list of drivers that are at risk for Bring Your Own Vulnerable Driver (BYOVD) attacks.
- [BitLocker (known issue)] A BitLocker recovery screen shows when you start up your device. This occurs after you install the July 9, 2024, update. This issue is more likely to occur if device encryption is on. Go to Settings > Privacy & Security > Device encryption. To unlock your drive, Windows might ask you to enter the recovery key from your Microsoft account.
- [Lock screen] This update addresses CVE-2024-38143. Because of this, the "Use my windows user account" check box is not available on the lock screen to connect to Wi-Fi.
- [NetJoinLegacyAccountReuse] This update removes this registry key. For more information refer to KB5020276—Netjoin: Domain join hardening changes.
- [Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.
- [Domain Name System (DNS)] This update hardens DNS server security to address CVE-2024-37968. If the configurations of your domains are not up to date, you might get the SERVFAIL error or time out.
- [Line Printer Daemon (LPD) protocol] Using this deprecated protocol to print might not work as you expect or fail. This issue occurs after you install the July 9, 2024, and later updates.
- Note When it is no longer available, clients, like UNIX, that use it will not connect to a server to print. UNIX clients should use the Internet Printing Protocol (IPP). Windows clients can connect to shared UNIX printers using the Windows Standard Port Monitor.
Das Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft hat zudem das Service Stack Update (SSU) aktualisiert. Beachtet die im Support-Beitrag beschriebene Installationsreihenfolge, ggf. die Hinweise zu weiteren Anforderungen und eventuell vorhandener Probleme.
Ergänzung: Einige Nutzer haben nach der Update-Installation erhebliche Performance-Probleme. Ich habe das Problem samt einer möglichen Lösung im Beitrag Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578 aufgegriffen.
Updates für Windows 10 Version 1507 bis 1607
Für Windows 10 RTM bis Version 1607 stehen Updates für die Enterprise LTSC-Versionen zur Verfügung. Diese Updates werden automatisch von Windows Update heruntergeladen und installiert, stehen aber im Microsoft Update Catalog als Download zur Verfügung (nach der KB-Nummer suchen lassen). Vor der manuellen Installation muss das aktuellste Servicing Stack Update (SSU) installiert werden. Details sind im jeweiligen KB-Artikel zu finden.
- Windows 10 Version 1607: Update KB5041773 steht nur noch für Enterprise LTSC sowie Windows Server 2016 bereit. Das Update adressiert Sicherheitsprobleme.
- Windows 10 Version 1507: Update KB504178 steht für die RTM-Version (LTSC) bereit. Das Update fixt Schwachstellen sowie ggf. Bugs.
Für die restlichen Windows 10 Versionen gab es kein Update, da diese Versionen aus dem Support gefallen ist. Details zu obigen Updates sind im Zweifelsfall den jeweiligen Microsoft KB-Artikeln zu entnehmen.
Ähnliche Artikel:
Office Updates vom 6. August 2024
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (13. August 2024)
Patchday: Windows 11/Server 2022-Updates (13. August 2024)
Windows Server 2012 / R2 und Windows 7 (13. August 2024)
Microsoft Office Updates (13. August 2024)
Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578
Windows August 2024-Update legt Linux-Boot lahm
Anzeige
Hallo,
hat schon jemand Probleme mit den Updates?
Vielleicht einfach warten – wenn jemand Probleme hat, wird er hier schon einschlagen …
Schöner Anblick… ängstliche Windows Admins, die vorsichtig fragend um sich herum schauen und Ihre Nachbarn fragen, na willst Du der erste sein mit BSODs oder was immer auch quer schlagen wird?
Da haben'se alle schon alles mögliche virtualisiert und könnten wunderbar eine isolierte AD-Testumgebung als doppelt digitalen Zwilling fahren und machen es trotzdem nicht?
Danke, Charaktere wie Deiner würzen den Kommentarbereich und machen ihn unterhaltsam.
Sein Blog ist erst spitze! CSV-Dateien bearbeitet man am besten mit Texteditorien unter Linux und natürlich ersetzt man Exchange on-prem mit "Debian als Mailserver" :)
Als Browser ist selbst Firefox zu böse, da muss man dann schon "Badwolf" selbst kompilieren, denn Binaries sind auch böse, wie sonst soll man surfen?
Die besten Tipps für den alltäglichen Alltag in Firmen also, wie man sieht :)
https://blog.jakobs.systems/
Und wie lange ist eine "isolierte AD-Testumgebung" ein "digitaler Zwilling"? Einen Tag.
Klar, testen muss man, machen wir auch. Aber es gibt keine "digitalen Zwillinge", wenn eine AD-Umgebung isoliert ist. Viel zu viele Änderungen in der Produktion in wenigen Tagen. Und wer arbeitet dann mit den Testservern mehrere Tage, bis man den ersten Fehler bemerkt? Niemand.
Es ist maximal eine Momentaufnahme, die vielleicht vor BSOD (wann hatten wir den letzten?) hilft, aber niemals vor Fehlern, die erst durch intensive Nutzung sichtbar werden. Eine Test-AD Umgebung ist wichtig für Scripting und Automatisierung, um mit ähnlichen OU-Strukturen, User/Computerobjekten usw. arbeiten zu können. Für Update-Tests fast völlig nutzlos und dafür viel zu viel Aufwand. Und auch nicht gerade billig, wenn man dann Exchange, SQL usw. alle doppelt lizenzieren darf.
Aber gut, dass wir das Thema "Wie man Updates NICHT testet" wieder mal hatten :)
Ein sinnvoller Test ist: zuerst Test-VMs, mit denen man für ein paar Stunden nach dem Update mit einem echten User arbeitet, dann eine kleine Gruppe Clients und Server in der Produktion, die nach dem Update wie gewohnt genutzt werden. Dann sieht man rasch, ob es Probleme gibt. Aber was weiß ich schon, mache den Job ja erst >30 Jahre :)
Ich würde mir ja schon wünschen, wenn es ein Tool gäbe, was alle User, Gruppen und GPOs im Produktiv-AD exportieren uns in so einen "digitalen Zwilling" importieren könnte, letzteres vielleicht im Abstand von x Wochen zum zugehörigen Export, um bisher nicht entdeckte "Unregelmäßigkeiten" der letzten Wochen nicht auch gleich in der AD-Kopie hat. Dann würde das "Ersatz-AD" im Fall eines Falles tatsächlich was bringen, so spart man ja nur maximal ne Stunde bis der erste neue DC für den Neuanfang nach einem "Totalausfall" läuft.
Gibts sowas?
Ja sowas scheint es zu geben. Schau mal hier:
https://www.youtube.com/watch?v=076xVgPDAMM
Ja sowas scheint es zu geben. Fred Weinman hat ein umfangreiches Tool in powershell geschrieben namens
Active Directory Management Framework
Es ist zwar ursprünglich wegen anderer Aufgaben entwickelt worden, sollte aber funktionieren. Ich selbst hatte leider noch keine Zeit es in meiner Testumgebung einzuführen.
Schau mal hier:
https://www.youtube.com/watch?v=076xVgPDAMM
Genauso machen wir das auch. Tomas Jakobs hat vermutlich zu viel Zeit und sehr viele Kollegen, die nichts Anderes tun ;). Diese Vorgehensweise ist ein Overkill und deckt dennoch nicht alles ab, da virtualisiert (Treiberstandard). Das könnte ein Denkfehler sein, wenn dann die Updates auf eine physische Hardware kommen.
Das Problem ist nicht die Testumgebung. Die ist seit gestern 22:00 durchgepatcht.
Das Problem sind die Bugs, die Microsoft gerne einbaut. Ein plötzlich auf Englisch erscheinendes Kontextmenü erschlage ich damit nicht.
Ein alle Jubeljahre vorhandenes Bitlocker-Recovery auch nicht
Deswegen der interessierte Blick hierher.
Server-/Desktoplandschaft mit allen hier eingesetzten Tools wird natürlich automatisiert getestet.
Der Thread läuft eindeutig in eine Richtung, die Mitlesern nichts bringt, wenn sie sich über Patchday-Probleme informieren wollen. Ich lösche jetzt alle Folgekommentare, da alles auf gegenseitiges Bashing hinausläuft – muss nicht sein.
Glückwunsch zum unqualifiziertesten Kommentar des Tages.
Sag bescheid, wenn du in die Realität zurückgekommen bist.
Aus vielerlei Gründen ist deine Aussage totaler Humbug – aber das übersteigt deine Qualifikation offensichtlich, sonst würdest du nicht so einen Kommentar schreiben.
Oder du möchtest nur extra witzig sein – das funktioniert aber anders.
Windows 10 22H2 64 bit – war dieses Mal sauber durch gelaufen, vielleicht nur Glück gehabt? Aber es darf ja auch mal was klappen …
Wir haben zwei Clients die nicht mehr über DNS-Name (IM VPN) auf den Fileserver zugreifen können sondern nur noch über IP-Adresse. Sonst hat sich in unserer Umgebung nichts verändert. Wir sind gerade noch am testen ob wirklich das Update das Problem ist.
Keine Probleme bei unseren vier Server 2019 (deutsch; einmal mit Exchange 2019; dreimal VM unter Proxmox)
Ich bin gerade in das Problem gelaufen, dass nach dem Update auf Server 2029, RDP nur noch schwarzes Bild zeigt.
Nach ca. 1 stunde dann mal ein Bild, aber alles extrem träge und keine Interaktion möglich.
Bild ist nun wieder schwarz.
Kann noch nicht mal den task manager öffnen.
Hake nur via rdp Zugriff.
Jemand eine Idee?
Grüße, Hary
Meine DCs wollen alle beim Booten einen Bitlocker Key, dabei habe ich sie doch gar nicht verschlüsselt!?!?
(/fakenews)
Was soll der Kommentar und das (/fakenews)? So langsam habe ich die Faxen dicke und überlege, den Blog einzustellen, da ich offenbar nur noch IT-Kindergarten unter der Leserschaft habe (siehe auch meinen obigen Kommentar). Ich fasse es einfach nicht.
Das wäre echt schade. Als Administrator für Windows-Systeme ist man für jede Information dankbar. Ich schaue nach dem Patchday als erstes hier herein und dann zu Heise. Und dann immer mal wieder, wenn sich Fragen ergeben bzw. offene Fragen hier auftauchten, die inzwischen beantwortet sein könnten.
Aber verstehen kann ich Ihre Überlegungen.
Möglicherweise sperre ich auch einfach einige Kandidaten.
Bitte mach das. Manche Trolle lernen es nur so. Es wäre sehr schade wenn wegen einiger einzelner geistiger Tieflieger dein Blog eingestellt wird.
Wir hier wissen deinen Blog sehr zu schätzen.
Viele schätzen das Blog hier sehr, ein Sperren einzelner Trolle wäre wirklich sehr hilfreich für alle, die einfach arbeiten wollen/müssen. Danke :)
Falls das technisch einfach möglich ist: weiter posten lassen, aber diese Postings niemanden anzeigen außer dem Troll. Dann macht er sich keinen neuen Account, sondern es wird ihm nur langweilig, weil die Provokation ins Leere geht.
Dem kann ich mich nur abschließen. Bin auch gerade am evaluieren, ob es Probleme mit den Updates gibt. Auf Grund der hohen Anzahl an 0-days ist ja zeitnahes Patchen angesagt.
Bitte denk bei allem, was Du tust zuerst an Deine Gesundheit!
Ich schätze dieses Blog sehr, aber ein permanent hoher Blutdruck wegen diesem Kindergarten (ich rätsle noch, ob Vorschulkinder oder eher die "kleine" Gruppe) mit allen möglichen Folgeerscheinungen ist keinesfalls gut.
Ich habe es bisher nicht thematisiert, aber vielleicht als Warnung:
Vor mehr als 10 Jahren gab es schon mal einen sehr ähnlichen Blog, welches sich vorwiegend mit Windows und seinen Updates beschäftigte – ebenfalls von einem Einzelnen mit sehr hohem Engagement betrieben (patch-info.de).
Der Betreiber Ottmar Freudenberger griff teilweise zu sehr rabiaten Mitteln (u.a. wurde mal der gesamte T-Online IP-Bereich gesperrt, so daß man nur auf Umwegen lesen konnte), hat aber diese Problematik auch nie in den Griff bekommen.
Sein letzter Post "Mich trifft der Schlag" über seinen Schlaganfall mit kompletter halbseitiger Lähmung ist noch im Web-Archiv abrufbar (23.03.2013) – danach kam nichts mehr, so daß ich das schlimmste befürchte. Wissen tue ich es nicht (auch nicht ob er diesen Post noch selbst verfassen konnte), aber BITTE versuche für Dich einen Ausweg zu finden bevor es zu spät ist.
Ich hätte kein Problem, dass man sich nur per Firmen-Email registrieren kann.
Damit sperrt man 99% der Trolle aus, und das 1% kann man durch Sperren der Firmendomain in den Griff bekommen.
Der Echtname kommt für mich nicht in Frage, da man sonst durch Datamining schnell Social Engineering betreiben könnte.
Tschuldigung, ich halt meinen Rand.
Ich hatte heute das gleiche Problem mit Win 11 clients. Bei mir selbst hat es über 30 Minuten gedauert nach dem Reboot. Dabei stand der "Fortschritt" ca. 20 Minuten bei 96% fest.
Bei einem Mitarbeiter ist es gescheitert ohne erkennbaren Grund. Er musste geschlagene 45 Minuten warten, eh das automatische Zurückrollen ansprang.
Scheint wieder eins "dieser" Updates zu sein. Oh man.
Danke für den Kommentar und deinen Folgekommentar. Nachdem ich von Lesern auch per Mail kontaktiert wurde, habe ich das Thema samt Workaround mal separat aufgegriffen. Der Artikel ist am Beitragsende und im Text zum Update verlinkt.
schön das man mit dem update oder warum auch immer plötzlich dev home auf windows 10 22h2 installiert bekommt.
Windows 10: bei VMs (KVM) und auf Laptops (Testgruppe) bisher keine Probleme.
Da ich seit Neustem mein privates System mit VeraCrypt (W10 2021 IoT LTSC) verschlüsselt habe, kann ich voller Glück verkünden, dass die Microsoft Updates ohne Probleme durchgelaufen sind 😎
Ist ja auch kein Bitlocker…
(/realnews)
Mit Bitlocker genauso problemlos.
Die Updates hängen heute bei 2 PCs. Es bewegt sich nichts. Download je was es ist unverändert bei 10%, 4%, 1% oder Null.
In der Nacht hat er bei meinem alten Notebook das gemacht. DerNeustart heute morgen dauerte dann 2,5 Stunden.
Hat Jemand auch das Problem?
Win11 23/2 und Server 2019 und 2016 keine Probleme bisher.
Ich hatte das gleiche Problem heute auf mindestens zwei Win 11 Clients.
Den einen PC (ein sehr sehr alter Medion) habe ich neu gestartet und siehe an, er hat runtergeladen und beginnt zu installieren. Parallel lädt er jetzt das Sicherheitsupdate für Win10 runter.
Mein Arbeits-PC (kann ich erst in ca 10Min starten). Mal sehen was dann passiert.
Ein Schlusskommentar zu meinen Problem:
ich habe für mein Arbeits-PC insgesamt mehr als 10 Stunden gebraucht (von 7 Uhr bis 17-30Uhr). Damit das Ding nicht hängt, habe ich diesen dann 3x neu gestartet (kein herunterfahren).
Das Problem wird bei jeden Patchday im Monat immer schlimmer.
Moin,
ich habe mir bei den "Hängern" angewöhnt, das "Update-Fenster" zu schließen und dann über "Start – Einstellungen – Update&Sicherheit" den Update-Vorgang neu aufzurufen. War bisher immer erfolgreich.
Zusätzlich, nachdem das Update durchgelaufen ist, über "Systemsteuerung – Verwaltung – Datenträgerbereinigung" starten und zwar mit "Systemdateien bereinigen", dabei alle Auswahlkästchen anhaken und dann die gefundenen Dateien löschen. Kann je nach Update zwischen 500 MB und 5 GB betragen, was da gefunden und gelöscht wird.
VG
Hört sich für mich nach einen Problem mit der eigentlichen Installation an. Schonmal "sfc /scannow" und anschließend noch die vier verschiedenen "dism /Online /Cleanup-Image" drüberlaufen lassen?
Danke, ich werde mich mal dem widmen.
Das optionale Update davor ging ohne Probleme.
Datenträgebereinigung mache ich schon.
Ich mache jetzt gerade Datev mit deren "neuen" SQL-Server etc. Das Ganze dauert seine Zeit, hängt aber nicht mit dem Problem der Dauer bei MS-Sicherheitsupdate zusammen. Das dauert auch leider ca. 4,5 Stunden. Vielleicht bin ich vor 22 Uhr fertig. Ich bin gerade "fast" in der Endphase ((noch 18 Anwendungen, danach kommt Datenanpassung und sog. "ServiceTool"- das kann sich auch sehr sehr (!) ziehen)).
Keinerlei Probleme, Werder 10 noch 11 noch Server 3016 bis 2023. Mal ein Patchday ohne Stress 😀
Diverse Windows Server 2022 & 2019 bisher ohne Probleme, bei Windows 10 & 11 bisher auch keine Auffälligkeiten, auch nicht bei unseren Bitlocker Notebooks.
Jemand schon DCs und/oder Hyper-V Hosts probiert?
Hab nur bei einem unbedeutenden Server 2022 das Update eingespielt und mich gewundert wie schnell das Update durchlief. Probleme konnte ich keine feststellen.
DCs ja, Hyper-V habe ich nicht im Einsatz. Unsere zwei 2019er DCs haben bisher keine Auffälligkeiten, genauso wie die sonstigen 2019 und 2022er Server bis jetzt machen was sie sollen.
Danke! Hyper-V (Server 2022) jetzt selber getestet. Lief ohne Probleme aber mit typischen Doppelneustart. Die restlichen Server folgen in Kürze. Win 10 Clients bisher keine Probleme.
Gruß
2 x Server 2022 DCs und ein paar Server 2016er erfolgreich geupdated. Bisher gibt es keine Probleme.
Gruß
Ja, in einer Test Domain auf DCs installiert, werden die GPP Zielgruppenadressierung teilweise gestört. Gibt es wohl auch schon Reddit Beiträge zu
Beachte meinen Beitrag Windows-August 2024-Updates zerstören GPO-Zielgruppenadressierung wo ich das Ganze herausgezogen habe. Mark Heitbrink hat dort Workarounds gepostet.
Alles bestens hier mit Windows 10 Systemen.
Den Part mit dem LPD Protokoll finde ich besonders im Hinblick auf die Kommunikation seitens MS "amüsant". Kollegen in Portugal hatten im Juli Probleme mit einem SAP-Printserver. Das Juli Update wurde schnell als Ursache ausgemacht. Aber wenig bis keine Info im Netz. Vermutlich weil auch ein seltenes Szenario. Und nun in den August Patch-Notes wird reingeschrieben, dass es seit Juli geplant kaputt ist und nicht gefixt werden wird. :)
Wenn ein Feature als veraltet erklärt wird und dann doch noch 4 Server-Generationen mitgeschleppt wird, hat das doch niemand mehr auf dem Schirm.
Das LPD Print Problem das wohl den meisten SAP nutzenden Unternehmen um die Ohren geflogen ist, ist angeblich mit dem August Patch gefixed worden, der Satz in den Patch notes oben ist einfach nur unglücklich formuliert.
Hier steht es nochmal eindeutig:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019
Danke für den Hinweis/Korrektur. Ich hätte den Kollegen jetzt geschrieben "fangt mal an umzubauen". :D
Wirklich großartig formuliert seitens MS "July 9, 2024, and later updates"…
Also ich habe gestern ca 20 diverse 2019 Server aktualisiert und es lief wie es soll.
Wie ich jetzt sehe, gibt einen sehr guten Grund, das zu tun: CVE-2024-38063
Alternativ kann man als Workaround gegen die Schwachstelle vermutlich* auch den IPv6-Stack abschalten, so wie ich es überall mache, wo es nicht im Spiel ist.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents REG_DWORD 0x000000ff (255)
Weiß jemand, ob alternativ auch das Abhaken des Protokolls an der Netzwerkkarte genügt?
* Im MSRC schreibt MS dazu am 13.08.: "Systems are not affected if IPv6 is disabled on the target machine"
"Weiß jemand, ob alternativ auch das Abhaken des Protokolls an der Netzwerkkarte genügt?"
Das genügt leider nicht, die Dinger funken teils weiter, vor allem Cluster. Vor allem wenn man die Windows-Cluster-Funktionen einsetzt (Hyper-V, MS-SQL, Sharepoint, Fileserver, …) dann sollte man das auch unbedingt nicht tun! Denn die Cluster-Funktionen verwenden IPv6 für die Syncronisation/Heartbeat/… untereinander. Und die versuchen sich auch übers reguläre Netz gegenseitig anzufunken, wenn es über die zusätzlichen Cluster-Netzwerke nicht klappt. Das ist insbesondere eine Herausforderung, wenn man auf solchen Maschinen die Windows-Firewall aktivieren muss. Denn welche Ports usw. benötigt werden, ist nirgends gescheit dokumentiert, und jede Sorte Cluster (Hyper-V, MS-SQL, Sharepoint, Fileserver, …) nutzt andere Ports, ICMP, … – Das ist zum Schreien, denn wenn man was davon "vergisst", funktioniert der Cluster nicht!
Nun, da das Sicherheitsproblem ausgelöst wird durch die fehlerhafte verarbeitung eingehender ipv6 Packete ist das abharken des Protokolls bei den Netzwerkkarten völlig ausreichend, denn dann kannst du dem jeweiligen System ja keine ipv6 Packete mehr schicken über das Netz.
Und entgegen der hinlänglichen "Propaganda" z.b. auf Reddit oder Aussagen von Microsoft in irgendwelchen Artikeln o.ä. haben wir damit noch nie irgendwelche Probleme gehabt, weder auf Windows 10/11 Clients noch auf Windows 2008-2022 Servern jeglicher Art(inkl. Exchange, AD, usw..), somit ist bei uns schon immer und auf allen internen Systemen das ipv6 bei den Netzwerkkarten abgeharkt. (Manche mögen das uncool finden aber wir haben definitiv wichtigere Probleme als uns mit ipv6 und dem dadurch entstehenden Aufwand rumzuärgern… ipv4 inkl. nat wird meine restliche Arbeitszeit von ~30 Jahren wahrscheinlich locker überleben und ich habe noch keinen Anwendungsfall gefunden bei dem ich ipv6 gebraucht hätte…
Hi, ich habe oft an einem "ping localhost" bemerkt, dass ich noch vergessen hatte, diesen Registry Hack anzuwenden.
Das loopback interface hat dann mit IPv6 geantwortet und denke mal, der IPv6-Stack wurde benutzt.
Das passiert meiner Meinung nach auch, wenn man von seinen physischen NICs die Häkchen entfernt hat.
Dieser Angriff könnte so vielleicht noch eine Erhöhung von Privilegien erwirken – ich kann mir vorstellen, dass das Stack-Abschalten also besser wäre.
(Aber OK, das ist jetzt akademisch und für Leute, die ewig nicht patchen könnten und Eskalationsszenarien hätten.)
Moin, das einfach abhaken soll man nicht. Ich würde das hier empfehlen, setzt die Keys aber kannst es per GPO verwalten und auch per eignen WMI Filtern steuern wenn es z.B. nur auf Server 2012 soll (die man natürlich nicht mehr hat)
https://www.gruppenrichtlinien.de/artikel/ipv6-deaktivieren-das-protokoll-nicht-die-bindung
/EDIT die Server/Computer brauchen einen Reboot nachdem sie die GPO gezogen haben. Nach dem Reboot haben sie keine IPv6 Adresse mehr, beim testen vorher/nachher prüfen mit IPCONFIG /ALL
ich finde nirgends info ob der Bug im RD-Gateway (Juli Updates) behoben wurde?
da gab es ja das Problem dass der Dienst alle 15 Min abshcmierte…
Korrigiert mich wenn ich falsch liege, aber das abschmieren des Dienstes passiert doch aufgrund der Nutzung von Remote Procedure Call over HTTP. Gibt hierzu auch einen Workaround unter "Known issues in this update", wenn ich das nicht ganz falsch verstehe.
https://support.microsoft.com/en-us/topic/august-13-2024-kb5041578-os-build-17763-6189-522a6305-63d2-40e3-8084-2ab8f9589bc6
Wird der Port 3388 nicht für die Remotedesktop-Gatewayserverfarm genutzt? Genau das habe ich nämlich im Einsatz und laut der Windows-Firewall wird dieser Port dafür verwendet.
ist er nicht, habe ich gestern getestet und gehofft, dass es gefix ist. Leider nicht, bei mir geht auch der Workarround mit der Windows Firewall dazu nicht
Gestern komplette Testumgebung gepatcht.
4x DC auf Server 2022 Std.
1x 4-Node HyperV S2D-Cluster auf Server 2022 Datacenter
ca. 30 Memberserver auf Server 2016, 2019, 2022
alles problemlos…bisher
Bei mir funktioniert seitdem die GPO Berichterstellung auf Windows Server 2019 nicht mehr sofort.
Der IE blockt wieder "about:security_mmc.exe", aber man kann es nicht mehr zu den vertrauenswürdigen Sites hinzufügen. Da sind sämtliche Felder ausgegraut.
Schließt man die Meldung wieder wird ein dann trotzdem der Bericht angezeigt.
Auf Windows Server 2016 habe ich nicht dieses Phänomen. Beide Server bekommen die gleichen GPO Settings.
Es hat ja auch bis vorm Patch Day normal auf 2019 funktioniert.
Weiß jemand eigentlich was konkret mit "If the configurations of your domains are not up to date, you might get the SERVFAIL error or time out"? Hätte da irgendwie gerne etwas konkretere Infos, welche Konfig die genau meinen.
Bei Reddit haben sich Leute der Sache angenommen und mit MS Kontakt aufgenommen. Aktueller Status: Nicht mal MS weiß, was da gemacht wird. Es gibt lediglich den Hinweis, dass es sich da wohl um öffentlich zugängliche DNS Server handeln soll nicht lokale. Es werden lediglich 0815 best practices genannt:
The guidance does seem to be targeted at DNS services that are public facing, but he was unable to ensure that there would be no impact for on-prem AD environments.
1) DNSSEC: ensure DNSSEC is properly configured and enabled.
2) Zone Transfers: Verify zone transfers are restricted to authorized servers only.
3) Recursive DNS resolver: Ensure your DNS resolver is configured securely to prevent DNS amplification attacks
4) DNS Records: Regularly update and verify your DNS records to ensure they are accurate and secure.
To test whether these changes affect your DNS:
DNSSEC test: Use tools like Verisign DNSSEC Analyzer to check if your domain is compliant with DNSSEC
Zone transfer test: Use tools like Hacker Target to check if your DNS records are vulnerable to zone transfers
DNS Health Check: Use comprehensive DNS health check tools like DNSStuff or Geekflare to identify any potential issues.
Es gibt jetzt mehr Infos von Microsoft.
Sorry, dass ich hier so Textblöcke poste!
DNS administrators should ensure that the IP addresses for Name Server (NS) records (glue records) are valid and active for all parent, child and delegated zones.
Prioritize validation efforts for (1.) external zones, then (2.) parent zones of Active Directory forest root domains. Client queries may fail when an invalid configuration is used after installing protections for CVE-2024-37968 contained in Windows Updates released on or after August 13, 2024
Glue records that are not properly registered on the domain or are out of date, may result in glue validation query failure. This could cause certain customer queries to result in RCODE 2 (Server Failure).
Example of Out-of-Date Glue: http://www.contoso.com NS ns1.foo.com 1.2.3.4 where actual ns1.foo.com is 1.1.1.1 (if customer forgot to update COM server with new IP address but IP 1.2.3.4 is still working fine).
The current pre-emptive action for DNS admins is this: "Verify that all DNS zone delegations are valid prior to installing Windows Updates released on or after August 13, 2024. Specifically, IP addresses in Glue records must reference the valid IP address."
In short, validate IP Addresses for Name Server (NS) records: Ensure that the IP addresses for NS records (also known as glue records) are valid and active for all parent, child, and delegated zones. This is particularly important for external zones and parent zones of Active Directory forest root domains.
Ach super, Danke dir für die Info. Naja warum wundert es mich eigentlich nicht, dass nichtmal MS weiß, was da zutun ist. ;D
So nach meinem ersten Post gestern komme ich nun nicht mehr weiter.
Der Server 2019 läuft nicht mehr korrekt nach Installation der August-Updates.
Hängt noch jemand in dem Problem fest, dass der Server nach dem Update nicht mehr rund läuft?
Teilweise kann die Verbindung via RDP gar nicht aufgebaut werden, häufig nur schwarzer Bildschirm.
Hängt dann oft bei Remotesitzung wird konfiguriert oder gesichert.
Ping durchgehend einwandfrei.
Dann Fenster inaktiv, keine Rückmeldung.
Wenn ich den Taskmanager dann mal geöffnet bekomme, ist die Auslastung nicht mal bei der Hälfte.
Alles extrem langsam. Minuten vergehen bis sich ein Fenster öffnet.
Habe bisher keinen Fix gefunden oder Hinweise auf dieses Phänomen nach dem Update.
Bin kurz davor, das Update wieder runterzuwerfen in der Hoffnung, dass es danach wieder wie zuvor läuft…
Danke für eure Ideen.
Ein Kommentar von Reddit betreffend Performanceproblemen nach dem Update:
Same. Clearing out the contents of C:\Windows\System32\catroot2 seems to fix this issue for us, and clearing it out before patching seems to prevent it from happening at all.
https://www.reddit.com/r/sysadmin/comments/1eqziiy/comment/li844s2/
Ich plane die Nacht noch einen Beitrag. Gerade per Mail was rein bekommen, was sich ähnlich anhört.
Ergänzung: Ich habe das nun in einem separaten Beitrag aufbereitet – siehe Link in obigem Text sowie am Ende des Beitrags.
Hat jemand weitere Informationen zur Situation beim Booten von Linux ISOs?
UEFI shim bootloader:
https://github.com/rhboot/shim/blob/main/SBAT.md
"step in replacing the compromised firmware keys from Microsoft"
https://news.ycombinator.com/item?id=41242943
Ich frage mich ob jetzt nur beim Versuch Secure Boot durchzuführen oder ob allgemein einzelne nicht aktualisierte und auf MS Zertifikatskette basierende Distros nicht mehr booten.
"Windows-Update legt erneut Linuxe lahm"
"Das liegt an veralteten Bootloadern, die nun gesperrt wurden."
www[.]heise[.]de/news/Windows-Update-legt-erneut-Linuxe-lahm-9838170.html
Sowas habe ich heute NACH dem Augustupdate KB5041580 (W10) mit meinem Ventoy USB-Stick (UEFI, Version 1.0.98) festgestellt, der VOR diesem Update n0ch bei eingeschaltetem Secure-Boot funktionierte.
Beim Bootversuch vom USB-Stick kam eine Fehlermeldung, die ich so zum ersten mal sah:
———————–
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
———————–
Die Meldung erschien für gut 5 Sekunden auf schwarzem Hintergrund und dann schaltete sich der Rechner aus.
Nach dem Ausschalten von Secure-Boot ging es dann.
Da hat ihm das Windowsupdate wohl seinen Sicherheitsschlüssel aus dem BIOS weggeputzt, vermute ich.
Hallo zusammen,
also nach dem August Update gibt es noch Probleme mit RDS Lizenzserver, wenn dieser nicht für eine Domäne die Lizenzen ausstellt.
War im Juli schon so, nach Deinstallation des Updates ging es wieder.
Es werden keine neuen Lizenzen verteilt bzw. vorhandene nicht erneuert, es kommt dann immer der nette Spruch, dass kein Lizenzsserver zur Verfügung steht und die Sitzung in 60 Minuten getrennt wird.
Lizenzdiagnose auf den RDS Servern ist immer ok, Verbindung da, ausreichend Lizenzen vorhanden, aber nichts passiert.
Habe jetzt das KB5041578 deinstalliert und alles ist funktional.
Hat das noch jemand? Und hilft vielleicht eine Migration auf Server 2022? Möchte den Server eigentlich nicht so weiter betreiben.
Hallo zusammen
Ich habe gestern abend mehrere Server 2019 und 2022 aktualisiert.
Dabei auch ein RDP Server. Bei dem hatte ich ebenfalls Probleme, nur bei dem.
Es wahr keine Anmeldung mehr per RDP möglich.
Am Client (Win 11) kam nach dem Login der Hinweis, dass die Verbindung nicht aufgebaut werden konnte.
Erst die Deinstallation des Pakets: KB5041578 am RDP Server hat geholfen. Seitdem funktioniert alles wieder.
Du hast meinen am Ende verlinkten Artikel zu KB5041578 und einem möglichen Workaround gelesen?
Mit dem Update wird auch die App " Dev Home (Vorschau) " installiert.
Zu finden als System App und nicht löschbar.
Nach kurzer Suche dann doch einen Weg gefunden, die Bloatware zu deinstallieren.
Geht wie folgt: In der Eingabeaufforderung(Administrator) winget uninstall "dev home (preview)" eingeben und bestätigen.
Update KB5041580 für Windows 10 Version 21H1 – 22H2
Entgegen der Aussage
"[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)]
This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI
(Shim bootloaders) from running.
This SBAT update will not apply to systems that dual-boot Windows and Linux."
wird es auch bei Dual-Boot-Systemen ausgeführt!
Die Meldung danach lautet
"Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriosly wromg: SBAT self-check failed: Security Policy Violation"
Der Rechner schaltet sich aus.
Es hilft nur "SecureBoot" ausschalten.
In unserer Umgebung wird im WSUS kein Statusbericht mehr von den Clients aktualisiert.
Ich vermute das Problem existiert, seit der WSUS-Server (Windows-Server 2019) das KB5041578 installiert hat, da die letzten Statusberichte mit dem Timestamp der Installation des KB5041578 übereinstimmen.
Versuche den Statustbericht direkt am Client forciert auszulösen (usoclient.exe ScanInstallWait) hatten biosher keinen Erfolg
Kurzes Update…
Nachdem ich nun im IIS-Manager den WSUS-Pool manuell angehalten und neu gestartet habe, kommen wieder akutelle Client-Statusberichte im WSUS an.
Ob dieser manuelle Eingriff auch nach dem Reboot des WSUS-Servers notwendig ist, muss ich noch testen.
WSUS-Pool neustarten funktioniert, Danke!