Google publiceert details van Windows-zeroday die actief misbruikt wordt

Google Project Zero heeft een zeroday-kwetsbaarheid in Windows 7 tot en met 10 onthuld omdat deze volgens het bedrijf al actief gebruikt wordt in de praktijk. De lokale kwetsbaarheid bevindt zich in de Windows Kernel Cryptography Driver en kan leiden tot privilege escalation.

Google zegt dat het 'gelooft' dat de kwetsbaarheid sinds ten minste Windows 7 aanwezig is, maar in ieder geval werkt op een machine met een up-to-date Windows 10 build 1903, 64-bits. Google heeft een uitgebreide beschrijving van de kwetsbaarheid en exploit, inclusief de broncode van een proof of concept-programma. De kwetsbaarheid heeft aanduiding CVE-2020-17087. Bewijs dat de kwetsbaarheid uitgebuit wordt, geeft Google niet.

Google stelt dat het Microsoft zeven dagen de tijd heeft gegeven om deze kwetsbaarheid te verhelpen. De deadline zou zo kort zijn wegens de tekenen dat hij al in het wild gebruikt wordt. Microsoft heeft op dit moment nog geen fix uitgebracht. Er wordt verwacht dat dit zal gebeuren op 10 november, de volgende Patch Tuesday van Microsoft, schrijft The Register. Microsoft laat in een reactie weten dat 'een security-update ontwikkelen altijd een koorddans is tussen snelheid en kwaliteit'.

The Register schrijft verder dat Microsoft wel aantekent dat de kwetsbaarheid in feite meevalt omdat deze onderdeel moet zijn van een keten van exploits. Het gaat om een lokale kwetsbaarheid, dus eerst moet een aanvaller lokale toegang krijgen tot een Windows-machine. De enige bekende schakel in de keten die dit mogelijk zou maken, een Chromium-kwetsbaarheid met aanduiding CVE-2020-15999, is eerder deze maand al verholpen.

Reacties (117)

[wildhagen]

Ik vind een termijn van 7 dagen wel extreem kort. Zeker voor een lek dat relatief low-risk is, door de complexiteit om hem te exploiten.

Ontwikkelen en vooral testen van een patch in een produkt zo complex als Windows kost gewoon tijd. Als je dit overhaast introduceer je weer andere bugs, of andere applicaties stoppen met werken. Met alle impact vandien.

Imho is 7 dagen echt véél te kort. Een termijn van 25-30 dagen ofzo lijkt me heel wat realistischer.

[Reactie gewijzigd door wildhagen op 23 juli 2024 11:23]

[GertMenkel]

Doorgaans gebruikt Google een termijn van 90 dagen, maar dit lek werd al actief misbruikt door malware. Het idee dat Google hierbij had is dat op deze manier kan worden gemonitord naar verdacht gedrag dat deze zero day misbruikt, waar dat anders niet kon.

Bij een normale securitybug gebeurt dit pas na drie maanden dus, maar als het lek in de malwarewereld al bekend is, heeft het weinig nut om die lange deadline te behouden.

Overigens vind ik zeven dagen voor een memory bug best prima, het oplossen van de bug kost een programmeur een uur met de voorbeeldcode meegeleverd. Het duurt langer om de fix te compilen dan om hem te testen. Omdat de fix ook nog eens geen gedrag aanpast, hoeft er maar minimaal getest te worden en kan de fix met drie dagen de deur uit.

Als het probleem onderdeel zou zijn van het protocol, zoals de recente netlogon-kwetsbaarheid, of te maken had met parsen van netwerkpakketten, zoals de IPV6-RCE van laatst, had ik je gelijk gegeven. In dit geval is de bug te verhelpen door een integer overflow te repareren, een fix van een regel of drie. Daar heeft Microsoft niet zoveel tijd voor nodig als het goed is.

[kodak]

De gedachte achter verantwoordelijk bekendmaken is alleen niet dat je zelf maar wat uitgangspunten gaat wijzigen wanneer het je uit komt maar dat je als researchers ook betrouwbaar bent is verwachtingen. Bedrijven en ontwikkelaars zijn niet 24/7 beschikbaar en hebben ook te maken met kwaliteitseisen enz. Daarom zijn de deadlines er. Net zoals je dan niet hoeft te verwachten dat een ontwikkelaar dan niet zomaar meer tijd neemt (waar het project zelfs ook enige mogelijkheid voor had bij de 90 dagen deadline) is het dan ook niet redelijk om als researcher dan maar veel eerder te gaan bekend maken omdat je een eigen mening hebt. Als je je als researcher niet in de spelregels kan vinden of die niet kent of snapt dan hoor je er ook niet aan mee te doen. Anders kan je net zo goed geen regels opstellen en steeds zelf maar wat verzinnen wat je zelf goed uit komt.

[Reactie gewijzigd door kodak op 23 juli 2024 11:23]

[jpsch]

Bedrijven als Google en MS kunnen toch 24 uur per dag doorgaan met ontwikkeling? Ze hebben personeel over de hele wereld.

[Relief2009]

Development vindt alleen in de VS plaats.

[Matthijs Hoekstra]

Nope, Microsoft heeft dev centra over de hele wereld. En dan zijn er ook nog genoeg devs die remote werken.

[jpsch]

Misschien maar eens aanpassen?

[kodak]

Ga jij dan ook meer betalen voor je software? En wat is dan in de tussentijd de verantwoordelijkheid van Google of researchers als de bedrijven en klanten het niet gaat lukken om binnen 7 dagen een oplossing te hebben die ook nog getest moet worden en je niet zomaar even overal toe past in een netwerk met vele verschillende eisen over beschikbaarheid en betrouwbaarheid? Wie zijn Google of de researchers of wij om wel even voor een ander te bepalen wat er zal moeten veranderen als je zelf verder geen enkele verantwoordelijkheid draagt om dat te moeten regelen en bekostigen?

[ejabberd]

Ga jij dan ook meer betalen voor je software?

Als je voor welke software dan ook kiest, weet je op voorhand dat er ooit zulke beveiligingslekken zullen zijn waarbij je op korte termijn tijd en geld zal moeten uitgeven om ze te verhelpen. Er kan dan op voorhand een draaiboek opgesteld worden en ingeschat worden wat dit telkens zal kosten. Ik weet dat hier vaak op voorhand onvoldoende over wordt nagedacht.

[Bender]

Waarom meer betalen? Die link zie ik niet?

[divvid]

De mensen die dit soort patches schrijven zijn dun gezaaid en hebben waarschijnlijk óók een gezin...
7 dagen is gewoon tekort voor iets waar je fysieke toegang voor moet hebben.

[dasiro]

dit lek werd al actief misbruikt door malware. Het idee dat Google hierbij had is dat op deze manier kan worden gemonitord naar verdacht gedrag dat deze zero day misbruikt, waar dat anders niet kon.

het vrijgeven ervan zorgt er enkel voor dat nóg meer malwaremakers er misbruik van kunnen gaan maken. Geen idee waarom je denkt dat dit door het vrijgeven ervan plots gemonitorred zou kunnen worden. Dit is zoals bij een auto uitleggen wélke draden je tegen elkaar moet houden om hem te starten en waar ze zich bevinden ipv te zeggen dat een multipla model 2005 het eenvoudig te doen is en je aan fiat hebt gezegd van "hey dat stukje plastic van 2mm in het dashboard waar die draden onder zitten zou je misschien beter een plaatje staal achter steken."

