Microsoft repareert 16 kritieke 'remote code executions' tijdens Patch Tuesday

Microsoft heeft tijdens de Patch Tuesday-updateronde 71 kwetsbaarheden gerepareerd in Windows, Edge en andere software. Zestien bugs worden als Kritiek bestempeld. Dat zijn allemaal remotecode-executionbugs. Van een actief misbruikte bug waren al details openbaar.

Microsoft heeft KB5048685 voor Windows 11 24H2 en KB50485652 voor Windows 10 uitgebracht. In de maandelijkse patchronde worden in december 71 kwetsbaarheden gerepareerd. Zestien daarvan hebben de CVSS-classificatie Kritiek. Daarvan zitten er meerdere in LDAP, de Message Queueing en in het remote desktop protocol. Opvallend is dat alle zestien Kritieke bugs remotecode-executions zijn, waarmee het mogelijk is op afstand code op een systeem uit te voeren.

Een van de bugs tijdens de patchronde is een local privilege escalation die actief wordt misbruikt. Over die zeroday, CVE-2024-49138, was eerder al informatie openbaar. Nu zegt Microsoft ook dat de bug actief wordt misbruikt, al geeft het bedrijf daarover zoals gebruikelijk geen details. De kwetsbaarheid zit in de Common Log File System-driver. Het gaat om een heap-based buffer overflow waarmee het mogelijk was System-rechten op een geïnfecteerd systeem te krijgen.

De patchupdate is de enige update die in december uitkomt voor Windows 11. Microsoft zei eerder al dat het geen reguliere, non-securityupdate uitbrengt voor het nieuwe OS vanwege de feestdagen.

Reacties (44)

[Yzord]

Ik blijf het frappant vinden dat als er kritieke kwetsbaarheden zijn die actief gebruikt worden dat men dan wacht tot patch Tuesday. In feite kan men dus nog een maand doorgaan met het misbruiken ervan. En eentje was dus al algemeen bekend dus waarom men deze niet meteen aanpakt vind ik wel bijzonder.

En natuurlijk zal er getest moeten worden, dat snap ik, maar kwaadwillenden kunnen dus inspelen op de maandelijkse patchronde door een dag later het actief te gebruiken wetende dat het pas, met goed geluk, een maand later gedicht wordt.

[Blokker_1999]

Dat hangt van vele factoren af. Indien noodzakelijk zal men wel degelijk de patch sneller uitbrengen, maar dat heeft ook zijn nadelen. Vele bedrijven, zeker grote bedrijven, moeten patches door een heel test traject sturen, dat kost tijd. En je kan vaak niet zomaar 2 patches door dezelfde testsystemen sturen wanneer je gaat testen op stabiliteit, want als het dan misgaat, welke patch vormt dan ineens het probleem. Daarom dat vele bedrijven alsnog op patch tuesday zouden wachten.

Maar door het vrijgeven van die patch kunnen mensen met minder goede bedoelingen gerichter gaan zoeken naar wat er mogelijk mis is en kan het misbruik gaan toenemen waardoor er ook weer grotere risico's gaan ontstaan. Daarom dus dat MS een afweging moet maken om te bepalen wat belangrijker is, sneller patchen en dus mogelijks grotere bedrijven meer risico geven terwijl aanvallers kunnen gaan zoeken of wachten tot patch tuesday en de weinigen die weten hoe het te misbruiken meer tijd geven.

[bazzym]

Precies dat, alles doorloopt hier de OTAP-straat, wordt daar volledig automatisch uitgerold.
Sterker nog, nadat de patch gereleased wordt op patch tuesday staat pas bijna een maand later op onze productieomgeving.

Als er beveiligingsrisico's zijn dan probeer je die ook al op andere vlakken af te vangen.

[wmkuipers]

Een maand incubatietijd voor security patches is wel absurd lang. Hier zit 5 uren tussen OTA en P. Betere geautomatiseerde testing op A brengt tijdig problemen aan het licht, gelukkig zijn die er zelden.

