Microsoft bevestigt bug na Patch Tuesday waardoor Windows Servers vastlopen

Microsoft bevestigt dat er een bug zit in de Patch Tuesday-update van maart voor Windows Server. Door dat geheugenprobleem herstarten servers onverwacht of lopen ze vast. De bug zit in alle moderne versies van de software. Microsoft zegt aan een oplossing te werken.

Microsoft bevestigt op een ondersteuningspagina dat er problemen zijn ontstaan na de Patch Tuesday-updateronde van maart. In update KB5035857 zit volgens het bedrijf een probleem voor verschillende versies van Windows Server. Het gaat om Windows Server 2012 R2, 2016, 2019 en 2022. Vorige week klaagden meerdere systeembeheerders online al over problemen in het server-OS na installatie van de update.

Nu blijkt dat het inderdaad gaat om een bug die gerelateerd is aan de update. Volgens Microsoft kan het voorkomen dat er een geheugenlek ontstaat in het Local Security Authority Subsystem Service of Lsass van Windows Server als dat op een domaincontroller staat geïnstalleerd. Dat gebeurt als zowel on-prem- als cloudbased domaincontrollers met Active Directory een authenticatieverzoek via Kerberos doen. Door 'een extreem geheugenlek' kan het komen dat Lsass dan crasht. Daardoor start de domaincontroller opnieuw op, zegt Microsoft, al melden veel beheerders ook dat de DC's ook vastlopen.

Microsoft zegt dat het de hoofdoorzaak heeft gevonden, al geeft het bedrijf daar verder weinig details over. "We werken aan een oplossing die in de komende dagen beschikbaar komt", schrijft het bedrijf.

Reacties (68)

[Triblade_8472]

Mocht iemand dit nog lezen, er zijn OOB (out-of-bandwidth) updates uitgebracht.
https://www.bleepingcompu...r-windows-server-crashes/

• Windows Server 2022: KB5037422
• Windows Server 2016: KB5037423
• Windows Server 2012 R2: KB5037426

Download ze hier: https://catalog.update.microsoft.com

[VOosterhof]

Dank voor je bericht! Als ik kudo's kon geven....

[Pietertje]

Wij hebben een tiental Windows 10 machines die door KB503585 een geheugenlek kregen en down gingen. Deze Windows 10 machines draaiden wel een video server applicatie. KB5037423 is hier de fix voor.

[jepe68]

Via een Microsoft nieuwsbrief las ik deze info ook. Als je doorklikt op KB5037426 voor Windows Server 2012r2 en dan download, krijg je de Win8.1 patch die uiteraard geweigerd wordt op een 2012r2 server.

[Triblade_8472]

Zou het kunnen zijn dat je ondertussen al een nieuwe/vervangende patch hebt? Handmatig of via WSUS.

[jepe68]

Zojuist in mijn patchronde opnieuw gecontroleerd:
https://catalog.update.microsoft.com/Search.aspx?q=KB5037426
2 mogelijkheden; een download voor Windows Embedded 8.1 of Windows Server 2012 r2, maar beiden downloaden dezelfde patch voor Windows 8.1

[Triblade_8472]

Nu is Windows 8.1 en server 2012 r2 onder water hetzelfde, dus dat klopt wel. Maar de melding die je eerder kreeg is wel raar.

[jepe68]

Yep.
"The update is not applicable to your computer", she said.
Ik begin bijna aan mezelf te twijfelen, omdat niemand anders hier meldt het probleem te hebben. Of mijn bedrijf is echt een van de laatste der Mohikanen die nog een server op 2012r2 heeft draaien.

Overigens: Het is een Out of Band update. Ik twijfel of ik die dan via WSUS kan aanbieden. Is het proberen waard. Bedankt voor de tip.

[Reactie gewijzigd door jepe68 op 22 juli 2024 14:18]

[Triblade_8472]

Je kan OOB updates importeren in WSUS!
https://techcommunity.mic...-is-changing/ba-p/3882937

Zeker niet de laatste met 2012(R2)!!
Maar mogelijk wél de laatste wat 2012(R2) server betreft de Active Directory erop. Deze patch is dan ook voor Domain Controllers bedoeld.

Nu ik dat schrijf, probeer je de update wel op een 2012R2 DC te installeren?