[johnkeates]

Nee, het vrijgeven geeft mensen de kans om er zelf wat aan te doen. Zo kan je bijv. als je een IoC of signature van netwerkverkeer hebt in je IPS en zelfs basic DPI firewalls bekende soorten misbruik actief weren. Dat kan je sowieso al doen, maar om dat dat best arbeidsintensief of CPU-intensief kan zijn is dat voor de lange termijn niet praktisch (en daarom hebben we vendor patches).

Een andere optie is derde partijen die micropatching en in-memory patching doen. Dat werkt vooral bij VMs goed maar op bare-metal kan dat ook. Wat ze doen is realtime binary editing om bekende codepaden die misbruikt worden uit te patchen. Dat gaat niet altijd perfect, en ook daar heb je weer met een lagere efficiency te maken, maar het is in elk geval een middel om door te kunnen met enige bescherming.

Dat jij denkt dat een malwaremaker hier opeens meer misbruik van gaat maken betekent niet dat dat ook daadwerkelijk zo is, vooral niet als de exploits al gewoon bekend zijn en gedeeld worden. Eigenlijk kunnen we stellen dat iedereen er van op de hoogte is, behalve de 'enterprise markt'. Black markets en grey markets hebben vaak al lang zowel de exploits als de mitigerende maatregelen, nog voor dat er in het publieke nieuws iets over een kwetsbaarheid naar boven komt.

[dasiro]

het publiekelijk vrijgeven van een proof-of-concept samen met de exploit is de kat bij de melk zetten. Bedrijven als google en microsoft hebben ook hun bronnen binnen de black & grey markets, al zullen ze dat niet met zoveel woorden toegeven.
Het gaat hier om een exploit die in een chain gebruikt moet worden en lokaal draait, dus kan je DPI en netwerktraffic-scanner rechtstreeks de vuilbak in voor dit gevalletje. Als Microsoft het binnen 2 weken patcht, dan zullen er maar heel weinig bedrijven zijn die hiervoor zélf of uitbesteed iets sneller aan zullen kunnen doen en weten dat dat geld dan verloren is. Dit is gewoon het onverantwoord aanvallen van een concurrent.

[johnkeates]

Hoe denk je dat die exploit op je machine terecht komt? Een chinees die naar je kantoor reist met een USB-stick?

Als dat spul binnen komt kan je het detecteren voor dat het op de machine staat. Wat Google nu vrijgegeven heeft is juist extreem nuttig om zelf wat te kunnen doen met de tools die je hebt. Zodra je toegang op IOCTL 0x390400 ziet (al dan niet via CNG die je als Device aanroept) vanaf een set bekende calls kan je meteen reageren. Als deze informatie niet beschikbaar gesteld was kon je dus niet anticiperen.

Verder heeft men helemaal geen PoC en Exploit vrijgegeven, er is een kwetsbaarheid gepubliceerd met een stukje pseudocode die uitlegt waarom het een kwetsbaarheid is.

Het benutten van de kwetsbaarheid om misbruik te maken van een systeem wordt nergens uitgelegd, en alleen genoemd als zijnde een feit dat dit al gebeurt en gewoon te koop is.

Het vrijgeven van de informatie as-is doet maar 1 ding: beheerders laten weten dat dit iets is wat gebeurt, actief misbruikt wordt, en waar ze op kunnen letten tot dat er een patch is. Skriptkiddies zijn niet slim genoeg om het zelf in te zetten, en mensen die wel slim genoeg zijn en het willen misbruiken kopen dat gewoon in of reverse-engineren zelf een exploit, ook zonder dat Google (of iemand anders) dit bekend maakt.

[Reactie gewijzigd door johnkeates op 23 juli 2024 11:23]

[latka]

Virusscanners moeten wel weten waarop ze moeten scannen. Google zou kunnen proberen alle vendoren van informatie te voorzien en hopen dat er niets lekt, maar dat is ook onbegonnen werk. Alles MS informeren als de exploit al in gebruik is is. mi. niet echt voldoende.

[dasiro]

legitieme antivirusbedrijven zullen wel hun kanalen hebben om gevoelige gegevens zoals dit vertrouwelijk te verkrijgen en als dusdanig ook te behandelen.

[bbob]

Doorgaans gebruikt Google een termijn van 90 dagen, maar dit lek werd al actief misbruikt door malware. Het idee dat Google hierbij had is dat op deze manier kan worden gemonitord naar verdacht gedrag dat deze zero day misbruikt, waar dat anders niet kon.

Google stelt dat het Microsoft zeven dagen de tijd heeft gegeven om deze kwetsbaarheid te verhelpen. De deadline zou zo kort zijn wegens de tekenen dat hij al in het wild gebruikt wordt.

Jij stelt dat het actief misbruikt werd door malware. Google heeft het alleen over tekenen. Dat is wet mij betreft een groot verschil. Tekenen is geen vaststaand feit het is een vermoeden.

Maar google speelt ook hier weer rechter en aanklager en waar ze normaal 90 dagen hanteren is er nu dus weer een nieuwe door google bedachte wet max 7 dagen als het lees goed misschien actief misbruikt wordt.

Ik wordt een beetje ziek van dat gedrag van google.

[GertMenkel]

Google geeft aan bewijs te hebben dat dit gaat om targeted exploitation, denk aan aanvallen op journalisten etc. Ik zie nergens in de bug staan dat Google het heeft over tekenen, de eerste regel van het report heeft het over bewijs. Dit is bevestigd met de "Director of Google's Threat Analysis Group", oftewel iemand die gespecialiseerd is in het onderzoeken van malwareaanvallen.

Die zeven dagen policy is niet nieuw, die is al zeven dagen sinds 2013. De 90 dagen policy is begin dit jaar aangepast (door altijd 90 dagen te wachten, ook al is de bug na 20 dagen opgelost) maar deze niet. Ik zou een interne afspraak die al zeven jaar lang wordt uitgevoerd niet een "nieuwe door Google bedachte wet" noemen.

En welke wet denk je dat hier relevant is? Er is echt niks wat ze weerhoudt het gewoon direct op hun homepage te zetten zonder Microsoft te waarschuwen. Google loopt gratis Microsoft's werk te doen en deelt, in tegenstelling tot Microsoft, hun bevindingen met iedereen in plaats van een stel bedrijven dat MS mag gaan betalen voor signatures van malware. Google speelt hier niet "rechter en aanklager", Google houdt zich aan de regels en afspraken die het binnen Google gesteld heeft.

Wees boos op Microsoft en hun triviale bugs als je iemand de schuld moet geven. Als dit zonder disclosure op een Russisch blog was verschenen zoals de meeste van dit soort simpele exploits had niemand er wat om gegeven, maar omdat Google het doet is het slecht en kwaadaardig en een manifestatie van de softwaresatan zelve. Als er iets is dat met Project Zero is aangetoond is dat deadlines vasthouden gewoon werkt. De hoeveelheid routerfabrikanten die toch opeens in minder dan twee jaar updates maken is enorm gestegen, de patch cycle van Windows is enorm versneld en de vendor updates voor Android-firmware zijn nog nooit zo snel gekomen als wanneer Google er een blog over schrijft. Een fix voor een integer overflow kan met zeven dagen echt wel wereldwijd verspreid zijn hoor, het is niks bijzonders.