[L0g0ff]

Dat ligt aan de omgeving.

Ik heb beide scenarios. 1 omgeving waar alles in 2 dagen automatisch via otap wordt geupdate (webapplicatie)

Andere situaties is een ziekenhuis met een mix van workloads, externe leveranciers en afspraken.

Ook Automated en daar duurt het een maand. Mede omdat er eerst akkoord moet komen van een leverancier met een heel belangrijk beeldmateriaal proces.

Er is helaas niet 1 methode.

[Frame164]

Hoe zou jij het doen?

[henk717]

Zoals Linux bijvoorbeeld wat een veel beter update systeem heeft. Daar heb je geen gigantische updare tijd maar een simpelere package manager die weet welke bestanden bij welk onderdeel horen. Kritieke kwetsbaarheid?Wordt er zo snel mogelijk een update gepusht voor dat package en die heb je dan ook zo binnen en soms zelfs zonder reboot.

[GertMenkel]

Dat kan Windows ook wel, maar soms maakt een patch weer andere dingen kapot. Daarom stellen mensen Windows-updates ook vaak uit bij grote omgevingen, of worden ze langzaam uitgerold. Een kwetsbaarheid die via een printopdracht je computer over kan nemen is gevaarlijk, maar 5000 mensen die niet meer kunnen printen doordat de printerdriver niet met de fix om kan gaan is net zo'n groot risico.

Overigens rolt Microsoft bij kritieke lekken nog wel eens eerder patches uit, het is niet meer zoals vroeger dat het altijd de tweede dinsdag van de maand gebeurt. Ze proberen nog wel patches te groeperen, zodat IT-beheerders niet na het testen van een set updates meteen een nieuwe set updates binnenkomt, op die manier heb je fulltime update-testers nodig .

[Rolfie]

Dit klopt. Echter voor bedrijven maakt dit het niet gemakkelijker. Je wilt voorspelbaarheid hebben in je changes. Iedere dag je servers patchen doe je niet. Leuk voor thuis bijvoorbeeld, maar als bedrijf ga je dit niet redden.

[field33P]

Daar heb je geen gigantische updare tijd maar een simpelere package manager die weet welke bestanden bij welk onderdeel horen

Dependency resolution is juist langzamer, zeker voor een besturingssysteem wat uit een hele rits aan losse packages bestaat. Een Windows-update is juist simpeler omdat er één kernel in omloop is en één bureaubladomgeving.

[sfranken]

Een Windows-update is juist simpeler omdat er één kernel in omloop is en één bureaubladomgeving.

Uh, nee. Je hebt Windows server versies, en Windows desktop versies. Die hebben in nummer allemaal dezelfde kernel, maar daar zitten toch echt verschillen in. Ook heb je verschillende versies van de Windows shell, kijk maar naar 7 -> 8 -> 8.1 -> 10 -> 11

[field33P]

Fair, 11 23H2 en 24H2 hebben hun eigen kernels en desktop-code, maar binnen die releases zijn ze wel homogeen.

[Reactie gewijzigd door field33P op 11 december 2024 15:39]

[henk717]

Nee, op Linux kan ik een oude linux pakken en alles updaten in een paar minuten. Meer dan 1000 updates is echt geen probleem. Bij windows update ben ik veel langer bezig met alle stappen die Windows doet voor een update.

[curkey]

Als je gevalideerde IT omgevingen hebt met bedrijfskritische software dan ga je echt niet zomaar je OS lopen patchen.

Dat heeft niets met een beter update-systeem te maken als wel een risico-afdekking en een compliance maatregel. Je kunt gewoon niet ongeteste wijzigingen op je systeem doorvoeren.

[digigast]

Als je gevalideerde IT omgevingen hebt met bedrijfskritische software dan hoor je ook geen windows te draaien

[Aalard99]

