Microsoft hekelt Google wegens publicatie Windows-lek
Microsoft heeft naar Google uitgehaald wegens het opnieuw publiceren van een lek in Windows 8.1 waarvoor nog geen beveiligingsupdate beschikbaar is. Via de kwetsbaarheid kan een aanvaller die al toegang tot de computer heeft zijn rechten verhogen. Het lek werd op 13 oktober aan Microsoft gerapporteerd. Aangezien de softwaregigant niet binnen 90 dagen met een patch kwam, besloot Google informatie over het lek automatisch te openbaren, tot onvrede van Microsoft. Onlangs onthulde Google ook al een soortgelijk probleem in Windows 8.1. Deze kwetsbaarheid werd op 30 september van vorig jaar aan Microsoft gerapporteerd.
Google heeft een speciaal team genaamd "Project Zero" dat naar kwetsbaarheden in allerlei software zoekt. In het geval van een lek worden de betreffende ontwikkelaars of leveranciers ingelicht en krijgen vervolgens drie maanden de tijd om het probleem op te lossen. Als er niet binnen de deadline een oplossing komt, wordt de bugmelding automatisch zichtbaar voor het publiek.
Principes
Microsoft had Google gevraagd om de details niet te openbaren, maar de zoekgigant gaf daar geen gehoor aan. "We hebben Google specifiek gevraagd om met ons samen te werken om klanten te beschermen door de details pas na 13 januari te openbaren, als we een update uitbrengen", zegt Chris Betz van Microsofts Trustworthy Computing. Hij heeft het gevoel dat het hier niet om principes gaat maar eerder een manier van Google om Microsoft te pakken te nemen, waarbij gebruikers mogelijk de gevolgen moeten dragen. "Wat goed is voor Google is niet altijd goed voor klanten. We vragen Google om de bescherming van gebruikers ons gezamenlijke doel te maken."
Volgens de softwaregigant is het belangrijk om kwetsbaarheden eerst aan een leverancier of ontwikkelaar te melden, zodat die de tijd krijgt een update te ontwikkelen. Tegenstanders zeggen dat lekken hierdoor niet tijdig worden gedicht, omdat leveranciers en ontwikkelaars daardoor teveel tijd voor een update nemen. In het geval van "full disclosure", waarbij de kwetsbaarheden direct openbaar worden gemaakt, zou er veel meer druk op een leverancier staan om actie te ondernemen en met een update te komen. Ook zouden gebruikers in afwachting op een update maatregelen kunnen nemen en zo toch beschermd zijn.
Betz laat echter weten dat de meeste gebruikers zelfs in het geval van full disclosure wachten op een update van de leverancier. Uit cijfers van Microsoft zou blijken dat lekken die gecoördineerd worden verholpen veel minder aanvallen krijgen te verduren voordat er een patch beschikbaar is, dan in het geval van full disclosure, waarbij cybercriminelen direct tot het aanvallen van gebruikers kunnen overgaan.
Betz erkent dat sommige leveranciers slecht op bugmeldingen reageren, maar dat het beschermen van klanten de prioriteit moet hebben. "Geen enkele software is perfect. Het wordt tenslotte allemaal door mensen gemaakt. Microsoft heeft een verantwoordelijkheid om in het belang van onze klanten te werken en beveiligingsproblemen snel op te lossen", gaat Betz verder. Volgens de Microsoftmedewerker is de kritiek op Google geen manier om de eigen verantwoordelijkheid te ontlopen. "Het is onze taak om de best mogelijke software te bouwen en zo goed mogelijk te beschermen."
En als je vindt dat je een verantwoordelijkheid hebt... neem die dan ook.
Voor wat betreft die 'best mogelijke software'... Laten we het er op houden dat ze of daar volledig niet in slagen of dat Microsoft en ik een heel andere definitie van 'goed' hebben...
Maar eerder staat er:
Dus er is een update klaar en men vraagt om een paar dagen te wachten met bekend maken, maar Google vind dat niet passend? Ben benieuwd hoe ze bij Google gaan reageren, wanneer bij een belangrijk produkt van hen zo'n situatie voorkomt. Gelet op wat ze hier doen, zouden ze zich dan stil moeten houden.
Verder weet google dondersgoed dat MS 1x per maand een patchronde heeft en hadden ze idd beter tot morgen kunnen wachten. De vorige patchronde was 70 dagen na googles publicatie.
Na morgen heeft MS geen excuus meer.
Maar er is ook echt wel wat te zeggen voor harde termijnen die niet onderhandelbaar zijn. Het openbaarmaken van lekken heeft een duidelijke functie: zonder publiciteitsdruk worden leveranciers laks. Een termijn inlassen tussen melden aan de leverancier en melden aan de rest van de wereld heeft een al even duidelijke functie: de leverancier heeft tijd nodig om het lek te dichten en publicatie vergroot de kans op misbruik. Het gevaar van onderhandelen over lekken is dat dat leveranciers weer laks kan maken.
Ik weet niet hoe Google aan die 90 dagen gekomen is, maar dit komt bij me op:
- Een leverancier krijgt 30 dagen om het lek te dichten.
- O, maar men hanteert tegenwoordig vaak een maandelijkse patch-cyclus. Ok, die ruimte geven we door er nog 30 dagen bij te doen.
- Dan blijkt men daar toch niet altijd aan te kunnen voldoen, dus geven we nog één keer 30 dagen respijt.
- Weet je wat, we maken daar gewoon voor iedereen 90 dagen van maar dan zijn die ook hard, zonder uitzonderingen. Eigenlijk moet het binnen 30 dagen geregeld zijn, 90 dagen moet echt meer dan genoeg zijn, zo'n lange termijn begint zelf al behoorlijk riskant te worden.
Over de hypocrisie gesproken die Google zou tonen door voor zichzelf een andere maat te hanteren: in mijn ogen is het net zo hypocriet dat Microsoft, met een verleden van met smerig spel concurrenten bestrijden (zie de antitrustzaken die ze verloren hebben, zie de standaardisatieoorlog over documentformaten), klaagt dat iemand geen rekening houdt met hun. Niet dat ze zich tegenwoordig niet netter lijken te gedragen, ze lijken zich positief te ontwikkelen en veel anderen zijn trouwens evenmin lieverdjes, maar het had ze goed gestaan om te zeggen dat ze het betreuren zo behandeld te worden maar dat ze niet in een positie zijn om Google iets kwalijk te nemen omdat ze zelf wel ergere dingen hebben geflikt in het verleden.
Je moet dit vervolgens echter wel waarmaken, als bekend wordt dat met die 90 dagen niet zo strikt omgegaan wordt, dan gaat heel het incentive direct ook verloren.
...
...
Automatically disclosing this vulnerability when a deadline is reached with absolutely zero context strikes me as incredibly irresponsible and I'd have expected a greater degree of care and maturity from a company like Google. My reading of the disclosure is that it's your average local privilege escalation vulnerability. That's bad and unfortunate, but it's also a fairly typical class of vulnerability, and not in the same class as those that keep people like me up at night patching servers. The sad reality is that these sort of vulnerabilities are a dime a dozen on Windows, and the situation on Linux is pretty comparable. But disclosing it with zero context strikes me as the wrong approach.
...
...
Een van de antwoorden van google in die thread:https://code.google.com/p/google-security-research/issues/detail?id=118#c25
...
...
On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security - it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face. By removing the ability of a vendor to withhold the details of security issues indefinitely, we give users the opportunity to react to vulnerabilities in a timely manner, and to exercise their power as a customer to request an expedited vendor response.
...
...
(Alles natuurlijk zo ge-copy-paste dat het in mijn straatje past :-))
Prima om elkaar scherp te houden. Alleen nog "collateral damage" de gewone gebruiker zien te vermijden.
Kan heel positief uitpakken de controleur/auditor is te vinden bij de concurrent. Eigen vlees keuren is niet de beste aanpak voor kwaliteit. Nu nog een paar kwaliteits-eisen voor dat process, die horen er bij.
90 dagen om een goed gedocumenteerd lek te patchen, lijkt me meer dan genoeg.
MS zou Google een bloemetje moeten sturen, als een ander hetzelfde lek had gevonden, was er ongetwijfeld iets met Vupen of kornuiten geregeld. En neem het iemand eens kwalijk, want deze actie van MS getuigd nu niet echt van respect.
Kortom, IMHO, iets met een ketel en een pot, die beide gitzwart zijn, maar waarbij de een toch net weer iets zwarter is dan de ander.
- Microsoft had deze bug überhaupt niet moeten introduceren
- Microsoft had deze bug zelf kunnen en moeten vinden
- Anderen dan Google kunnen deze bug ook vinden of al gevonden hebben (los van de publicatie van Google)
- Vanaf het moment dat Google medewerkers dit lek gevonden hebben, hebben steeds meer mensen er kennis van gekregen hetgeen de kans op uitlekken vergroot
- Windows 8.1 is momenteel het enige "Desktop" OS met volledige ondersteuning
Sinds het (kennelijk niet helemaal?) opheffen van de Trustworthy Computing Group is het updateproces van Microsoft een drama. Daarnaast kan ik me niet aan de indruk onttrekken dat Microsoft haar product Windows 8.1 al gevistaficeerd heeft (Microsoft term voor prullebakkeren) en er nog zo min mogelijk aan wil doen.
Frappant is, dat in dezelfde pagina als maboc hierboven noemt, meerdere mensen rapporteren (o.a. https://code.google.com/p/google-security-research/issues/detail?id=118#c7) dat deze bug niet reproduceerbaar is in prereleases van Windows 10.
Gewoon economische laksheid van Microsoft (dit niet de eerste keer). En dat meent zij zich te kunnen permitteren, want zakelijke gebruikers zijn er nauwelijks. En dus krijgt Google de schuld en zijn er nog naievelingen ook die zich daarachter scharen. Aandelen wellicht?
...
...
En dus krijgt Google de schuld en zijn er nog naievelingen ook die zich daarachter scharen. Aandelen wellicht?
(Daarnaast vind ik de term naïef ook nogal makkelijk aangenomen. Da's een fraaie retorische stijlvorm, om een ander in diskrediet te brengen, evenals de aandelen opmerking)
Mijn verbazing zit 'm vooral in het door Google zo rigide vasthouden aan de 90 dagen regel.
Daarnaast heb ik zelf zeer negatieve ervaringen met het MSRC, er wordt serieus niet normaal omgegaan met kwetsbaarheden en soms duurt het wel tot 10 maanden voordat je uberhaubt een inhoudelijk antwoord krijgt.
Kortom: NIET HUILEN Mickeysoft, grow up!
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