[bbob]

Google loopt ms werk te doen. bug is iets waar ieder software bedrijf last van heeft en ja zelf linux dus dat anderen bij iedere bug vinden is heel normaal en weinig te maken met het werk van een ander doen. Die opmerking komt nogal gekleurd over.

Google heeft met android wat mij betraft het slechte trackrecord van veiligheid en updates. Eerst android gratis in de markt dumpen, updates afschuiven of fabrikanten die dat niet doen. Pas nu beginnen ze door te hebben dat ze dat een beetje zelf moeten doen. maar google doet en deed alles ook vanuit marktaandeel en veiligheid is jaren een ondergeschoven kindje geweest.

Je kan dus wel afgeven op MS, google is wat dat betreft geen haar beter, misschien zelf slechter.

[Drardollan]

Overigens vind ik zeven dagen voor een memory bug best prima, het oplossen van de bug kost een programmeur een uur met de voorbeeldcode meegeleverd. Het duurt langer om de fix te compilen dan om hem te testen. Omdat de fix ook nog eens geen gedrag aanpast, hoeft er maar minimaal getest te worden en kan de fix met drie dagen de deur uit.

Klinkt leuk voor een klein bedrijf met software bij 100 of 1000 klanten. Microsoft bediend met Windows wel een iets grotere markt. Daar is wel iets meer tijd voor nodig om de impact te bepalen.

[rodie83]

Dat is net zo goed een aanname.

[robvanwijk]

dit lek werd al actief misbruikt door malware. Het idee dat Google hierbij had is dat op deze manier kan worden gemonitord naar verdacht gedrag dat deze zero day misbruikt, waar dat anders niet kon.

Behalve dan dat het een lokale exploit is. De details vrijgeven zodat talloze organisaties wereldwijd hun firewall filters bij kunnen werken is in theorie een goed punt, maar dat geldt natuurlijk alleen voor remote exploits. Ook als ze signatures zouden delen met de leveranciers van virusscanners, dan zou ik dat begrijpelijk vinden. Maar het ontgaat me compleet waarom het volledig openbaar maken van alle details nuttig zou zijn ^*) in deze situatie.

*) Vanuit beveiligingsoogpunt; vanuit een kleinzielig concurrentje-pesten oogpunt snap ik het natuurlijk prima.

[Kronossan]

In een managementfunctie toevallig?

[rene_fb]

Tja... Microsoft is een directe concurrent.
En een concurrent schandpalen... Hoe sneller hoe beter, zullen ze wel denken.

[zalazar]

7 dagen is inderdaad belachelijk maar bij mij levert dit juist een andere reactie op.
Als Google denkt op deze manier met bugs om te moeten gaan dan kan Google Project Zero zich misschien beter bij de hackers community aansluiten en direct alles doorsluizen.

[Cergorach]

Maar dat is toch niet het doel van het project! Het doel is direct de concurrentie te ondermijnen op een publiekelijke en legale manier.

[fapkonijntje]

Het is ook niet zo alsof de Google software van uitmuntende kwaliteit is. Dit soort gedrag, vooral van Google is wat hypocriet soms. Dat is net als dat Apple bij Android of Windows problemen die na updates onstaan gaat aanwijzen, ook totaal ongeloofwaardig.

[GertMenkel]

Als Project Zero een bug vindt in Android gebruiken ze gewoon dezelfde timing hoor. Sterker nog, door de manier waarop Google weinig invloed kan hebben op de timing van andere Android-fabrikanten zou je zelfs kunnen stellen dat die 90 dagen die ze aanhouden te kort zijn

Dit is niet zoals Apple die bij Android of Windows kleine probleempjes aanwijst, dit is meer als dat de security-afdeling van Apple onderzoek doet naar malware op Android-telefoons, ontdekt dat er een virusuitbraak is die een bepaalde Java-call kan gebruiken om de hele telefoon te rooten en dat met een week waarschuwing publiceert.

Project Zero is geen PR-campagne puur omdat het ook naar andere bedrijven kijkt. Het is gratis onderzoek dat men anders toch wel uitvoert, maar nu worden de resultaten niet op de zwarte markt verkocht.

[Chinco]

Het aantal onthullingen en de manier waarop Google dit doet geven geen reden voor jouw rooskleurige bril. Misschien omdat je het schildje Google hebt dat je bril sowieso wat roze is richting Google, maar een gat ontdekken, de tools ontwikkelen en beschrijven en dan maar 7 dagen de tijd geven terwijl over 2 weken een patch komt? Sorry hoor, daar is niets liefs aan. En het is niet de eerste keer dat dit gebeurd.

Het geeft echter niet, het is voor mij flinke anti-google reclame. Dus áls ze wat bereiken, is het dat. En gezien de inhoud van de reacties ben ik niet de enige.

[GertMenkel]

Twee weken voor een fix praktisch ter grootte van "if (integer > 65535){SetLastError(INVALID_ARGUMENT); return - 1;" die niet eens het gedrag van de functie aanpast? Ik heb kortere deadlines voor grotere bugs gehad.

Drie weken nodig hebben over het oplossen van een integer overflow is toch wel behoorlijke anti-Microsoftreclame vind ik zelf.

Ik heb geen idee waar dat Google-schildje vandaan komt want ik heb een hekel aan de meeste dingen die Google doet. Ik vind ze op veel vlakken beter dan Microsoft, maar dat is zoiets als Stalin en Mao vergelijken. Beter betekent niet goed.

Binnen Google gaan stemmen op om alle algemeen misbruikte exploits direct openbaar te maken bij vinden zodat niet alleen de criminelen de kennis hebben maar de verdedigende kant ook. Wees blij dat die de dienst niet uitmaken.

[enigmafan]

Twee weken voor een fix praktisch ter grootte van "if (integer > 65535){SetLastError(INVALID_ARGUMENT); return - 1;" die niet eens het gedrag van de functie aanpast? Ik heb kortere deadlines voor grotere bugs gehad.

Er komt dan een tester en die geeft aan dat er nog een foutsituatie is en moet de code aangepast worden naar:
"if ((integer > 65535) || (integer < 0)){SetLastError(INVALID_ARGUMENT); return - 1;"
Dan ben je toch alweer een paar uur verder.
En bij Microsoft is er wel een iets langer (automatisch) testtraject dan bij het gemiddelde stukje software.

[petehbehot]

Om nog maar te zwijgen over de prioritering... Gaat de developer aan de slag met deze local exploit, of toch met die andere remote exploit die men net gevonden had..? Die leuke illusie die men vaak heeft dat developers eindeloos opgeschaald kunnen worden om alle problemen tegelijk op te lossen...

Met een 7-day lead voor een low urgency bug zet je de andere partij nodeloos onder druk. En als die partij toevallig een concurrent is, komt dat natuurlijk niet bijster chique over.

[T.C]