Ik zou niet weten waarom niet? Bedrijfskritische software kan van alles zijn. Van HR systemen, kassa systemen, systemen die op een helpdesk draaien en ga zo maar door. Als je business model een helpdesk is dan is de kans vrij groot dat de medewerkers gewoon met Windows systemen werken. Ik kom maar weinig bedrijven tegen die Linux als desktop gebruiken. Ja in de Backend komt Linux wel vaak voor....

Kijk naar de impact die Crowdstrike had op Windows systemen....

[Reactie gewijzigd door Aalard99 op 11 december 2024 17:42]

[curkey]

Ja welkom in 2024, deze is oud. Als je vendor specifieke software hebt dat op een specifiek platform draait, heb je weinig keus.

En laten we realistisch wezen, ook in Linux kun je prima fuckups realiseren met een update. Verkeerde versie van een library, een update van de Java JVM terwijl er stiekem een utility is dat per sé nog 8 nodig heeft.

Ik zie niet het verschil om eerlijk te zijn: met alle platforms moet je gewoon een regressietest uitvoeren. Zeker ook als je bv interfaces hebt met gevalideerde systemen die je hebt vanwege wetgeving. Je kunt je niet veroorloven dat zoiets stukloopt.

[henk717]

Ik vind dat geen argument, je wil dat juist wel kunnen doen. Waarom zou ik als bedrijf willen wachten tot het de patch dag van Microsoft is? Prima dat je je servers op een vaste dag update die gaan uberhaupt niet automatisch. Als bedrijven heel specifiek patchbeleid willen voeren is dat prima, maar voor systemen met critieke beveiliging wil je niet weken lang kwetsbaar zijn voor remote execution.

[curkey]

Totdat jouw overhaaste patch ineens 60 fabrieken met 50 miljoen per dag stil zet, en je vanuit de wet (bijvoorbeeld in de pharmasector) specifieke eisen hebt hoe je met software moet omgaan en je o.a. geen zaken ongetest (of door de juiste personen goedgekeurd) in een productieomgeving mag zetten.

Zeker, weken wachten is niet altijd een optie, maar ongezien de boel setup.exe -> Next -> Next -> Finish kan echt niet.

[gimbal]

Magische toverspreuk. Errata Evictus!

Ik denk overigens dat de betere vraag is: hoe denk jij dat een test eruit ziet voor een operating system? Want ik denk dat daar het stukje enorm gemakzuchtig denken dwarszit. Testen voor normale software is al een enorme foutgevoelige last, voor een operating system kan ik het niet eens bevatten.

[Reactie gewijzigd door gimbal op 11 december 2024 10:21]

[Yzord]

En jij denkt dus dat Microsoft de hele tijd met een toverstaf de boel fixed? Natuurlijk wordt er getest. Dat dit zo nu en dan wel eens fout gaat is wel te bevestigen door de vele nieuwsberichten dat er het een en het ander fout gaat. Maar ze gaan echt geen patch online zetten die simpelweg niet getest is. Dat zou wel heel erg onprofessioneel zijn.

[R4gnax]

En jij denkt dus dat Microsoft de hele tijd met een toverstaf de boel fixed? Natuurlijk wordt er getest.

Ze hebben een aantal jaren terug al weer, hun hele hardware park aan testopstellingen de deur uitgedaan en bijna hun volledige afdeling aan gespecialiseerde test engineers de laan uitgestuurd. Windows wordt al tijden lang getest op geidealiseerde virtuele machines die continu clean-slate draaien; en de tests worden geschreven door de ontwikkelafdelingen zelf. (Slager die het eigen vlees keurt.)

Daarnaast hanteert MS een ping-pong ontwikkelmodel; wat wil zeggen: een half jaar lang vol gas features ontwikkelen, en daarna een half jaar alle bugs proberen op te lappen. Ze hanteren hiervoor schijnbaar strikte deadlines waardoor het nogal eens wil gebeuren dat er features op de mainline belanden waarvan men weet dat ze eigenlijk compleet stuk zijn en hopen problemen gaan veroorzaken -- maar als ze ze niet er in duwen, moet men een heel jaar wachten. Dus god zegene de greep. Maw YOLO.