[jepe68]

>Nu ik dat schrijf, probeer je de update wel op een 2012R2 DC te installeren?
Ja zeker

[Simon Weel]

Het gaat om Windows Server 2012 R2, 2016, 2019 en 2022.

Als ik het artikel van Microsoft bekijk, dan geldt het alleen voor Windows Server 2022. Ook het KB artikel rept alleen over Windows Server 2022.

[DDX]

Als je bij known issues van 2019 server kijkt :

https://learn.microsoft.c...9-and-windows-server-2019

En die linkt weer naar :

https://support.microsoft...c6-43f0-a612-1c15802fed06

Voor 2016 zelfde verhaal :

https://learn.microsoft.c...7-and-windows-server-2016

En 2012R2 is eol

[Simon Weel]

Ah, ok. Beetje onduidelijk allemaal? In het artikel waarnaar wordt gelinkt wordt alleen Windows Server 2022 genoemd. En als je links in de kolom op het pijltje bij Previous Versions klikt, dan worden Server 2016 en 2019 niet genoemd.

[Cergorach]

Uit het bron artikel:
https://learn.microsoft.c...s-server-2022#3271msgdesc

Affected platforms:
Client: None
Server: Windows Server 2022; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2

Echter verwijst KB5035857 specifiek naar Server 2022 voor zover ik kan vinden.

[djack]

Het probleem beperkt zich dus tot domaincontrollers en niet tot alle servers?
Beetje onduidelijk artikel

[Annihlator]

Als de server afhankelijk is van kerberosrequests/auths via of voor AD, zullen ze (neem ik aan) als domino-effect er last van kunnen ondervinden dat de AD vastloopt.
Hierdoor kunnen een aantal van de servers/clients pogen terug te vallen naar NTLM, maar dat zal niet helpen als het diezelfde server betreft (lijkt mij, iig.)

[anboni]

Dit is de jaarlijkse reminder om productie omgevingen nooit binnen een week na patch tuesday te updaten.

[Prince]

Vanaf de patch beschikbaar is, is door iedereen geweten wat alle security exploits waren.
De reden waarom dit zo gepland is, is zodat zoveel mogelijk server tegelijk updaten, omdat alle mensen met slechte intenties dus ook weten wat de exploits zijn. De dag na "Patch Tuesday" kan je "Hack Wednesday" noemen.
Het is natuurlijk geheel aan jou om de keuze te maken om je hiervoor open te stellen.

[anboni]

Da's hartstikke leuk in theorie natuurlijk. In de praktijk staan onze klanten op hun achterste poten als er door een patch ongeplande downtime optreedt. Alleen als het risico echt heel concreet is, wordt dat risico geaccepteerd (en zelfs bij log4j hebben we klanten gehad die klaagden omdat we die vrijdagavond/nacht aanpassingen hebben gedaan waar ze milde hinder van ondervonden)

[Prince]

Natuurlijk moet je altijd de risico's afwegen en klanten soms (lees: vaak) opvoeden over de potentiële risico's. Opvoeding is ook "part of the job", naast risicoanalyse.
Als het systeem ietswat redundant is opgezet, dan kan je vaak de updates gefaseerd doen.
Als de klant er echter voor kiest, terwijl hij volledig bewust is van de risico's, om een paalde patch niet uit te voeren, dan is dat zijn risico om te nemen.
Maar dan heb je ook iets om het gesprek aan te gaan, wanneer hij ransomware moet betalen omdat zijn hele systeem onleesbaar is geworden.

[Prince]

Nu ik je bericht nogmaals lees, merk ik wel iets vreemds op.
Je spreekt over ongeplande downtime.
Patch Tuesday is vast en in te plannen en het spreekt voor zich dat je voor het uitvoeren van een patch dit moet communiceren. Daarnaast moet je altijd meegeven dat er een rollback kan plaatsvinden bij issues en hoe lang dit kan duren. Dit ook telkens in afspraak met de klant.
Hoe jij het omschrijft, is het alsof je patches uitvoert zonder enige communicatie. Ik ga ervan uit dat dit stukje verloren gegaan is in het neerpennen, maar dat je dit natuurlijk wel doet...

[anboni]

Microsoft bevestigt bug na Patch Tuesday waardoor Windows Servers vastlopen