Om nog maar te zwijgen over de prioritering... Gaat de developer aan de slag met deze local exploit, of toch met die andere remote exploit die men net gevonden had..? Die leuke illusie die men vaak heeft dat developers eindeloos opgeschaald kunnen worden om alle problemen tegelijk op te lossen...

Met een 7-day lead voor een low urgency bug zet je de andere partij nodeloos onder druk. En als die partij toevallig een concurrent is, komt dat natuurlijk niet bijster chique over.

Als Microsoft gevoel voor humor heeft, geven ze Google in een vergelijkbare situatie een deadline van 7 uur (op Thanksgiving)
Want zeer kritische lokale bug.

[aikebah]

Dat zou niet pas door de tester moeten worden gevonden, maar al door de peer-reviewer. Dat scheelt weer een paar uurtjes.

[Chinco]

Daar gaat het niet om. Het gaat erom dat Google afwijkt van de zelf opgelegde termijn zonder een goede reden. De remote exploit variant was al gedicht en met fysieke toegang komt je TOCH wel in een pc.

Dat jij vindt dat het makkelijk opgelost kan worden en dus NU een patch uit moet komen, betekent niet dat Microsoft daar ook zo over hoeft te denken. Zelfs al zou jij meer weten over wat er aan de achterkant gebeurd. Misschien is het team op dit moment wel druk met een veel ernstiger, omvangrijker lek waar ze het lek niet boven krijgen. Weet jij veel? Het is altijd zo makkelijk roepen vanaf de zijlijn.

[GertMenkel]

De zelf opgelegde termijn van project zero is alleen 90 dagen als er geen exploitatie in het wild voorkomt. Ze hebben zich keurig aan hun standaardtermijn gehouden hier.

[latka]

Die 7 dagen (en 90 dagen) gelden voor iedere bug en iedere vendor. Dat MS het niet kan en systeembeheerder graag gepland updates willen inroosteren trekken hackers zich ook weinig van aan. Ben geen fan van google in de breede zin, maar het sponsoren van project zero is een van de betere initiatieven. Voorheen deden vendoren er maanden over om iets te fixen en gingen ze de discussie met de onderzoeker aan of ze niet nog een paar maanden uitstel konden krijgen voordat er gepubliceerd zou worden. Na een aantal akkefiets is voor iedereen het spel duidelijk: heb je een lek: 90 dagen, heb je een lek wat misbruikt wordt: 7 dagen geen mitsen en geen maren.

[Chinco]

Maar welk bewijs is er dan dat het misbruikt wordt? Hoe KAN Google dat weten? Welke telemetrische gegegevens hebben ze? Of doen ze stiekem meer met de services die ze op de pc's installeren dan dat wij weten en kunnen ze het daarom niet publiceren?

En dan ook nog eens publiceren op een versie die bijna niet meer ondersteund wordt. Waarom niet laten zien met de 2004 of 2009?

Zoveel vragen...

Het spijt me, ik kan niet uitgaan van hun goede wil. Al helemaal niet omdat dit niet de eerste keer is dat het motief niet geheel zuiver is of tenminste lijkt.

[GertMenkel]

Google onderzoek regelmatig exploit chains die Chrome treffen. Dat kunnen ze omdat Chrome on staat is een memory dump uit te voeren als de browser crasht, en dat is wat er doorgaans gebeurt zodra er een browser exploit wordt uitgevoerd. Van alle telemetry die Google verzamelt is een crashdump nou een van de weinige dingen waarvan ik denk dat Google er wel iets daadwerkelijk nuttigs mee kan. Iedere browser verzamelt die dumps trouwens, inclusief Firefox als je de optie niet uitschakelt. De meeste mensen kijken niet eens naar de instellingen dus dan krijgt Google wel vaker exploits binnen.

[GertMenkel]

Het artikel meldt dat de exploit onderdeel is van een exploit chain die gebruikt wordt in combinatie met een exploit in Chromium.

Google heeft waarschijnlijk een exploit kit gevonden die vanuit Chromium code execution en een sandbox escape mogelijk maken met daarop volgend een escalation of privilege. De Chromium bugs hebben ze zelf al gerepareerd, maar de exploit chain bevatte ook nog code die Windows exploit. Ze hadden het kunnen negeren en kunnen roepen "niet ons probleem", nu hebben ze MS op de hoogte gesteld.

Het bewijs dat de exploit misbruikt wordt is dat de exploit chain die ze zelf ontvangen/gevonden hebben de exploit bevat. Dat wil niet zeggen dat ze een specifieke kit hebben gevonden of gekregen of dat ze een exploit gekocht hebben; de exploits kunnen net zo goed uit een memory dump van een gecrasht Chrome-proces komen als onderdeel van de standaard bugrapportage. Dan weet Google niet wie wanneer hoe vaak waarvandaan aangevallen wordt, maar weten ze wel dat ergens een aanvaller dit misbruikt.

Voor praktisch iedere andere Windows bug geven ze MS gewoon 90 dagen, dus als ze nu maar 7 geven, hebben we gewoon daadwerkelijk bewijs. Ze hebben niks te winnen door van hun eigen protocollen af te wijken.

[Chinco]

Hmm, dat zou kunnen.

Waarom zouden ze dat dan niet vertoon vermelden?

(Kom heren en dames, zijn reactie is geen min 1 waard, dat is gewoon echt ontopic.)

[Chinco]

https://tweakers.net/nieu...gle+Windows+kwetsbaarheid

Lees de berichten van de afgelopen jaren eens door. Ook de commentaren. Sowieso heeft Google zelf verzonnen dat het 7 dagen is. Daarbij, een proof of concept erbij leveren, dan weet je zeker dat elke scriptkiddie het kan gaan misbruiken. Handig, joh!

Maar eerlijk gezegt denk ik dat ik nu paarlen voor de zwijnen werp omdat je het niet wilt zien.

[latka]

Als je de historie bekijkt op tweakers (en dat is maar een hele kleine samplesize van alles wat project zero publiceert) dan zie je dat ook Android lekken melden. Dus het verhaal met die motieven kan ik niet onderbouwen. Ja, hier zitten ook 7 dagen meldingen bij zonder een beschikbare patch voor alle toestellen. De eigen partners (Samsung e.d.) werden daar ook mooi te kakken gezet.

Dan die 7 dagen: als een lek actief gebruikt wordt moet je je afvragen of 90 dagen etisch verantwoord is. Los van het feit dat wat er dit maal gepubliceerd is niet bruikbaar is voor scriptkiddies aangezien een maar een onderdeel is van een complete aanval.

Imho, maar blijkbaar ben ik een zwijn, hoor ik het liefst zo snel mogelijk van een exploit die misbruikt wordt zodat ik eventueel mitigerende maatregelen kan treffen (firewall dicht zetten, bepaalde diensten uitzetten) om zo het actieve misbruik tegen te gaan.