De print queue die 5 keer achter elkaar compleet stuk ging in Windows 10?
Dat was dan dus waarschijnlijk zo'n plakje salami wat langzaamaan in een spoor van zn eigen groezelige oude vet langs de muur naar beneden aan het glijden ging, nadat men drie maanden eerder alles tegen de muur omhoog had gesmeten om te kijken wat er zou blijven plakken.

[Reactie gewijzigd door R4gnax op 11 december 2024 19:59]

[digigast]

Wat is dan normale software volgens jou?

En hoe is een OS anders dan een combinatie van meerdere "normale software"?

Er zit geen magische programmeertaal ofzo in een OS. De enige delen die je een beetje anders zou kunnen zien dan de gemiddelde stukken software, zijn de kernel en in zekere zin de drivers (hoewel die vaak niet veel anders zijn dan een vertaal laag).

[Robertdw]

Een OS is in functie anders, als daar met een patch iets fout gaat heb je een goede kans op een niet werkend systeem. Bij een patch van 1 programma heb je alleen kans dat dat ene programma niet meer werkt.

[digigast]

Er is slechts een klein deel van een OS dat er voor kan zorgen dat het hele systeem niks meer doet. Voor het grootste deel maakt het voor je test- en update scenario dus niet zo veel uit. Helemaal als het op security aan komt met als verschil dat een applicatie uit "het OS landschap" vaker systeemrechten heeft.

Hoewel Mickeysoft het je graag doet geloven, is een OS niet een magisch monolitisch ding. En het gros is "just another application".

[Robertdw]

Dat hebben we toch al diverse keren anders gezien. Er zijn toch al diverse systeemcrashes geweest na een windowsupdate. Dat onderdelen van een OS Just another application zouden zijn is natuurlijk onzin. Ook al zijn het afzonderlijke onderdelen dam nog kunnen die een leiden tot een totale crash van een systeem. Dat zal niet zo snel gebeuren met een programma wat verder niets met het functioneren van het OS te maken heeft. Masr goed sommige weten het altijd beter dan degenen die het OS ontwikkeld hebben.

[tweakorinho]

Enorm gemakszuchtig denken? Bedoel je Dunning-Kruger?
Wikipedia: Dunning-krugereffect

[Yzord]

Me focussen op de actief misbruikte kwetsbaarheid en de patch ad hoc uitrollen als er een akkoord is vanuit de teststraat. De rest komt met patch Tuesday wel, maar je kan jezelf in ieder geval op de borst kloppen dat je adequaat handelt naar je klanten toe.

Dat dit bij sysadmins voor enige verwarring kan zorgen omdat deze gewend zijn alleen op patch Tuesday de boel extra in de gaten te houden kan eenvoudig opgelost worden met een notificatie. Persoonlijk, maar wie ben ik, zou ik het top prioriteit geven als een kwetsbaarheid actief wordt misbruikt.

[Marve79]

Het blijft een afweging natuurlijk hoe actief het misbruik is. Bij zoiets als Blaster in het verleden waar heel de wereld er last van heeft doe je dat wel ja. Maar je gaat niet steeds adhoc slecht geteste patches uitbrengen voor een aantal rce's die in het wild opduiken. Wat je wel kunt doen is een mitigatie voorstellen, wellicht was die er al.

Plus je kunt ze wel uitbrengen maar IT gaat er waarschijnlijk nog 30 dagen over doen om die uit te rollen over alle systemen.

Een andere oplossing die tegenwoordig populair is is virtual patching. Je kunt dan de patch 'virtueel' overal toepassen (dus in de stream van je netwerkverkeer die de code execution detecteert). Dan ben je beschermd tot de uiteindelijke patch er is.

[Z80]