Die ongeplande downtime.

Uiteraard worden patchrondes ruim van de voren aangekondigd.

[Reactie gewijzigd door anboni op 22 juli 2024 14:18]

[Prince]

Dat is dan de rollback die steeds afgesproken moet worden waar ik over spreek.
Eens wel dat klanten niet graag spreken over de non-happy-flow. Niet bij servers of infra, maar ook niet in software projecten of operationele processen.

[anboni]

Dat is dan de rollback die steeds afgesproken moet worden waar ik over spreek.

Nee, dat is een ongeplande vastloper van een server OS nadat de patch is geinstalleerd.

En nu Microsoft dus twee dagen na de release van de patch, die patch alweer terugtrekt ( (maar in het verleden heeft dat ook langer geduurd)), krijgen we weer een gepland moment om de rollback te doen. Althans, dat zouden we hebben als we zo stom waren geweest om die patches direct na release te installeren. Gelukkig zijn we dat niet.

[Mexxwelll]

Daarom doe je security controls op verschillende niveaus implementeren om het risico van niet direct patchen te verkleinen. Uiteraard als er een CVE 10/10 uitkomt moet er een keuze gemaakt worden om wellicht bepaalde systemen direct te patchen.

[Cybje]

Aan de andere kant is het natuurlijk niet goed als buitenstaanders al zo vergaande toegang hebben tot je server dat er exploits op kunnen worden losgelaten. Dat betekent dat je firewalling, netwerksegmentering, WAF (bij een webserver), et cetera ook al niet op orde is.

Neemt niet weg dat je belangrijke patches wel met enige spoed wil installeren. Maar indien mogelijk geniet de voorkeur om toch even te wachten. Of minimaal om eerst je test en acceptatie omgevingen te patchen.

[JackDaniels]

Ik zou willen aanvullen dat patches, of enige andere wijziging, nooit op een productieomgeving moet worden doorgevoerd, zonder dat er getest is op een andere, liefst productie-like, omgeving.

[downtime]

Lastig dat dit lek alleen domain controllers raakt. Niet elk bedrijf heeft een apart domein voor non-productie.

[JackDaniels]

Dan kan uiteraard, maar dan zou dan een bewust genomen risico moeten zijn.

[Cergorach]

Laat staan een representatieve testomgeving. Want een patch testen op een niet representatieve omgeving doet MS ook al, je test juist om te zien of jou specifieke combinatie van servers/software/infra issues ondervind. En ik betwijfel of iemand ooit dit issue had gevonden op een testomgeving...

[bzzzt]

Ik mag hopen dat Microsoft hun patches ook test voor ze uitgebracht worden?

[JackDaniels]

Hopen dat iemand iets voor je test is niet echt een veilige strategie imho. Uiteraard zal Microsoft dingen testen, maar zoals je ziet kan dat ook niet alles voorkomen.

[bzzzt]

Ik had meer gedacht dat Microsoft voor het geld wat ze vangen ook enige beloftes kan doen.
Maar als Microsoft al geen regressies kan voorkomen heeft zelf testen ook maar beperkte meerwaarde.

[Marve79]

Dat testen gebeurt vaak automatisch. En iets als een geheugenlek uit zich pas na een bepaalde tijd, afhankelijk van hoeveel geheugen de machine heeft is dat korter of langer.

[IrBaboon79]

Ik heb al heel veel omgevingen gezien maar ik heb eigenlijk nog nooit een fatsoenlijk representatieve "productie-like" omgeving gezien... of er is beknibbeld op HW dus clusters e.d. draaien dan niet, of alles is virtueel terwijl productie fysiek is (HW compatibility en drivers met issues?), of er zijn niet genoeg recente resources/test scripts en tools die de load representatief maken (ja, hij doet het maar onder load kapot), een schaduwdomein met echte users die ook echte dingen doen behalve een paar keer inloggen is ook allemaal moeilijk moeilijk, etc...

Zo krijg je dus dat een maandelijkse patch uiteindelijk in een 2x-jaar patch ontaardt...of dat nu een gewenste situatie is?

[JackDaniels]