Blijkbaar verschillen we van mening over het publicatiebeleid van Google en hoe vendoren hier mee om horen te gaan. Ik zit zelf in software development en soms moet je een spoedreparatie doen. Dat is nooit leuk. De codebases die ik onderhou zijn niet op de schaal van die van MS, maar de teams waar ik mee werk zijn dan ook vele malen kleiner. Ik heb nog nooit meegemaakt dat een patch niet binnen 24 uur klaar was. Soms niet de fraaiste oplossing, maar een workaround die je later alsnog goed repareert. Vanuit die optiek snap ik niet dat een bedrijf van de omvang van MS dit niet in een week kan: de hele infrastructuur voor het uitrollen hebben ze al. Als er potentieel regressies zijn dan kun je alsnog een optional update de deur uit doen. 7 dagen is echt genoeg voor lekken van dit formaat.

Een lek van de ordegrote Spectre is een ander verhaal. Maar hier heeft Google, in goed overleg, met alle betrokkenen meer dan 6 maanden aan gewerkt.

Op basis van wat ik zie/gelezen heb is 7 dagen voor een 0-day altijd terecht: een lek geheim houden maakt het niet beter. De 90 dagen policy lijkt mij altijd voldoende voor een software patch (en is onderhandelbaar met goede argumenten). Dus gooi vooral nog wat parels voor dit zwijn want ik zie werkelijk geen argumenten waarom 7 en 90 dagen niet goed genoeg zijn, maar wel vage insinuaties over motieven. Laten we het bij feiten houden aub.

[Chinco]

Dank voor je (nu wel) inhoudelijke antwoord. Daar kan ik wel wat mee. In ieder geval stof tot nadenken.

Thanks.

(En mag ik aannemen dat je snapte dat ik het spreekwoord gebruikte en niet jou als zwijn zie? 😉)

[raptorix]

Zo werkt dat niet in de software wereld, zeker niet op security gebied, dat is een vrij klein wereldje waar men elkaar nodig heeft. Daarnaast bedienen Microsoft en Google beiden een hele andere markt.

[GertMenkel]

Waarop is Microsoft een concurrent? Azure versus GCP misschien? Ik zou Bing geen concurrent van Google willen noemen en Chromebooks zijn nou ook niet bepaald een bedreiging voor Microsoft's grip op de markt. Op browservlak heeft Microsoft zich al gewonnen gegeven, evenals op telefoonvlak.

Google heeft niks te winnen hier, het is Microsoft die zijn zaken op orde moet brengen.

[KeesAlderlieste]

browservlak heeft Microsoft zich al gewonnen gegeven

Niet echt, zijn juist druk aan de weg aan 't timmeren met een betere browser dan Chrome, de nieuwe Edge

[GertMenkel]

Het blijft Chrome met een laagje. Ze hebben alle Google-troep eruit gehaald maar voor zover ik van anderen hoor blijven mensen gewoon Chrome installeren. Spartan en alle andere pogingen om een grote invloed op het web te hebben zijn helaas mislukt.

[Magic Power]

Als je de Chrome browser interessant vind, maar niets van Google moet hebben, is Chromium een betere oplossing. Het enigste wat Edge doet is de Google-bloat vervangen door Microsoft-bloat.

[GertMenkel]

Ik gebruik doorgaans vooral Firefox met Chromium als backup (Bromite op mijn telefoon) maar ik vind het lastigste dat zo de concurrentie weg is in de browsermarkt. Safari is nogal duur met de eis dat je een Apple device koopt en IE, Edge en Opera hebben nu hun implementaties weggegooid. Nu is Google net zo erg als Microsoft vroeger was met IE6 qua standaarden met als gevolg dat Firefox maar achter Google aan moet lopen als laatste echte onafhankelijke browser.

[KeesAlderlieste]

Edge krijg je vanzelf.. :-)
Die Google troep scheelt dan een slok op een borrel qua geheugen en snelheid. Verder ziet 't instellingen scherm er een heel stuk overzichtelijker uit.

[swhnld]

Kijk eens lineaire TV, kom je reclames tegen die Chromebooks promoten als zonder virussen of bugs. Directe concurrentie met Windows schermen wordt getoond, dus wel directe concurrentie.

Ook hebben beide office suites, cloud opslag, samenwerkingstools, zoekmachine, noem maar op.

[Lapjespoes]

"Ik zou X geen concurrent van Y willen noemen" terwijl het om dezelfde soort producten gaat. Het gaat per definitie om concurrentie, of je iets nu wel of niet als bedreiging beschouwd.

[Danneh93x]

Misschien een gekke vraag, maar wat zijn de consequenties als niet wordt voldaan aan het ultimatum?

[wildhagen]

Dan maakt Google de details van het lek bekend. Hackers en malware-schijvers kunnen deze details dan vervolgens weer gaan gebruiken om malware te maken die deze bug misbruikt. En daarmee dus gebruikers en bedrijfsnetwerken aanvallen.

Wat die malware doet kan natuurlijk van alles zijn. Van ransomware, tot opname in een botnet, uitvoeren van DDoS-attacks etc etc. Net wat de hacker/malware-schrijver zelf maar bedenkt.

[KeiFront]

Je vergeet wel een belangrijk detail.

Nu hebben de blue team (wij Systeembeheerders/Security team/...) de eerlijke kans om detecties te creëren en onze omgeving beter te beschermen.

De kans is zeer groot dat de details van de vulnerability al lang bekend zijn bij hackers/malware schrijvers aangezien de vulnerability al in het wild wordt gexploit. Volledige openbaarmaking zal in dit geval aanvallers en verdedigers dezelfde kansen geven en de Vendor dwingen om zo snel mogelijk de vulnerability te patchen.

[GoBieN-Be]

Google brengt wel geen bewijs van gebruik in het wild maar toont wel een PoC.
Dus nu zal het zeker snel in het wild gaan circuleren.

[Reactie gewijzigd door GoBieN-Be op 23 juli 2024 11:23]

[El_Bartholomew]

Google gaf aan dat deze al in het wild gebruikt wordt maar gaf geen voorbeeld...
Je weet nooit wel steekspel op juridische of politiek vlak zich afspeelt achter de schermen of bepaalde economische belangen die doorwegen.
Het kan ook een waarschuwing naar een bepaalde partij (overheid) die er misbruik van maakt zonder die bij naam te noemen.
Het blijft altijd raden naar de motivatie als dergelijke zaken zo naar buiten worden gebracht.

[Reactie gewijzigd door El_Bartholomew op 23 juli 2024 11:23]

[Relief2009]

Of ze liegen om Microsoft in een slecht daglicht te stellen.

[Verwijderd]

Het is niet de eerste keer dat Project Zero slechts 7 dagen aan Microsoft geeft om een lek te fixen. Kan me iig 1 ander geval herinneren, maar kunnen er ook meerdere al geweest zijn. GPZ is heel erg asociaal wat dat betreft.

[_Thanatos_]

Imho is 7 dagen echt véél te kort. Een termijn van 25-30 dagen ofzo lijkt me heel wat realistischer.

Zij hebben die 7 dagen vast ergens op gebaseerd. Geen idee waarop, maar ik ben wel benieuwd waar jij die 25-30 dagen op baseert.

[kodak]

Het project lijkt helemaal geen 7 day deadline te hebben. Het is standaard 90 dagen. Daarmee zou dus iemand maar wat verzonnen hebben om als deadline te stellen wat de betrouwbaarheid van het project of de researcher geen goef doet. Dit heeft meer weg van chanteren als ze spontaan de zorgvuldig gemaakte regels gaan aan passen om het volledig publiek te maken. Wat is dan het volgende als het een remote exploit is? 24 uur de tijd hebben of anders maar de gevolgen ondervinden?