Deze bug kan alleen local worden uitgebuit. Tenzij gecombineerd.
Een aanvaller moet dus al in het systeem zitten voordat deze bug misbruikt kan worden. wat de noodzaak om nu, nu, nu een patch uit te brengen wat lager is.

[HuisRocker]

Omdat die actief misbruikte kwetsbaarheid "Attack Vector: Local" is, dus moet de aanvaller een lokale gebruiker op het systeem zijn naast dat deze (uiteraard) moet weten hoe de kwetsbaarheid misbruikt kan worden.

[HakanX]

I.c.m. één van de 16 kritieke remote code executions hoef je niet erg lokaal te zien. Eerst binnenkomen en dan admin worden.

[HuisRocker]

Zou kunnen, al moet je dan dus al weten hoe je minimaal twee verschillende kwetsbaarheden samen kan misbruiken, men schat die kans dus duidelijk in als 'relatief laag' (voor de duidelijkheid; het is niet mijn inschatting en/of mening, ook niet die in de vorige post ).

[Wouterie]

Goed punt. Ik neem even aan dat ze de gevallen waarbij duidelijk is dat het lek actief wordt misbruikt al eerder behandelen. We hebben ook eens gehad dat we een probleem hadden, dat Microsoft het bij/voor ons kwam oplossen en later pas een patch kwam voor de hele wereld. Dat stelde destijds niet zo veel voor, bij een actief misbruikt lek kan ik me voorstellen dat ze daar ook de nodige tijd in steken.

[Rolfie]

Bedrijven willen ook voorspelbaarheid. De meeste bedrijven hebben/kunnen nu al de Microsoft Patches inplannen voor volgend jaar, zodat eventuele andere changes, hier geen last van hebben. De patches uitrollen kan ook gerust over 2 of soms 3 weken gedaan worden. Eerst DEV/TEST en daarna pas PROD.
Voor eerst de IT afdeling/key users, daarna pas alle gebruikers.

Wat we nu en wanneer gaan uitrollen op MS Patches, weten we eigenlijk al voor de komende 12 maanden.

Blijft een lastig punt hoor, hoe snel en hoe vaak moet je nu exact patches uitrollen....

[Simon Weel]

Microsoft heeft KB5048685 voor Windows 11 24H2 en KB50485652 voor Windows 10 uitgebracht.

Tekst artikel klopt niet. KB5048685 is voor Windows 11 Enterprise and Education, version 22H2 Windows 11 version 23H2, all editions.
En KB5048652 is voor Windows 10 Enterprise LTSC 2021 Windows 10 IoT Enterprise LTSC 2021 Windows 10, version 22H2, all editions.

[Reactie gewijzigd door Simon Weel op 11 december 2024 12:52]

[LadyGiga]

KB5048685
KB5048685
2x hetzelfde?

[Llopigat]

Ja ik had het ook al gemerkt, ik zat te kijken op mijn LTSC box en ik zag daar een ander nummer langskomen dus ik vroeg me al af of het wel goed ging met die updates. Maar er stond dus gewoon een verkeerd nummer in het artikel.

[Sunrise]

Kan Microsoft niet met een popup vragen de desbetreffende stukjes software uit te schakelen totdat ze een fix hebben uitgebracht? Ik denk het wel, in de meeste gevallen, sowieso houdt je dan de optie om het toch te blijven gebruiken op eigen risico.

[MrMonkE]

Dan informeer je met je patch iedereen die er misbruik van wil maken.

[MrDrako]

Vergeet niet dat, wat tweakers helaas niet vermeld, dit ook voor alle server OS'en van microsoft geld, van 2008(!) tot 2025. Als je als bedrijf nog 2008/2012 servers zonder extended security update (ESU)'s hebt, loop je dus echt een steeds groter risico.

[Maulet]

Vreemd.
Ik heb(eindelijk) 2023H2 voorgeschoteld gekregen....

[Armselig]

Ah, dus daarom zie ik rechtsonderin weer een schermpje met een geel stipje, nou ja, komt later wel.. Geen zin om te rebooten nu.