[English]Zum Patchday am 11. Juli 2023, hat Microsoft ja einen Schwung an Sicherheitsupdates für Windows, Office und weitere Produkte veröffentlicht. Zudem wurde eine Schwachstelle in der HTML-Komponente des IE bekannt, die einen RCE-Angriff auf Office sowie Windows mit Systemübernahme ermöglichen. Dafür gibt es keinen Patch, sondern nur Gegenmaßnahmen zum Schutz. Und manche Leser klagen über Probleme nach dem Update, u.a. weil Kerberos Härtungsmaßnahmen seit Juli 2023 greifen und nicht mehr abschaltbar sind. Hier eine Nachlese zu diesen Fragestellungen.
Anzeige
Ungepatchte HTML RCE-Schwachstelle CVE-2023-36884
Zum 11. Juli 2023 (Patchday) ist eine 0-Day-Schwachstelle (CVE-2023-36884) öffentlich geworden, die eine Remote Code Execution in Microsoft Windows und Office ermöglicht. Die Schwachstelle wurde von Hackern der Gruppe Storm-0978 bereits für Angriffe auf diverse Ziele (z.B. Nato Gipfeltreffen im Juli 2023) ausgenutzt. Aktuell gibt es aber keinen Patch, Microsoft hat lediglich Anleitungen zur Schadensbegrenzung publiziert. Alles, was man wissen sollte, habe ich im Blog-Beitrag Office und Windows HTML RCE-Schwachstelle CVE-2023-36884 erlaubt Systemübernahme zusammen getragen.
Zu patchende Schwachstellen
Die Sicherheitsupdates vom 11. Juli 2023 beseitigen 130 Schwachstellen, fünf sind 0-Days, in Microsoft Produkten. Die Artikel am Beitragsende geben die Updates für Windows und Office an, soweit dieses über Windows Update verteilt werden. Eine Auflistung der Schwachstellen, die geschlossen werden sollten, findet sich im Blog-Beitrag Microsoft Security Update Summary (11. Juli 2023).
Netzwerk als Problemstelle
Mit den Sicherheitsupdates für Windows wird ab dem 11. Juli 2023 die erste Stufe des Enforcement Modus beim Netlogon- und Kerberos-Protokoll aktiviert (siehe November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll). Wenn es also Probleme mit der Kommunikation mit DC gibt, lässt sich die Anpassung an Netlogon und Kerberos mit installiertem Update nicht mehr abschalten. Das ist möglicherweise die Ursache für Warnungen hier in den Blog-Kommentaren, dass es Probleme mit dem Netzwerk gibt.
Connect-Problem mit OpenLDAP-Server als DC
In diesem Kommentar weist ein Nutzer darauf hin, dass es nach Installation von KB5028166 unter Windows 10 22H2 Probleme gebe. Domänenbenutzer können sich nicht mehr direkt und via RDP am Client anmelden (Fehler 0xC000018D): "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Anzeige
Den Client aus der Domäne entfernen und wieder neu hinzufügen funktioniert, aber dann taucht der Fehler wieder auf. Es bleibt aktuell nur die Deinstallation von KB5028166. Problem ist wohl das LDAP-Signing, was aber im aktuellen Fall am OpenLDAP-Server liegt.
Probleme mit SAMBA-Servern
Sofern als Domain Controller ein SAMBA-Server eingesetzt wird, können Windows Clients nach der Update-Installation wohl keine Verbindung mehr aufnehmen. Im Kommentar-Thread hier wird das Thema aufgegriffen:
Seit dem Update haben meine Windows 2022 Server ihre Vertrauensstellung zur Domain verloren (Netlogon Event-ID 3210).
Auch ein "Test-ComputerSecureChannel -Repair" hilft nicht weiter. Eventuell erwähnenswert: AD-DC ist bei uns ein Samba 4.15.13
Es gibt weitere Bestätigungen, dass es mit SAMBA Verbindungsprobleme gibt. Inzwischen gibt es im SAMBA-Projekt diesen Bug-Report zu diesem Problem.
Windows 10 Embedded verliert Netzwerkkonfiguration
In diesem Kommentar berichtet Michael, dass bei mehreren Windows 10 Embedded-Maschinen festgestellt wurde, dass durch das Update die Netzwerkkonfiguration verloren gegangen ist. Vorhandene Netzwerk-Schnittstellen werden scheinbar als neues Gerät erkannt, sodass eventuell statische IP, DNS etc. bei dem Update verloren gehen.
IGEL OS scheitert bei RDP-Zugriff
In diesem Kommentar meldet Hartmut, dass Windows 10 Pro-Clients mit Version 22H2 nach der Installation von KB5028166 Probleme mit RDP machen. Mit installiertem Update "können die IGEL nicht mehr per RDP darauf zugreifen", heißt es. Ich tippe, dass es sich um IGEL OS handelt, ein plattformunabhängiges, Linux- basiertes Endpunkt-Betriebssystem, entwickelt für den einfachen, intelligenten und sicheren Zugriff auf virtuelle Anwendungen, Desktops und Cloud Workspaces. Der Nutzer hat das Problem auch bei administrator.de eingestellt, wo es auf auf GEL-OS V 11 geschoben wird.
WLAN-Adapter-Probleme
Es gibt nur zwei vage Meldungen über Probleme mit WLAN-Adaptern in Verbindung mit den Juli 2023-Updates. Holger meldet hier einen abgelehnten TP-Link Archer T1U WLAN-Adapter, weil der Treiber bemängelt wird. Könnte mit dem Thema aus dem Blog-Beitrag Windows: Weiterhin Malware in Kernel-Treibern ladbar (RedDriver-Angriff) zusammen hängen – auch wenn der Treiber nicht auf der Block-Liste steht. Ähnliches wird hier von tecci für AVM WLAN-Sticks befürchtet.
Installationsfehler bei Updates
Bisher sind die Meldungen zu Installationsfehlern noch begrenzt. Von tecci gibt es diesen Kommentar, dass 5 Maschinen spätestens während des Neustarts Probleme mit dem Update KB5028166 (Windows 10) hatten. In einem Folgekommentar ergänzt tecci, dass die Installation sehr zuverlässig aufgrund veralteter Intel-Treiber fehl schlägt. Sein Ratschlag: Alles per INTEL Treiber- & Support-Assistent auf Vordermann bringen, dann rennt das. Andernfalls STOPP bei 74% und Stillstand beim Herunterfahren während eines Neustarts. Allerdings hat sich später ESET NOD32 AntiVirus als Problembär herausgestellt.
MWC meldet hier aber gravierende Probleme mit Windows Server 2016 / 2019, die die Installation der Updates nach dem Reboot mit dem Fehler 0x800f0922 zurückrollen. Es lassen sich keine Updates mehr installieren.
Update KB5028185: Fehlermeldung 0x800f081f beim Surface
Ergänzung: Blog-Leser Reinhard H. hat mich per Mail auf ein weiteres Problem aufmerksam gemacht. Bei seinem nagelneuen Microsoft Surface Go 3 hat er Installationsprobleme beim kumulativen Update KB5028185 (das Update ist im Blog-Beitrag Patchday: Windows 11/Server 2022-Updates (11. Juli 2023) beschrieben). Der Leser teilte mir folgendes zum Update für Windows 22H2 mit:
KB5028185, Fehlermeldung 0x800f081f
Hallo Günter,
nur kurz ne Info, ich glaube du sammelst sowas.
Jetzt gerade im Juli-Patchday gab es hier (nagelneues Microsoft Surface GO3, Win11 Home mit Defender) diese Probleme.
Troubleshooting, sfc, dism, manuell install und löschen von software distribution half nichts.
Eigentlich sollte doch Microsoft bei seinen eigenen Rechnern besonders sorgfältig sein…..
Die Fehlermeldung des Windows 11 Update-Managers deutet darauf hin, dass wichtige Systemdateien fehlen oder dort fehlerhafte Verweise stehen – der Fehlercode zieht sich seit Jahren durch Windows 10/11. Da die oben erwähnten Methoden mit einer Fehlerbereinigung mittels sfc und dism nicht geholfen haben, gehe ich davon aus, dass es entweder am Update-Paket liegt, oder auf dem neuen Gerät bereits Beschädigungen an den Systemdateien vorliegen.
Sein Post auf deskmodder.de gab den Ratschlag auf ein "Inplace-Upgrade" durch Installation von Windows 11 aus dem laufenden Windows heraus. Aber auch nach diesem Schritt gab es Probleme mit der Update-Installation. Da der Benutzer schreibt, dass "Windows 11 sich erhole" und langsam Updates installiere, gehe ich davon aus, dass Microsoft den Fehler bemerkt und das Update-Paket repariert hat.
Inzwischen gibt es weitere Fundstellen im Internet (z.B. Windows Central, oder hier, sowie im Microsoft Techcommunity) wo dieser Installationsfehler 0x800f081f bei Windows 11 22H2 für das Update KB5028185 beschrieben wird.
Anwendungsprobleme nach Update-Installation
Es gibt einige Meldung zu isolierten Problemen mit Software, die nach der Installation der Windows-Updates streikt. Hier die betreffenden Leser-Hinweise – die aber mit EDR/Virenschutzlösungen von PaloAlto Cortex zusammen hängen.
Chromium-Browser streiken in VDIs
Christoph meldet sich in diesem Kommentar und berichtet, dass sich nach Installation des Update KB5028171 auf Windows Server 2022 in VDIs (virtuelle Desktop Umgebungen, basierend auf Windows Server 2022 21H2) keine Chromium basierten Browser (Chrome, Edge) mehr öffnen lassen. Es erscheint lediglich kurz ein weißes Fenster und schließt sich kurz darauf wieder. Problem sei der GPU-Support der besagten Browser. Ein Deaktivieren des GPU-Supports über Registry oder Startparameter bringt keine Änderung. Einzige Lösung aktuell ist die Deinstallation des Updates. Der Bug ist von weiteren Lesern bestätigt, wobei dort der Hinweis kam, dass der Cortex XDR Virenwächter die Ursache ist. Die Deaktivierung behebt das Problem des nicht mehr startenden Browsers (nicht das erste Mal, dass es diesen Effekt gibt).
WMI abfragen in PRTG liefert Fehler
Nach der Installation der Juli Updates KB5028171 und KB5028943 lassen sich die Windows Server 2022-Installationen laut diesem Kommentar von Bjoern nicht mehr per WMI abfragen. PRTG meldet z.B. den Fehler 8080005: Server execution failed. Es ist aber ein isoliertes Problem für Umgebungen, wo Palo Alto Cortex EDR läuft. Deaktivieren/deinstallieren von Cortex oder Deinstallation des Updates KB5028171 beheben das Problem.
Mausstottern in Windows 11 gefixt
Wenn ich den Artikel von neowin.net richtig interpretiere, wurde ein Problem in Windows 11 behoben, das zu einer stotternden Reaktion auf Mausbewegungen führte.
Outlook-Exchange-Probleme: Start im ECM
Ergänzung: Im Juni 2023 hatte ich den Beitrag Outlook-Exchange-Probleme: Startet nur noch im Exchange Cache Modus (ECM) im Blog veröffentlicht, der den Effekt aufgrifft, dass Outlook-Clients nur noch im Cache Modus (ECM) betrieben werden können. Dennis hat sich am 12. Juli 2023 in einer privaten Facebook-Nachricht gemeldet und schrieb, dass er beinem Kunden mit drei Terminalservern "seit neuestem" wieder den obigen Fehler habe.
Ähnliche Artikel:
Microsoft Security Update Summary (11. Juli 2023)
Patchday: Windows 10-Updates (11. Juli 2023)
Patchday: Windows 11/Server 2022-Updates (11. Juli 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (11. Juli 2023)
Microsoft Office Updates (11. Juli 2023)
Office und Windows HTML RCE-Schwachstelle CVE-2023-36884 erlaubt Systemübernahme
Windows: Weiterhin Malware in Kernel-Treibern ladbar (RedDriver-Angriff)
China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Anzeige
Das ist ja ein heisses Konstrukt:
„ Seit dem Update haben meine Windows 2022 Server ihre Vertrauensstellung zur Domain verloren (Netlogon Event-ID 3210).
Auch ein "Test-ComputerSecureChannel -Repair" hilft nicht weiter. Eventuell erwähnenswert: AD-DC ist bei uns ein Samba 4.15.13"
Windows Server 2022 an Samba AD?
Samba fährt doch heute noch im AD den Max Forest Server 2008 R2.
Die Samba Entwicklung hier schein mir seit Jahren kräftig auf der Stelle zu treten. Alleine schon die derzeit fehlenden Möglichkeiten das Samba das sysvol selbst repliziert oder die richtigen Rechte des AD auf das Share legt wären durchaus sinnvoll (Explorer Absturz, Eigenschaften, Sicherheit). Auch ein modernes SWAT wäre nett.
AD gehört auf einen Windows Server und sonst nirgends wenn ich eine Windows Landschaft habe, dann kann man das auch richtig nutzen. Der Samba kann als zusätzlicher Fileserver dienen und fertig.
Der Forest Level ist kein Problem.
Auch Server 2008 R2 mit ESU im 4. Jahr hat die Updates noch bekommen und unterstützt den Enforcement Modus bei Netlogon und Kerberos.
Auch LDAP-Signing kann der problemlos.
Ansonsten stimme ich zu:
In einer Windows Domäne sollte das AD auf einem Windows Server liegen.
Sonst holt man sich nur unnötig Probleme ins Haus.
Und was Netlogon und Kerberos angeht:
Mit dem November-Update gabs 6 neue Fehlernummern (4 für Netlogon, 2 für Kerberos) im Ereignisprotokoll, aber natürlich nur bei Windows DCs.
Da konnte man schon vorher sehen, ob es Probleme geben wird.
Dann musste man aktiv werden.
Gibts die 6 neuen Fehler im Ereignisprotokoll nicht, so kann man direkt den Enforcement Modus scharf schalten. Das habe ich schon im Frühjahr getan, da die Ereignisprotokolle bzgl. der neuen Fehlernummern leer blieben.
Bisher gibt es deswegen absolut gar keine Probleme im Netzwerk.
Liegt das AD nicht auf einem Windows Server, sieht man von den Fehlern natürlich nichts, da andere Systeme das wohl nicht protokollieren.
Ein Windows Server Standard der als DC normal völlig ausreichend ist, naja gut, man sollte besser mindestens 2 Stück davon haben, kostet um die 1350 Euro Lizenz. Wenn man jetzt Arbeitszeit, Personalkosten, usw. rechnet, die es braucht um einen OpenLDAP/SAMBA als alternativen DC aufzusetzen, das ganze zu warten und pflegen, wie jetzt Fehlersuche bei Updates usw. Ob sich das rechnet? Ob man damit den gleichen Funktionsumfang und Komfort wie mit einem Windows DC erreicht? Es bleibt auf jeden Fall Gefrickel.
Hast du mal auf die schnelle die 6 neuen Fehlernummern für mich? Ich find den Artikel nicht mehr. Danke!
Eine AD Umgebung haben aber SAMBA AD-DC nutzen macht wirklich keinen Sinn. Ob das dann auch sicherer wäre steht in den Sternen. In diesem Fall "KISS" anwenden – also Standards.
Also M$-Standards… ;-)
Aber ja, M$ hat nichts falsch gemacht-alles ok. Es liegt tatsächlich am Samba-Core.
Problem nur, diese betreffende Stelle ist von M$ wohl leider nicht gut dokumentiert gewesen-so die Aussagen vom Samba-Team. Also ich würde sagen: M$=50% – Samba-Core: 50% ;-)
https://bugzilla.samba.org/show_bug.cgi?id=15418
Das ist eine dumme Ausrede. Microsoft arbeitet an Samba nämlich mit. LDAP-Signing ist dokumentiert, Samba kann das auch schon, nur wird es von Samba bisher nur in bestimmten Fällen benutzt, und das auch nur optional. Es ist auch schon gut 1 Jahr bekannt, dass LDAP-Signing unter Windows kommen wird, seit Anfang dieses Jahres kann man es optional auch schon erzwingen. War genug Zeit für die Samba-Entwickler, um das vorzubereiten und zu testen.
Standards *gröhl*
Die "Igel" sind Thin-Clients, die mit einem Linux laufen, und auf denen ein veralter RDP-Client genutzt wird. Auch hier vermutlich LDAP-Signing als Problemursache. Die bei uns verwendeten Dell und HP Thinclients haben damit kein Problem.
Danke für den Bugzilla-Link.
Mal ein paar Auszüge:
Michael Saxl 2023-07-12 18:23:41 UTC
"Hope Microsoft takes back this update asap since it will take at least a half year until a fix for this will be downstream"
Michael Saxl 2023-07-13 11:41:59 UTC
"I suspect that it is samba failing to send the response (with the NT_STATUS_INVALID_LEVEL)"
Michael Saxl 2023-07-13 14:37:18 UTC
"Love when things turn out easier than expected. This looks like a change that will not take ages to develop and backport"
Zeigt schön den Erkenntnisprozeß bei den Samba-Entwicklern.
Für Debian kamen heute (Samstag) geänderte SMB-Libs. Mal sehen wann SuSE und RedHat nachziehen.
Ich habe einen Server wo folgender Fehler auftritt:
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 generated an exception
danach reboot, das ganze in Bootloop!
ein anmelden am Server ist weder mit lokalen Admin noch mit Domain Usern möglich, sobald man auf login klickt sprint der Cursor wieder auf den usernamen…
ich glaube fast es ist das selbe Problem wie beim Patchday im April 2023:
https://www.borncity.com/blog/2023/04/14/microsoft-april-2023-patchday-nachlese/
in den kommentaren hatten einige User das Problem… wenn man nach dem Fehler mit den Authentication Package googelt findet man überhaupt nur die kommentare auf Borncity? finde ich auch komisch, spinne ich?
Ich habe ebenfalls LAPS im Einsatz, noch mit alten legacy Client und Policys, am Server waren 2 Lokale User aktiv.. einen davon habe ich nun deaktiviert und auch LAPS Passwort change erzwungen, das hat er sogar zw. so einem Bootloop geschafft.. danach trozdem wieder bootloopund kein login.. im abgesicherten Modus kann ich mich mit dem neu erzeugten LAPS kennwort anmelden, das hat also geklappt…
ich versuche nun das letzte kumulative Update zu deinstallieren…
komisch ist, das Update ist eigtl. seit 12.7. (automatisch mit reboot) installiert, der fehler wurde wohl aber heute getriggert wo ich mich zum ersten mal (per RDP) am Server angemeldet habe…
deinstallation aus abgesicherten Modus -> reboot (in normal) mode , Update(de-)installation wird fortgsetzt wo die Prozente hochzählen und während dessen wieder reboot/bootloop …
wunderbar…
Das Update KB5028937 "July 11, 2023-KB5028937 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 22H2" wird hier nur für Windows 10 Rechner per WSUS angeboten, wenn das Juni "CU for .NET" nicht installiert wurde.
Das normale Juli CU wird anstandslos ausgeliefert.
Hat noch jemand dieses Phänomen?
Auch bei mir wurde auf zwei PCs mit Windows 10 Version 22H2
im Juli kein KB5028937 .NET Framework …
mittels Windows Update installiert.
Im Juni 2023 hingegen schon.
Es gibt Kommentare bei deskmodder.de die
auf vereinzelte Probleme hinweisen.
Ich habe hier ein Notebook mit Windows 10. Nach Installation von KB5028937 und KB5027937 und anschließenden Neustart kommt BSOD und dann stürzt es mehrfach ab und repariert solange rum bis es beide wieder losgeworden ist.
Ich habe aktuell auch schon Probleme mit Minolta-Kopierern gesehen. Bei denen geht das Scan-to-Share gegen einen Windows-2022-Server nicht mehr. Weder ein lokaler Windows-2022-Server-Benutzer noch eine AD-Nutzer – zugegeben aus dem Samba-DC – kann das Share vom Kopierer aus einbinden. Habe das Update da wieder zurückrollen müssen.
Man kann sich sicher leicht vorstellen, wie schnell die Hardwarehersteller da nachziehen werden, um ihre Samba-Libs in der Firmware auszutauschen :-(
Ist da eventuell auch schon jemand drüber gestolpert?
Ich tippe da darauf, dass SMBv1 mit dem Update deaktiviert wurde.
Das war nie drauf. So alt ist der Kopierer dann doch nicht :-) Nach der Deinstallation des Updates geht ja alles wieder. Aber so soll es ja nicht bleiben auf Dauer.
Evrl. wurde durch das Update SMB Signing scharf geschaltet und der Kopierer kann das nicht.
Das SMB Signing kann man aber afaik abschalten.
Also ich hab noch ein Problem mit dem aktuellen Office 365 Updates in Outlook gefunden: wenn ich einen Link mit dem Laufwerksbuchstaben (statt dem ganzen Sharenamen) einfüge und versende dann kann man diesen Link nicht mehr öffnen! Habs bei einem ohne aktuelles Update getestet, da hat es noch funktioniert, danach den Client aktualisiert (Build 16.0.16529.20164), danach hat es nicht mehr funktioniert. Ist zumindest bei Netzwerkshares so, bei Link auf lokales Laufwerk geht es.
es kann sein, dass KB5028937 den context menu => sent to => mail recipient bei mir zerstört hat. auf rechnern, die thunderbird und windows mail und kalender haben, kommt nur diese fehlermeldung https://user-images.githubusercontent.com/11273667/255332935-2dfee5e1-5e96-4343-a2f1-70271ba19a34.png oder es passiert garnichts. auf rechnern, die neben diversen mail-programmen auch ms outlook installiert haben, da wird das dokument NUR an outlook weitergeleitet. und das obwohl outlook NIE nie ein standard-mail-programm war.
will garnicht wissen, was passiert, wenn man outlook löscht. ich hatte schon bei der selektierten installation auf anderen rechnern mit word, powerpoint, excel genug zu tun
https://pastebin.com/zpjJeYsH
Nur, weil mich die recht flinke Reaktion gefreut hat: Mit [GB: dem Update] haben wir alle Authentifizierungsprobleme (auch Ulis copy2folder hatten wir hier) recht schnell wieder ablegen können. Was ich allerdings nicht verstehe – warum Synology den Patch (26.07.2023 immer noch) nicht offiziell verteilt.
Warum ist eigentlich der Link zum synology-Beitrag verschwunden? https://community.synology.com/enu/forum/1/post/161649
edit: wahrscheinlich, weil ich ihn in spitze Klammern gesetzt hatte.
spitze Klammern werden alt Tags interpretiert und gefiltert