[latka]

Nope, 7 dagen voor 0days in the wild: https://www.google.com/about/appsecurity/

[kodak]

Als dat ook voor project zero zou gelden dan ziet dat er niet best uit. Er was al discussie over de 90 dagen die er was maar 7 dagen is helemaal niet realistisch als je bedenkt dat veel software meer tijd kost om te ontwikkelen en testen door allerlei andere omstandigheden als kwaliteiteisen, vrije dagen mensen die ziek kunnen zijn, geen grote teams hebben enz. Google lijkt dus net te doen alsof hun standaard maar door anderen (inclusief gebruikers die last krijgen van malware die vaak gemaakt word na het bekend maken) geaccepteerd moet worden.

[latka]

Project zero aligneert aan de de google timelines (volgens de eigen policy). En 7 dagen is super realistisch als je een actieve 0day ziet. Denk je echt dat hackers je de tijd gaan geven om te patchen? Als je als bedrijf niet in 7 uur een fix de deur uit kunt rollen heb je denk ik een groter probleem. Wellicht is het dan beter als je software gaat maken die niet aan het internet hangt en dus lastiger te bereiken is. We willen een 24/7 economie en op zondagavond nog besluiten een BBQ te organiseren en daar alles voor te kunnen halen. Maar als het op software aankomt is het te moeilijk en te lastig en te duur om dat te willen. Alternatief is de webserver op zondag uit ;-) Zoals de SGP ook doet.

[Reactie gewijzigd door latka op 23 juli 2024 11:23]

[kodak]

Je kan wel vinden dat iemand maar binnen 7 dagen een patch kan leveren of anders een probleem zou hebben maar ondertussen is software vaak gemaakt voor heel veel platformen en versies, moet er ook aan kwaliteitseisen worden voldaan, is ook heel veel software die in vrije tijd is gemaakt door kleine groepjes die ondertussen nog meer doen en stellen gebruikers zich net zo goed afhankelijk van dat soort constructies. Dus als Google dan liever die software ontwikkelaars en de gebruikers geen keus geeft en anders nog meer problemen gaat veroorzaken dan mag als eerste naar Google en de researchers gekeken worden waarom ze zelf ook die problemen veroorzaken. Jou of de mening van Google wijzigt namelijk in die paar dagen niets aan al die omstandigheden bij de makers en klanten, maar zorgt er ondertussen wel voor dat ze door het in te korte tijd nog meer openbaar te maken dus vooral vele anderen met de problemen opzadelen. Terwijl google en de onderzoekers er verder geen enkele verantwoordelijkheid nemen voor de negatieve gevolgen. Dan is het erg makkelijk om iets te vinden wat 'goed' voor een ander zou zijn.

Natuurlijk is het van belang om rekening te houden dat een security bug al door criminelen in gebruik is. Maar er is ook van belang of dat daarmee werkelijk zoveel risico meer risico is dat het binnen enkele dagen maar opgelost moet worden. Beveiliging is niet een simpele kwestie van iemand heeft ontdekt dat je iets kan doen en dus heeft iedereen er heel veel risico door dat er maar onder grote druk een oplossing moet komen naar de wil van een researcher of groot bedrijf dat wel even voor de rest gaat bepalen wat goed voor ze is. Daarbij moet je bij het oplossen ook rekening houden dat de klanten tijd nodig hebben om de patch te testen en toe te passen. En dan is 7 dagen echt niet genoeg om en voor een patch te zorgen en te zorgen dat iedereen de patch heeft en dat alles stabiel is en er verder niets stuk gaat enz.

[Reactie gewijzigd door kodak op 23 juli 2024 11:23]

[aikebah]

Maar het is dan ook niet 'als jij niet binnen 7 dagen een patch uitbrengt gaan we publiceren', maar 'we publiceren uiterlijk over 7 dagen omdat we het reeds door hackers uitgebuit zien worden en dus systeembeheerders en security managers in staat willen stellen zich er tegen te verweren ook als jullie (nog) geen patch of advisory uit kunnen brengen'.

[kodak]

Het komt op het zelfde neer: ze zetten zowel de softwaremaker als klanten voor het blok. Het project en de researchers bepalen wel even wat er zal gebeuren, ongeacht of er een patch is. Een goed doel voor ogen hebben is geen verplichting, maar het is wel verboden om zomaar geen rekening te houden met de negatieve gevolgen voor anderen. Ook al is je intentie naar jou mening nog zo goed.

[Reactie gewijzigd door kodak op 23 juli 2024 11:23]

[aikebah]