Eens. Ligt eraan wat je als representatief ziet natuurlijk. Een complete acceptatie-omgeving die precies hetzelfde is als productie is eigenlijk niet haalbaar. Dus qua schaal zal het altijd kleiner zijn, maar zou het nog steeds dezelfde soort architectuur moeten zijn. En ook daarmee kun je voldoende de 'load' testen. Maar als je een compleet andere architectuur op acceptatie zet dan op productie dan is het natuurlijk vragen om moeilijkheden en dan niet alleen in het geval van patch updates.

[Marve79]

Het is al lastig genoeg om een productieomgeving werkende en updated te houden, laat staan ook nog een kopie ervan

[Zackito]

Ervaring leert dat als je een paar weken wacht er doorgaans geen grote bugs meer aanwezig zijn.
Als MSPer is het gewoon niet mogelijk om op zo een grote schaal te testen en rekening te houden met alle klanten.

Enkel kritische updates welke bijvoorbeeld een zero day oplost pushen wij direct naar de servers/werkstations. Overigens was dit een kritische update dus dat is wel weer jammer.

[Reactie gewijzigd door Zackito op 22 juli 2024 14:18]

[GeroldM]

Dat heet toch een acceptatie-omgeving?

Zo werk ik al minstens 15 jaar.

[JackDaniels]

Zo ben ik het ook gewend, maar het kan ook aan de schaal van een onderneming liggen dat het soms anders gaat. Tja en dan.....

[tvtech]

Wij hebben een prima testomgeving.
Alleen geen productieomgeving

[Rataplan_]

Lastige... want ook potentieel gevaarlijke exploits worden gedicht en dát wil je dan weer zo gauw mogelijk geregeld hebben. Ik denk soms met weemoed terug aan de tijd dat Windows patches gewoon afzonderlijk gedistribueerd werden, en je zelf de rotte appels eruit kon laten maar de rest dan toch in elk geval wél kon patchen. Nu is het alles of niets, en beiden is deze maand weer geen goede oplossing.

[Reactie gewijzigd door Rataplan_ op 22 juli 2024 14:18]

[_JGC_]

Ik wacht altijd een week voor het toepassen van patches, ik heb altijd 3e woensdag van de maand patch wednesday. Zijn veelal MKB klanten, test en acceptatie hebben de meesten helemaal niet.

Gisteravond dus uitgerold, lees ik vandaag dit .

Maargoed, de klanten die er last van zouden kunnen krijgen hebben de DCs los draaien zonder extra services erbij, dus als dat crasht zie ik de melding vanzelf tegemoet en is er nog een DC als backup. Je hebt ze echter ook die alle services op 1 (virtuele) machine knallen waardoor alles kapot gaat.

[Marve79]

Makkelijk gezegd maar tegenwoordig moet je kort op de bal spelen met al die ransomware. Managers eisen dat.

[Sjaakys]

Volledig mee eens. Snap niet waarom dit bericht een 0 rating heeft.

[DDX]

Dat gebeurt als zowel on-prem- als cloudbased domaincontrollers met Active Directory een authenticatieverzoek via Kerberos doen.

Dat cloudbased is hier niet echt van toepassing, het gaat gewoon om windows server, die op ijzer, virtueel in private cloud of virtueel in een publieke cloud kan draaien.

[the_stickie]

Op het eerste gezicht een lelijke... rebootende servers, lssas.exe is nogal euh belangrijk,... maar als je wat best practices volgde heeft een reboot van één DC (tegelijk) gelukkig maar heel weinig impact.
Bovendien lijkt het betrokken KB amper interessant, dus evengoed te rollbacken/uninstallen/...
Ach ja, shit happens en gelukkig word ik/worden we betaald om een oogje in het zeil te houden en soortgelijke dingen onder controle te houden

[wildhagen]

Op het eerste gezicht een lelijke... rebootende servers, lssas.exe is nogal euh belangrijk,... maar als je wat best practices volgde heeft een reboot van één DC (tegelijk) gelukkig maar heel weinig impact.

Tenzij die DC net één van je FSMO-rollen heeft, dan kan dat wel (korte) impact hebben. Of als je andere DC's door het (tijdelijk) wegvallen van die DC's juist ook extra last van die bug gaan krijgen omdat ze opeens meer werk krijgen, en als gevolg daarvan ook onderuit gaan

Bovendien lijkt het betrokken KB amper interessant, dus evengoed te rollbacken/uninstallen/...