Ik zou als ik verantwoordelijk was voor security eerder verbolgen zijn als project zero dit (actieve exploitatie gespot van een 0day) stil zou houden tot 10 november (er even van uitgaand dat die patch, conform de verwachtingen uitgesproken in het project zero ticket (vrijwel zeker een reflectie van vendor feedback van Microsoft), bij het setje van patch Tuesday zit.

Het is aan de security verantwoordelijke om te bepalen of er gewacht kan worden op de patch door Microsoft, of dat (bepaalde danwel alle) systemen met windows zo security-technisch cruciaal zijn dat additionele monitoring op het gebruik van de kernel cryptography driver ingeregeld moet worden.

[kodak]

Prima als jij verbolgen zou zijn als iemand iets niet groots bekend maakt, maar er zijn nog een paar miljard andere mensen op deze wereld die ook eisen en wensen hebben. Dan kan je wel eigenwijs gaan doen dat je het aan een ander ligt om rekening te houden met de nadelen maar dat is niet hoe een samenleving werkt en waarom iemand die iets doet ook zelf verantwoordelijkheid heeft. Het is ook aan een security verantwoordelijke van een softwarebedrijf of klanten om iets te bepalen, maar dat wil niet zeggen dat het project of de onderzoekers dus zelf geen verantwoordelijkheid hebben om rekening te houden met negatieve gevolgen. En normaal doe je dat bij vrijgeven door vooraf in goed gesprek te gaan met anderen om te zien wat redelijk is. Niet voor niets is het bij heel veel andere disclosure projecten dat de deadlines ruimer zijn. Het is niet realistisch om rekening met een paar problemen te houden die je als project of researcher en de rest te negeren.

[aikebah]

Tsja... de scheidslijn ligt wat mij betreft tussen 'exploits gespot in the wild' (korte disclosure tijd, aangezien de hacker/malware wereld dit probleem al kent en code beschikbaar heeft die er effectief misbruik van maakt') en 'exploit of mogelijke exploit ontdekt in security research' (lange disclosure tijd om een leverancier of community de tijd te geven zelf in relatieve rust een patch uit te brengen en te communiceren).

[Waah]

7 dagen, alle details etc en geen bewijs ....
Dit lijkt gewoon weer Microsoft pesten. Iets waar Google wel een historie mee heeft....

[Splorky]

Ik ben blij dat Microsoft dit niet doet bij Android. Windows laat apparaten na 2 jaar nog updaten zonder dat bijvoorbeeld Dell dit tegenhoudt. Dit zie je wel bij Android.

[Verwijderd]

Zeker voor een lek dat relatief low-risk is
privilege escalation Is niet low risk

[batjes]

Gaan we weer.

Google stelt dat het Microsoft zeven dagen de tijd heeft gegeven om deze kwetsbaarheid te verhelpen.

Wat? 7 hele dagen?

Intel kreeg een half jaar zonder gemorrel. Google heeft zijn eigen regels ook al een paar gebroken bij serieuze -al misbruikte- exploits als het hun eigen producten betreft. Maar dit is een directe concurrent. Zodra o.a Apple of Microsoft in het vizier komen, "regels zijn regels!!! geen uitzonderingen!".

The Register schrijft verder dat Microsoft wel aantekent dat de kwetsbaarheid in feite meevalt omdat deze onderdeel moet zijn van een keten van exploits. Het gaat om een lokale kwetsbaarheid, dus eerst moet een aanvaller lokale toegang krijgen tot een Windows-machine. De enige bekende schakel in de keten die dit mogelijk zou maken, een Chromium-kwetsbaarheid met aanduiding CVE-2020-15999, is eerder deze maand al verholpen.

Niet zo'n serieuze exploit als Google beweert en die laatste zin is best een mooie burn, van wie is Chromium ook al weer, die deze exploit -zoals momenteel bekend- mogelijk maakte?

[bskibinski]

Eens dat 7 dagen te kort is.

Maar chromium is "technisch gezien" niet "van Google", het is een open source project waar ook mensen aan werken die niet bij google horen.

Het is wel opgezet door Google, en die hebben dus zeker een grote vinger in de pap, maar Microsoft zal er tegenwoordig net zo goed aan ontwikkelen sinds hun nieuwe edge.

[michielRB]

Wie denk je dat de commits accepteert? Dat is niet jan-en-alleman. Daar heeft Google toch echt de touwtjes in handen.
Hier is overigens de officiele chromium repo, en ja die wordt beheerd door google: https://chromium.googlesource.com/chromium/src/

[svenk91]

Dat was een burn geweest als Edge niet op Chromium zou draaien. Microsoft geld nu zelfs als een van de grotere contributeurs aan de Chromium code base als ik het niet mis heb.

Dat laatste stukje klopt trouwens niet. Die exploit keten met Chromium was de enige bekende manier voor REMOTE based exploitation. Voor lokale toegang is het niet nodig. Ook als je al toegang hebt tot een systeem via bijv. malware, kan je die nu zo updaten dat hij van dit lek gebruik maakt. Daarom dus altijd ook voorzichtig zijn met programma's installeren die geen admin rechten willen, die kunnen zichzelf vrolijk updaten zodra er een exploit beschikbaar komt die hun rechten kan verhogen, zoals nu het geval lijkt

[latka]

Wat een FUD: https://googleprojectzero...ility-disclosure-faq.html
3 hele keren zijn ze de 90 of 7 dagen niet nagekomen. 1x MS, 1xIntel en 1xGoogle. Heb je meer voorbeelden?

En met een RDP sessie ben je behoorlijk lokaal en vatbaar. Leuk remote desktops, maar je attack surface is vele malen groter.

[Vexxon]

En hoe lang kreeg Google voor Stagefright? Veel langer dan 90 dagen

[_Thanatos_]

Gaan we weer.

[...]

Wat? 7 hele dagen?

Intel kreeg een half jaar zonder gemorrel. Google heeft zijn eigen regels ook al een paar gebroken bij serieuze -al misbruikte- exploits als het hun eigen producten betreft. Maar dit is een directe concurrent. Zodra o.a Apple of Microsoft in het vizier komen, "regels zijn regels!!! geen uitzonderingen!".

De ontdekker of klokkenluider van een kwetsbaarheid is vrij om zelf te bepalen hoe lang ze een partij de tijd geven om iets te doen. Daar zijn geen wetten of regels voor.

Daarbij vind ik het voldoende tijd. Microsoft is een bedrijf met HEEL VEEL mankracht, en ze hebben de mogelijk om NU bij IEDEREEN met hun windows een update te forceren.

[SinergyX]

Bewijs dat de kwetsbaarheid uitgebuit wordt, geeft Google niet.
die actief misbruikt wordt

Wat klopt hier niet...

[GertMenkel]

Volgens Microsoft is de exploit op zich niet heel bruikbaar en moet er een keten van exploits gebruikt worden om er wat mee te kunnen. Die keten die ze vonden bestaat onder andere uit een Chromium-exploit. Oftewel, Google fixt een exploit tegen hun software en laat Microsoft weten dat daar ook wat mis gaat. Als Google haar browser patch is Microsoft dus veilig.

[WhatsappHack]

Van remote aanvallen, niet lokaal; dus Microsoft moet alsnog patchen.

[GertMenkel]

Klopt, maar als iemand code execution heeft zijn er legio mogelijkheden om binnen te komen. Fixen moeten ze wel, maar het risico zit hem vooral in de exploit chain die gebruikt wordt (en die Google toevallig al gefixt heeft door Chromium te patchen).

De patch is nodig, maar voor eindgebruikers is de impact van deze bug minimaal. De meeste mensen hebben UAC toch praktisch uit staan (alles dat de schuif niet max zet voor UAC staat gebruikers toe UAC te bypassen) en loggen in als admin op hun eigen PC. Mensen die dat niet doen zijn doorgaans onderdeel van een bedrijf met een antivirus die deze keten vindt voor het misgaat nu er een PoC vrijgegeven is. Al met al is het een matig grote bug die niet heel praktisch uit te buiten meer valt.

[hackerhater]

Wat denk je van bedrijven?
local user => local admin of zelfs hoger.

Of als ze een andere manier naar binnen vinden via bijvoorbeeld Outlook of Office?
Zonder deze publicatie van Google is er best een kans dat anti-virus bedrijven er geen weet van hadden.
Nu zal het zeer waarschijnlijk inderdaad niet meer werken.

[Reactie gewijzigd door hackerhater op 23 juli 2024 11:23]

[WhatsappHack]

In welke zin? Ze zeggen dat het actief misbruikt wordt, maar geven geen bewijs. We weten dus niet of het daadwerkelijk actief misbruikt wordt, maar er hoeft niet perse iets niet te kloppen.

[Webaccess]

Zou iemand het onderstaande kunnen uitleggen
-> Een up-to-date Windows 10 build 1903, 64-bits
Build 1903 is 1,5 jaar oud. Een up-to-date Windows 10 build is in mijn ogen 2004 of 20H2.

Ik begrijp dat je Build 1903 kan updaten maar het lijkt geschreven te worden alsof het een groot probleem is maar ongeveer elke thuis PC met een internet verbinding draait standaard volgens mij als build 2004 of mogelijk 20H2.

[wildhagen]

Uptodate gaat in deze context over uptodate met security patches, niet zozeer de Windows-versie zelf. Build 1903 is nog steeds supported en krijgt dus gewoon dezelfde security fixes (waar relevant) als 1909 en 2004.

[pstalman]

nog geen 2 maanden toch (8 dec?)

[wildhagen]

Klopt, de support van 1903 wordt per 8 december beeindigd.

Maar de patch voor dit lek komt dus (vermoedelijk) met de komende Patch Tuesday op 10 november uit, en 1903 zal die dus ook gewoon nog netjes krijgen.

Ook de voorganger van 1903, versie 1809, zal deze patch nog krijgen. Die support is namelijk verlengd van mei 2020 tot november 2020, en krijgt deze dus nog mee. Zie nieuws: Microsoft verlengt ondersteuning Windows 10 October 2018 Update

Alleen 1803 (support gestopt per 12 november 2019) en nog ouder krijgen de patch dus vermoedelijk niet meer, hoewel het wel mogelijk is dat Microsoft deze eenmalig alsnog zal uitbrengen. Maargoed, dan heb je het inmiddels wel over heel oude versies natuurlijk.

[Xfade]

Microsoft says the only known remote-based attack chain for this vulnerability has been dealt with, a hole in Chromium-based browsers

Dus eigenljk moet het lokaal uitgevoerd worden, en is het risico dus zeer laag. Waarom dan 7 dagen. Of ik lees het verkeerd ofzo.

[latka]

7 dagen voor bugs die in gebruik zijn, 90 dagen voor bugs die alleen door de onderzoekers gevonden zijn.

[Verwijderd]

Je leest het goed. Het is gewoon marketing van een bug door Google.

[GeroldM]

Chromium (en daarmee dus Chrome) ligt als browser continu onder vuur van hackers/malware. Naar ik heb begrepen draait 90% van alle (Windows) gebruikers een op Chromium gebaseerde browser.

Dat is een wel heel grote groep. Vind het daarom niet zo vreemd dat er vanwege dit soort nummers strakkere periodes worden aangehouden.

Komt er ook nog eens bij: hoe makkelijk is de bug te fixen? Voor wie ooit in software-ontwikkeling heeft gewerkt, de ene bug is de andere niet. Sommigen zijn simpel op te lossen en snel door test-systemen te krijgen (unit- en/of andere vormen van regressie tests).

De melders van de bug en/of Google hebben wel enigzins een idee over de moeilijkheidsgraad van de bug en zijn misschien zelfs al zo vriendelijk geweest om voorbeeld code aan te leveren welke het probleem oplost. Kreeg ik niet mee uit het artikel, maar dit soort ervaring krijg je als je lang genoeg toegang hebt tot een code-base. Zelfs als deze code en test-omgevingen niet door jezelf zijn opgezet.

Is 7 dagen kort dag? Ja.
Maar is het te kort dag? Niet noodzakelijk en zou dat niet mogen zijn voor een toko als Microsoft, welke dit voor elkaar zou moeten krijgen in een paar uur, als de nood erom vraagt.

Het team erachter heeft al proof-of-concept software kunnen maken. Dat geeft ook inzicht in de manier hoe deze in het wild misbruikt word.

Overdrijft Google met hun bewijs of bagetelliseert Microsoft het probleem? Beide partijen hebben hun eigen belang en zijn daarom nou niet bepaald betrouwbaar, wanneer ze dit soort "spelletjes" spelen.

Is het verdacht dat Google zegt wel bewijs te hebben, maar dat niet toont? Is het verdacht dat Microsoft niet wil dat de eindgebruikers te panisch over eventuele verregaande consequenties worden en daarom het werkelijke probleem kleineert?

Zonder bewijs en code kan niemand een duidelijk beeld krijgen over de omvang en het gevaar. Echter is 7 dagen minder kort dag dan de meesten hier verkondigen. En, laten we eerlijk zijn, Microsoft heeft de laatste paar jaar genoeg updates uitgebracht welke niet goed zijn getest en voor een hoop ellende hebben gezorgd, terwijl deze updates langer dan 90 dagen door de mangel zijn gehaald.

De periode om te testen is duidelijk niet zo van belang bij Microsoft. Het nivo van testen is ook niet altijd zo hoog. Google heeft het probleem en proof-of-concept software bij Microsoft aangeleverd. 7 dagen voor een fix kan zelfs te vrijgevig van Google zijn geweest.

[GertMenkel]

Het gelinkte issue van Google laat een integer overflow zien. Kan gebeuren bij het casten in C, op zich geen slechte bug dus.

De fix, een if statement toevoegen, is ook niet zo bijster veel werk. Het gedrag van de functie wordt niet aangepast, dus testen zal ook wel meevallen. Ik vind voor deze bug zeven dagen helemaal niet zo'n probleem eigenlijk.

Als dit nou een security issue op protocolniveau was of als dit niet zou vereisen dat de aanvaller al code execution bereikt heeft, had ik mijn bedenkingen hier gehad, maar bij deze specifieke bug vind ik het allemaal wel meevallen.

Dit gezeur hoor je steeds als Project Zero iets vindt bij Microsoft, of het nou na 7 dagen of na 90 dagen wordt gereleased. Microsoft reageert traag op bugs, systeembeheerders zijn boos en geven dat af op degene die de bug vindt in plaats van op degene die te traag is met de oplossing. Dan nog hier en daar wat beschuldigingen van laster en zwartmaken want Google is kwaadaardig en wil Microsoft doormaken blablabla en je hebt de comment sectie wel weer compleet.

Als ik zo'n bug gevonden had, had ik hem aangegeven bij hrt rewards program van Microsoft en er geld voor gevangen. Dit scheelt Microsoft toch weer een paar duizend euro denk ik.

[SuperDre]

En omdat er zo'n grote groep gebruik maakt van daarop gebaseerde browsers (overigens zal het op andere OSsen niet heel anders zijn) maakt het dus logisch dat deze veel aandacht krijgt van hackers/malware.

[Tasminos]

Betekent dit dat alles met een hogere build dan 1903 de kwetsbaarheid niet heeft??

[wildhagen]

Nee, dat betekent het niet, of iig niet automatisch. Het is alleen niet getest op hogere versies dan 1903, zover nu bekend.

De kans is vrij groot dat het ook in 1909 en 2004 zal zitten, maar zekerheid zullen we pas hebben zodra Microsof hun eigen Security Bulletin uitbrengt. Daarin worden alle versies (iig die versies die nog in support zijn) benoemd die worden geraakt.

[CrashOne]

7 dagen. Dat is toch serieus veel te kort? Onverantwoordelijk om dit nu al met proof of concept online te zetten.

[dakathefox]

Zo op het eerste gezicht ziet het er anders niet bijster complex uit.

[iDennis3D]

De marketing specialisten van Google zijn weer op hun best. Begonnen met een lek in Chrome en zo onrealistisch verdraaien dat nu alle aandacht naar Microsoft gaat.

Het is natuurlijk super triest dat Google dit nu publiceert en MS maar 7 dagen de tijd geeft.

Dit heeft NIETS met bescherming van de devices te maken, het is allemaal domme Google marketing.

[TheMak]

Ik heb de indruk dat Google al langer wist van de bug (via hun eigen bug CVE-2020-15999). Ze hebben het op 21 oktober gepatched. Nadat ze zelf hun bug hebben gepatcht, en een nieuwe versie hebben gereleased, geven ze microsoft nog maar zeven dagen de tijd om hun bug te fixen. Ik krijg de indruk dat Google Microsoft eerder over de bug hadden kunnen informeren, maar misschien hebben ze dat ook gedaan.