Nou, 'amper interessant'? Het gaat hier om een security hotfix die maar liefst 61 beveiligingslekken dicht. Dat is toch best interessant over het algemeen...

Als je de lijst met security fixes in deze KB bekijkt zitten er daar heel veel bij met een score van boven de 7.5 of zelfs hoger dan 8, dat is best serieus qua lek.

[Sinned123]

Als een server eenmaal verbonden is met een DC's dan gaat hij pas na 5min geen contact op zoek naar een andere DC.
Er kan dus wel degelijk impact zijn.

[vinkjb]

.opgelost

[Reactie gewijzigd door vinkjb op 22 juli 2024 14:18]

[CriticalHit_NL]

Je kan deze guide mogelijk wel volgen, er vanuit gaande dat de recovery partitie de laatste partitie is na de primaire partitie van je OS:

https://www.minitool.com/...with-code-0x80070643.html

Heb het zelf ook maar handmatig moeten oplossen omdat tot dusver Microsoft daar zelf niet in geslaagd lijkt te zijn bij meerdere machines.

1. Eerst cmd.exe openen als administrator.
2. Dan reagentc /disable om de recovery omgeving uit te schakelen, doe je dit niet zul je naderhand het moeten fixen door Winre.wim van een andere installatie of iso te moeten overhevelen en dat is niet zo handig.
3. Typ in: diskpart
4. Typ in: list disk (fysieke schijven laten tonen)
5. Typ in: sel disk <OS schijfnummer> zonder <>
6. Typn in: list part (partities laten tonen)
7. Typ in: sel part <partitienummer van OS> zonder <>
8. Typ in: shrink desired=250 minimum=250 (verkleint OS schijf met 250mb)
9. Typ in: sel part <partitienummer herstelpartitie> zonder <>
10. Typ in: delete partition override (verwijdert herstelpartitie)
11. Typ in: list disk (indien er een * sterretje bij staat is de OS schijf een GPT schijf, anders MBR)

12.
Indien GPT typ in: create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
En dan: gpt attributes =0x8000000000000001

Indien MBR typ in: create partition primary id=27

13. Typ in: format quick fs=ntfs (label is niet nodig imo, formatteerd de herstelpartitie)
14. Typ in: list vol (controleren of het herstelvolume aanwezig is)
15. Typ in: reagentc /enable (inschakelen herstelpartitie)
16. Typ in: reagentc /info (kijken of deze weer geactiveerd is)

Daarna zou de update moeten lukken.
Maak wel een backup van te voren voordat je iets fout doet!

[Thc_Nbl]

microsoft zegt ook, dat als je geen recovery partitie hebt je de melding kan negeren.
m.a.w. hide die update en klaar.

[CriticalHit_NL]

Windows maakt ze wel standaard aan bij de installatie, maar inderdaad zal niet in elk geval zo zijn.

[LollieStick]

https://support.microsoft...a5-4fee-a02a-2fdea17075a8

Alstublieft. Mogelijk te weinig schijfruimte op de recovery partitie.

[SilentDecode]

Mogelijk te weinig schijfruimte op de recovery partitie.

Dit is bevestigd en de oplossing is om de recovery wat meer ruimte te geven.

Ik heb dit zelf getest en dit werkt, echter vind ik dit geen oplossing voor ~100 VM's die we op werk hebben draaien, en heb ik deze eigenlijk alleen toegepast op kritieke machines.

[WokBoy]

Is dit nou werkelijk dezelfde lompe bug die 2(?) maanden geleden in Windows 10 en 11 werd geïntroduceerd en afaik ook nog steeds niet verholpen is?

[Prince]

Er staat dat de server onverwachts opstart, dat is natuurlijk niet het issue; het is een onverwachte reboot
De oorspronkelijke tekst is "which triggers an unscheduled reboot"

Reeds doorgegeven aan Tijs...

[TijsZonderH]

Inmiddels aangepast, dank!

[prekz]

De microsoft pagina waar naar wordt gelinkt heeft het enkel over een memory leak op Domain Controllers.

[Prince]

Quote

Extreme memory leaks may cause LSASS to crash, which triggers an unscheduled reboot of underlying domain controllers (DCs).

[Sniffels]

Yup, gisteravond DC crash..