Google-beveiligingsteam publiceert Windows-lek na uitblijven volledige patch

Googles Project Zero-beveiligingsteam heeft de details van een Windows-lek bekendgemaakt, omdat Microsoft te lang op zich liet wachten met het uitbrengen van een patch. Microsoft stelde vorige week zijn maandelijkse patch tuesday uit.

In een bericht legt Google-onderzoeker Mateusz Jurczyk uit dat het lek deel uitmaakte van een verzameling kwetsbaarheden die hij eerder al aan Microsoft had gemeld. Het bedrijf heeft in juni een patch voor de lekken uitgebracht, maar deze blijkt niet alle problemen verholpen te hebben. Het lek met kenmerk CVE-2017-0038 maakt het mogelijk voor een aanvaller om via emf-bestanden het geheugen uit te lezen. Dit kan via Internet Explorer en andere applicaties die gebruikmaken van de Graphics Device Interface.

De onderzoeker vraagt zich af of de patch vorige week had moeten uitkomen als onderdeel van patch tuesday. Microsoft liet weten dat het de patchronde had uitgesteld, omdat er op het laatste moment een probleem aan het licht kwam. Het gaf geen verdere details over de aard van het probleem. Doordat Microsoft patches voortaan bundelt, werden andere patches ook door het uitstel vertraagd. De release van de updates staat nu gepland op 14 maart, maakte het bedrijf bekend.

Het is niet de eerste keer dat het Google-team een kwetsbaarheid publiceert voordat Microsoft een patch heeft uitgebracht. Eind vorig jaar deed zich hetzelfde verschijnsel voor, waarop Microsoft met kritiek reageerde. Google zou met de beslissing te publiceren een risico voor gebruikers in het leven geroepen hebben. Het team hanteert een deadline van negentig dagen, waarna het overgaat tot publicatie van een lek.

Reacties (202)

[batjes]

Zucht, alweer.

As part of MS16-074, some of the bugs were indeed fixed, such as the EMR_STRETCHBLT record, which the original proof-of-concept image relied on

Een deel van de exploit is al gefixt.

I have confirmed that the vulnerability reproduces both locally in Internet Explorer, and remotely in Office Online, via a .docx document containing the specially crafted EMF file.

De exploit is ook nog eens van toepassing in een deprecated browser.

MS is al bezig met dit probleem en het zo publishen is gewoon totale onzin.
Dit is niet "het publiek helpen", dit is weer "microsoft op de hak nemen". Erg jammer weer Google. Want ja, MS had gewoon de patch tuesday moeten pushen ondanks problemen.

[Nas T]

Ik ben het niet met je eens. Het zou inderdaad over kunnen komen als Microsoft op de hak nemen, maar dit is wel een effectief middel om aandacht te vragen voor lekken.
Microsoft heeft, net als elk ander softwarebedrijf, er baat bij dat lekken zo lang mogelijk onbekend blijven. Dat verlaagt namelijk de noodzaak om deze lekken te dichten en dat betekent dat er minder kosten gemaakt worden.

Bedenk je dat je na een operatie een ziekenhuisbacterie hebt opgelopen waardoor je goed ziek bent en de huisarts doet het af als een flinke griep. Zo blijft het ziekenhuis vrijuit en leert niemand er iets van.

Als ik waar ik werk een fout maak, vind ik het normaal dat mijn collega's me daarop wijzen als ze het opmerken. Daar leer ik ook van. Omdat Microsoft toch wel een bepaalde verantwoordelijkheid draagt bij de beveiliging van hun software, vind ik dit ook terecht.
Zo vaak als lekken al lekken aan het licht komen, zo vaak heb ik het de afgelopen drie jaar nog niet gehoord. Dat komt ook doordat er zoveel aan het internet hangt, dat het simpelweg nodig is...

[batjes]

Ik ben het niet met je eens. Het zou inderdaad over kunnen komen als Microsoft op de hak nemen, maar dit is wel een effectief middel om aandacht te vragen voor lekken.

Ik zou het daarmee eens zijn als Microsoft laks omging met security (Hoe Google bv met Android omgaat). Maar dat is niet het geval. Aan deze melding werd door MS al gewerkt, een gedeeltelijke oplossing is al via patches naar buiten gekomen.

Publiceren is een goed pressiemiddel als de partij in kwestie uitblijft van alle vormen van communicatie en als er geen enkele indruk gewekt wordt dat er wat aan gedaan wordt.

Bedenk je dat je na een operatie een ziekenhuisbacterie hebt opgelopen waardoor je goed ziek bent en de huisarts doet het af als een flinke griep. Zo blijft het ziekenhuis vrijuit en leert niemand er iets van.

Risico's zul je altijd hebben. Maar om nu halsoverkop allerlei aanpassingen door te voeren in het ziekenhuis zonder dit grondig te onderzoeken en uitvoerig te testen, heb je straks honderden of duizenden mensen die ziek worden omdat er een foutje is gemaakt, of omdat de geboden oplossing niet genoeg soelaas bied.

Als ik waar ik werk een fout maak, vind ik het normaal dat mijn collega's me daarop wijzen als ze het opmerken. Daar leer ik ook van. Omdat Microsoft toch wel een bepaalde verantwoordelijkheid draagt bij de beveiliging van hun software, vind ik dit ook terecht.
Zo vaak als lekken al lekken aan het licht komen, zo vaak heb ik het de afgelopen drie jaar nog niet gehoord. Dat komt ook doordat er zoveel aan het internet hangt, dat het simpelweg nodig is...

Microsoft is op de fout/exploit geattendeerd, sterker nog. Microsoft heeft het probleem al deels verholpen. Google's proof of concept voor deze exploit werkt al enige tijd niet meer. En de kans is vrij groot dat de rest van de exploit gefixt zou worden in de afgelaste patch tuesday.

Je hoort het nu meer omdat er een politiek spel uitgevochten wordt.

[svenslootweg]

Ik zou het daarmee eens zijn als Microsoft laks omging met security (Hoe Google bv met Android omgaat). Maar dat is niet het geval.

Dat is hier wel het geval - Microsoft heeft het probleem immers niet genoeg geprioritiseerd om het in 90 dagen gefixt te krijgen (en dat is al een erg ruime deadline, die zelfs voor veelomvattende problemen makkelijk te halen valt).

Wat mij betreft dan ook een prima actie van Google; de regels zijn voor Microsoft precies hetzelfde als voor iedere andere vendor, en ze zorgen maar dat ze het binnen de deadline gefixt hebben, wat prima haalbaar is als je veiligheid belangrijk genoeg vindt.

Als ze treuzelen en/of op het proces proberen te besparen door het uit te stellen, dan moeten ze ook op de blaren zitten. Dat is niet Google's probleem.

Microsoft heeft het probleem al deels verholpen. Google's proof of concept voor deze exploit werkt al enige tijd niet meer.

Dan is er toch ook geen probleem? Of het resterende probleem is wel gevaarlijk, en dan hoort het na de deadline gepubliceerd te worden om zo een snellere patch af te dwingen, of het resterende probleem is niet gevaarlijk, en dan kan het publiceren op de deadline sowieso geen kwaad.

Publiceren is een goed pressiemiddel als de partij in kwestie uitblijft van alle vormen van communicatie en als er geen enkele indruk gewekt wordt dat er wat aan gedaan wordt.

Dit is een onzinnig beperkte blik van wat kwalificeert als "nalatig", en eentje die het wel erg makkelijk maakt voor vendors om een lulverhaal op te hangen en te besparen op beveiliging.

Waar trek je de grens tussen "doet er wel genoeg aan" en "doet er niet genoeg aan"? Dat is waarom de 90-dagen-deadline van Project Zero bestaat, en die heeft Microsoft simpelweg overschreden.

[OruBLMsFrl]

om het in 90 dagen gefixt te krijgen (en dat is al een erg ruime deadline, die zelfs voor veelomvattende problemen makkelijk te halen valt)

Dat is mij echt even veel te makkelijk vanuit de huiskamer bondscoach spelen zeg. De impactanalyse van mogelijke aanpassingen alleen al kan enorm zijn. Je raakt met die patch een miljard gebruikers en tientallen OS versies/varianten. Er zijn allerlei externen die ook nog eens jouw software gebruiken via allerlei API's. Ik zou daarmee die 90 dagen na melding echt niet zien als zijnde makkelijk te halen.

Security teams krijgen bovendien ook nog meer meldingen binnen dan die van Google alleen. Misschien verlies je al ergens tussen de 1-3 weken puur voordat een capabel team beschikbaar is, wil je niet een andere fix of analyse die in de maak is uit handen laten vallen.

Google moet zich niet onnodig in een positie plaatsen dat zij met een publieke schandpaal de prioriteit van bugfixes gaat bepalen voor anderen. Misschien heeft Microsoft daadwerkelijk ernstigere beveiligingsproblemen om aan te werken. Die deadlines moeten ook gehaald worden. Zelf maakt Google een potje van Android beveiliging en patch management, om vervolgens naar anderen te gaan wijzen in de hoop dat dat de publieke aandacht van de eigen problemen afleidt.

Google stelt zelf de eisen voor apparaten die gebruik maken van de Play Store. Daar kunnen ze prima voorwaarden op het gebied van beveiligingsupdates aan verbinden. Ze willen het alleen niet, beveiliging is immers geen vereiste voor het tonen van advertenties en onveilige apparaten uitsluiten betekent minder views. Vergeet nooit dat Google op advertenties leeft...

[svenslootweg]

Dat is mij echt even veel te makkelijk vanuit de huiskamer bondscoach spelen zeg. De impactanalyse van mogelijke aanpassingen alleen al kan enorm zijn. Je raakt met die patch een miljard gebruikers en tientallen OS versies/varianten. Er zijn allerlei externen die ook nog eens jouw software gebruiken via allerlei API's. Ik zou daarmee die 90 dagen na melding echt niet zien als zijnde makkelijk te halen.

Ik spreek vanuit het oogpunt van een ervaren softwareontwikkelaar, die zowel complexe patch-processen als bezuinigingen en slappe excuses van dichtbij heeft gezien, en zijn brood verdient met code reviews, beveiligingsaudits, enzovoorts.

Ja, 90 dagen is afdoende, ongeacht de complexiteit, ongeacht de grootte van de userbase, ongeacht het aantal vreemde configuraties. De enige factor is geld.

Security teams krijgen bovendien ook nog meer meldingen binnen dan die van Google alleen. Misschien verlies je al ergens tussen de 1-3 weken puur voordat een capabel team beschikbaar is, wil je niet een andere fix of analyse die in de maak is uit handen laten vallen.

En dit is waar het echte probleem ligt: budget. En het is precies waarom ik het onnozel vind om uitzonderingen te maken voor bedrijven als Microsoft. Als er geen capabel team beschikbaar, dan heeft Microsoft dus niet genoeg geinvesteerd in beveiliging, en dan mogen ze daar wat mij betreft keihard op afgerekend worden. Dit is echt geen excuus.

Google moet zich niet onnodig in een positie plaatsen dat zij met een publieke schandpaal de prioriteit van bugfixes gaat bepalen voor anderen.

Wie gaat het dan doen? De ervaring leert dat er simpelweg geen prioriteit achter patches gezet wordt als er geen stok achter de deur is, ook bij Microsoft. Dus wie is er wat jou betreft in een betere positie dan Google om dit af te dwingen?

isschien heeft Microsoft daadwerkelijk ernstigere beveiligingsproblemen om aan te werken. Die deadlines moeten ook gehaald worden.

Wederom: budget. Oplosbaar probleem. Of Microsoft bereid is om daarin te investeren is een heel andere discussie, maar daar heeft Google niets mee te maken, noch kunnen gebruikers daar de dupe van worden.

Zelf maakt Google een potje van Android beveiliging en patch management, om vervolgens naar anderen te gaan wijzen in de hoop dat dat de publieke aandacht van de eigen problemen afleidt.

Android heeft zelf zat problemen, maar dit riekt toch naar een conspiracy theory.

Op het moment dat Google bezwaar maakt tegen een harde deadline op een Android-lek, prima, dan gun ik je dat punt qua hypocrisie. Maar daar heb ik tot nog toe geen indicatie van gezien, en het heeft dan ook vrij weinig met dit geval te maken.

Google stelt zelf de eisen voor apparaten die gebruik maken van de Play Store. Daar kunnen ze prima voorwaarden op het gebied van beveiligingsupdates aan verbinden. Ze willen het alleen niet, beveiliging is immers geen vereiste voor het tonen van advertenties en onveilige apparaten uitsluiten betekent minder views. Vergeet nooit dat Google op advertenties leeft...

Dit is nog een stuk lastiger dan je het voorstelt.

EDIT: Om maar even duidelijk te zijn: ik vind absoluut dat Google nog heel wat problemen op heeft te lossen betreffende Android, en ik ben absoluut geen fan van Google an sich. Maar de situatie is simpelweg niet zoals je het hier voorstelt.

[Reactie gewijzigd door svenslootweg op 25 juli 2024 07:44]

[OruBLMsFrl]

Dus Android patchen is lastiger dan ik me voorstel doordat er veel verschillende hardware en drivers voor zijn (Windows ook trouwens), terwijl jij de ervaren developer alles kan patchen binnen 90 dagen met voldoende budget, merkwaardige tegenstelling.

Bij Google zeg ik budget vrijmaken voor ondersteuning en security patches in plaats van moddergooien met schone schijn. Ze weigeren soms domweg zeer actieve versies te patchen, waar Windows Phone en Vista nog altijd security patches krijgen ondanks een klein marktaandeel. Zie onder een concreet voorbeeld van waar het bij Google zelf misgaat, los van de vendor kernel change problematiek. Nu nog altijd 15% marktaandeel Android 4.3 en eerder. Waarin stel ik de situatie dan anders voor, onderbouwing genoeg lijkt me?
https://www.extremetech.c...to-patch-os-vulnerability

[svenslootweg]

Dus Android patchen is lastiger dan ik me voorstel doordat er veel verschillende hardware en drivers voor zijn (Windows ook trouwens), terwijl jij de ervaren developer alles kan patchen binnen 90 dagen met voldoende budget, merkwaardige tegenstelling.

Hier haal je een paar dingen door elkaar. Android wordt upstream doorgaans wel tijdig gepatcht, het zijn de telefoonfabrikanten die nalaten om de updates te pushen naar hun eigen devices.

Bovendien zijn het drivermodel (en de bijbehorende politieke spelletjes) geheel verschillend tussen Android en Windows; op Windows definieert Microsoft de API, en hebben driverbouwers het daar maar mee te schaften. Op Android wordt het OS doorgaans om de drivers heen gebouwd, omdat het uiteindelijk de telefoonfabrikanten zijn die de software installeren en updaten, en niet Google.

En natuurlijk is dat een probleem, en natuurlijk moet dat opgelost worden, maar dat is een lastig en tijdrovend proces voor een platform dat al zo wijdverbreid verbruikt wordt.

Ze weigeren soms domweg zeer actieve versies te patchen, waar Windows Phone en Vista nog altijd security patches krijgen ondanks een klein marktaandeel. Zie onder een concreet voorbeeld van waar het bij Google zelf misgaat, los van de vendor kernel change problematiek. Nu nog altijd 15% marktaandeel Android 4.3 en eerder. Waarin stel ik de situatie dan anders voor, onderbouwing genoeg lijkt me?

Wederom is dit een probleem van de telefoonfabrikanten (die daar ook absoluut op aangesproken mogen worden), en niet van Google.

Als een fabrikant een EOL-versie van Android gebruikt (wat naar mijn weten de enige versies zijn waar lekken niet gepatcht worden), dan kan Google daar vrij weinig aan doen, en is dat toch echt een probleem dat fabrikanten op moeten lossen.

(Mocht Google weigeren een patch uit te brengen voor een niet-EOL versie van Android, dan hoor ik het graag. Dat zou namelijk wel echt een probleem van Google zijn.)

[OruBLMsFrl]

Zie die link dus, in 2015 geen patch meer voor Android 4.3. Dat was veel te vroeg om EOL te claimen naar de gebruiksstatistieken van toen. Dat was echt Google, had niets met telefoonfabrikanten te maken. Hooguit dat die fabrikanten niet een upgrade naar 4.4 aanboden, maar dan slachtoffert Google de consument ten faveure van de telefoonfabrikanten. Er is ook niets verbeterd sindsdien op dit vlak lijkt het... maar gooi vooral Microsoft onder de bus die Vista nog supporten, grote klasse. Dat is ouder dan alle genoemde Android versies trouwens en pas over een paar maanden EOL!

[svenslootweg]

Zie die link dus, in 2015 geen patch meer voor Android 4.3. Dat was veel te vroeg om EOL te claimen naar de gebruiksstatistieken van toen.

Wanneer iets EOL gaat heeft helemaal niets met gebruiksstatistieken te maken. Het is andersom; zodra iets EOL is (omdat de support-periode is verlopen) behoort het niet meer gebruikt te worden.

Betreffende het specifieke geval van Android 4.3, is er blijkbaar aangegeven dat die versie niet meer ondersteund werd, en dat er dus geen patch voor uit zou komen - dit is een EOL-situatie, en daar zie ik an sich dus geen probleem mee.

Waar ik wel een probleem mee heb, is dat Google blijkbaar niet publiek aangeeft wanneer precies de EOL-datum voor Android-releases is (al vermoed ik dat telefoonfabrikanten dat wel te horen krijgen). Dat is dus wel iets wat Google zou moeten veranderen.

Hooguit dat die fabrikanten niet een upgrade naar 4.4 aanboden, maar dan slachtoffert Google de consument ten faveure van de telefoonfabrikanten.

Als 4.3 EOL was, dan zijn het de telefoonfabrikanten die verantwoordelijk zijn voor dat geintje, door geen upgrades aan te bieden naar een ondersteunde versie. Dat is niet Google's probleem.

maar gooi vooral Microsoft onder de bus die Vista nog supporten, grote klasse. Dat is ouder dan alle genoemde Android versies trouwens en pas over een paar maanden EOL!

Om redenen die ik hierboven ook al heb aangegeven (plus het feit dat desktop-OSes zo ongeveer uitontwikkeld zijn), kun je geen directe vergelijking trekken tussen Windows en Android.

[OruBLMsFrl]

Als een bedrijf zijn maatschappelijke verantwoordelijkheid neemt worden problemen voor grote groepen gebruikers opgelost. Prematuur zaken als End of Life bestempelen doet daar niets aan af. Je maakt een verder prima functionerend apparaat feitelijk risicovol in gebruik.

Dat beleid en het Project Zero beleid vullen elkaar uitstekend aan. Problemen elders leggen bij vendors/Microsoft. Maak dan gewoon die patch die honderd miljoen gebruikers nodig hebben. Kost alleen wat geld toch. Als ze echt niet zoveel versies kunnen ondersteunen dan moeten ze er misschien eens wat minder uitbrengen als ze zien dat de telefoonfabrikanten het tempo niet kunnen bijbenen.

Google kan van alles met Android als ze echt zouden willen, maar ze schuiven de ellende echter het meest gemakkelijk op de consument af.

Tot slot: Windows Phone is er ook nog, niet alleen een desktop OS. Windows XP was ook EOL, maar kreeg 3 jaar langer updates vanwege het grote marktaandeel. Zo doe je dat.

[Anoniem: 663905]

Sorry hoor, maar enkel een budget verhogen lost niet ineens problemen op. Jij stelt dat als er meer poppetjes nodig zijn dat je deze met een groter budget kan regelen (want het is tenslotte zo veel werk). Dit kan goed gaan tot een bepaald niveau, want anders zou je wel duizend man een dag aan het werk kunnen zetten en klaar zijn.

Daarbij is het niet alleen Microsoft die ze schaden, maar vooral gebruikers. Wel een beetje vervelend als jouw bankrekening geplunderd zou worden omdat Google bepaalt dat het nu toch maar eens opgelost had moeten zijn.

Uiteraard ben ik het wel eens dat Google Microsoft publiekelijk erop mag attenderen, maar dat het de inhoudelijke informatie voor zich dient te houden. Wellicht zou je nog zelfs een rechtzaak tegen Google kunnen starten omdat zij jou willens en wetens digitaal in gevaar brengen?

[svenslootweg]

Sorry hoor, maar enkel een budget verhogen lost niet ineens problemen op. Jij stelt dat als er meer poppetjes nodig zijn dat je deze met een groter budget kan regelen (want het is tenslotte zo veel werk). Dit kan goed gaan tot een bepaald niveau, want anders zou je wel duizend man een dag aan het werk kunnen zetten en klaar zijn.

Dat is absoluut mogelijk voor het oplossen van beveiligingsproblemen, mits je een goed georganiseerd proces hebt, waar de patch-teams toegang hebben tot de originele ontwikkelaars, enzovoorts.

Het zou natuurlijk wat anders zijn als het ging over het implementeren van nieuwe dingen; dan heb je doorgaans een 'architect' nodig, en werkt een grote groep ontwikkelaars inderdaad alleen maar tegen.

Het patchen van beveiligingslekken (en testen van die patches) is echter een sterk paralleliseerbaar proces.

Daarbij is het niet alleen Microsoft die ze schaden, maar vooral gebruikers. Wel een beetje vervelend als jouw bankrekening geplunderd zou worden omdat Google bepaalt dat het nu toch maar eens opgelost had moeten zijn.

Ja ho even, hier leg je de schuld toch echt bij de verkeerde partij. Die schade wordt niet veroorzaakt door de melder; hij wordt veroorzaakt door de bouwer (Microsoft dus), en dat wordt alleen maar verergerd door het niet tijdig op te lossen.

De (al dan niet publieke) melder van een lek de schuld gaan geven is totale onzin, en een typisch geval van "shooting the messenger".

Het lek bestond ook zonder de publicatie al, en die publicatie is echt niet noodzakelijk om het lek misbruikt te laten worden; een beetje georganiseerde crimineel heeft z'n eigen team wel om dit soort lekken te vinden en misbruiken.

Sterker nog, het niet publiceren laat de betreffende crimineel vrolijk in stilte zijn gang gaan, omdat niemand weet dat het lek bestaat. Dit is waarom disclosure zo belangrijk is.

Uiteraard ben ik het wel eens dat Google Microsoft publiekelijk erop mag attenderen, maar dat het de inhoudelijke informatie voor zich dient te houden. Wellicht zou je nog zelfs een rechtzaak tegen Google kunnen starten omdat zij jou willens en wetens digitaal in gevaar brengen?

Zullen we dan maar beginnen met een rechtszaak tegen Microsoft? Die hebben immers het lek veroorzaakt en niet tijdig opgelost. Het is echt van de zotten om de melder dan te gaan vervolgen.

[Reactie gewijzigd door svenslootweg op 25 juli 2024 07:44]

[tweaknico]

Je kan er ook van uitgaan dat de "Bad-Guys" (tm) ook het eerste rapport gelezen hebben (als ze het al niet eerder wisten), en dat die ook verder zijn gaan zoeken.

Stil houden is uiteindelijk geen optie. Bij mijn weten kun je ook meer tijd krijgen om het te fixen maar dan moet er overleg over zijn.

[D11]

Wat vind jij voldoende tijd voordat je een beveiligingslek bekend maakt?

[batjes]

Dat is echt afhankelijk van het type exploit en het effect die dit heeft.

Hoe dan ook, het is niet aan Google om dit voor anderen te bepalen.

[D11]

Wie moet dit dan wel bepalen?

[batjes]

Microsoft zelf?

Microsoft gaat wat dat betreft best goed om met de security van hun OS en hun producten. Ze hebben het beste inzage in hun producten en hoe deze ge- of misbruikt worden. Google kan niet voor Microsoft bepalen hoe lang het mag duren. Exploits deftig fixen kan soms echt pittig werk zijn, en dat kan gewoon tijd kosten. We hebben het hier niet over 1 of ander stukje software van maar duizend regels. Maar een uiterst complex OS.

[kvdveer]

[quote]

Wie moet dit dan wel bepalen?

Microsoft zelf?[quote]

Het gaat er hier om dat Microsoft haar verantwoordelijkheid niet (geheel) neemt, dus zij kunnen dat kennelijk niet bepalen. Het is IMHO redelijk om dan terug te vallen op de industrie standaard (responsible disclosure), en die standaard noemt 90 dagen als een redelijke termijn.

[CivLord]

Wie zegt dat Microsoft haar verantwoordelijkheid niet neemt? Niet elke exploit wordt veroorzaakt door een verkeerde komma in de broncode, die in een paar minuten gefixt kan worden. Soms is het een onbedoelde bijwerking van een hoofdtaak van het programma, die een gedeeltelijk herschrijven nodig maakt; uiteraard zonder de bedoelde werking te beïnvloeden. Dan kan 90 dagen (inclusief testen) zomaar erg kort zijn.

[WillySis]

Drie maanden kunnen kort zijn, maar voor serieuze beveiligingslekken is het nog aan de lange kant. Wat men bij Google vindt kunnen anderen ook vinden.

In het algemeen vind ik dat men stuk depreciated software niet oneindig hoeft te patchen, mits men bij het starten een melding geeft dat het gebruik beveiligingsrisico's met zich mee kan brengen en dat men beter kan updaten naar de nieuwste versie.
Een jaar of twee na het uitkomen van een nieuwe versie (gratis misschien een jaartje korter dure software een jaartje langer) moet men oude versies toch definitief vaarwel kunnen zeggen.

[CivLord]

Klopt. Wat Google heeft gevonden kan iedereen vinden die er naar zoekt. Maar nu weet iedereen het en kan iedereen het gebruiken, en dat is een groot verschil.

[mikesmit]

Het enige antwoord wat Microsoft hierop kan geven is een gigantisch team zetten op het zoeken van exploits bij Google en vervolgens dezelfde tactieken toepassen als google bij hun doet

[BikkelZ]

Android is al een zootje op het gebied van security, waarom zou Microsoft ineens hypocriet moeten gaan doen en een spelletje "ja nee maar hullie!" doen?

Volgens mij is 80% van alle Android devices in gebruik niet gepatcht voor een of meerdere ernstige beveiligingslekken. Als mensen dáár nog niet van wakker liggen dan heeft verdere actie vanuit Microsoft ook geen zin en werkt alleen maar contraproductief. De 20% betreft toestellen nieuwer dan een jaar en met een beetje mazzel, Pixel/Nexus toestellen of toestellen die onderhouden worden door Tweakers.

[mikesmit]

Mijn punt is meer dat Google momenteel puur alleen energie in de bugs van Microsoft steekt voor slechte pr voor Microsoft. Ze kunnen beter hun eigen problemen gaan oplossen

[gday]

Google steekt alleen energie in bugs van Microsoft? Heb je daar een bron van, of verzin je maar wat zonder dat je je er enigszins in verdiept? (Ik vermoed het laatste.)

Hoe verklaar je bijvoorbeeld dat dit team van Google ook bijv fouten heeft gevonden in software van Symantec?
http://fortune.com/2016/06/29/symantec-norton-vulnerability/
Of bijvoorbeeld fouten in software van Apple?
https://threatpost.com/un...-zero-disclosures/110605/

[Reactie gewijzigd door gday op 25 juli 2024 07:44]

[BikkelZ]

Klopt maar Android heeft de negatieve aandacht van Microsoft niet nodig en het straalt alleen maar negatief af. Kijk wat voor een reacties Google iedere keer krijgt als ze zoiets doen.

[Nik Du Bois]

je kan je beter deftig informeren voor je mensen zwart maakt. Het google security team telt als een van de beste ter wereld, en ze testen enorm veel producten waaronder natuurlijk ook hun eigen producten.

Als microsoft Google problemen vind dan zal dit alleen maar in dank worden afgenomen door Google. Dit is niet een kwestie van mensen zwart maken, maar gewoon een van de fundamentele onderdelen van IT security volgens bijna gelijk welke security standaard die je kan terugvinden.

Problemen die gevonden worden moeten bekend gemaakt worden, liefst nadat ze zijn opgelost maar als dit niet/niet voldoende gebeurt dan is het bekendmaken belangrijker en beter dan het verstoppen. Onbekend in het grote publiek betekent niet dat er geen andere partijen de bug ook kennen en er al misbruik van maken.

[D11]

Het lijkt mij verstandiger als ze hun energie richten op hun eigen problemen.

[mikesmit]

Net als dat Google dat beter ook kan doen...

[D11]

Ze was in dit geval ook meervoud.

[TommyboyNL]

Aan wie is dit dan wel?

[Loller1]

Bekend maken en een werkende exploit de wereld ingooien zodat je direct iedereen kwetsbaar maakt zijn 2 totaal verschillende dingen. Daarbij is het gewoon onnozel om hier een tijdsduur op te plakken want dat verschilt gewoon van project tot project, hoe makkelijk hij op te lossen is en hoe belangrijk die bug is.

[Nik Du Bois]

1) de exploit is al partieel opgelost. Google geeft geen werkende 0 day exploit code vrij. Als de bugs al misbruikt worden zullen ze publiceren, maar de exploit code achterwege houden.
Je kan dan weer stellen dat de informatie/beschrijving van de bug genoeg is voor experts om dit te reproduceren en dat klopt, maar diezelfde experts kunnen ook zonder Google op de bugs komen dus dat is juist reden te meer om het bekend te maken.

2) het is nog meer onnozel om beveiligingsrisico's te laten bestaan en niet met de hoogste prioriteit op te lossen. Als de mensen van Google de bug konden vinden dan kunnen anderen dit ook. Responsible disclosure bestaat voor een reden. Als de bug van Microsoft niet belangrijk genoeg is om direct op te lossen, dan is het ook niet van belang om het later te publiceren? Ofwel is het belangrijk, ofwel niet.

[Reactie gewijzigd door Nik Du Bois op 25 juli 2024 07:44]

[Luxx]

Als Microsoft aangeeft dit op te lossen en helaas een patch een paar weken moet uitstellen, bereik je niets met publishen. In het verleden werden lekken wel een express stil gehouden en op de lange baan geschoven, dan kan publishen een mooi pressiemiddel zijn. De 90 dagen is totaal willekeurig, en als het een keer niet lukt... Is 110 dagen net zo goed(of eigenlijk 21%slechter, maar het blijft willekeur).

Ik ben voorstander van publishen van bedrijven die geen security beleid hebben, maar in dit geval...😐

[Armin]

Wat vind jij voldoende tijd voordat je een beveiligingslek bekend maakt?

Elke tijdsduur is arbitrair. Ik zou het liefst willen dat men geen vaste tijdsduren hanteerd maar naar de omstandigheden keek.

Mijn persoonlijke kritiek is dan ook niet dat Google het bekend maakt, maar dat men andere standaarden voor eigen producten handteerd dan die van de rest van de wereld. Als je een lek in een Google product bij Google meldt wordt er geen arbitraire datum aan geplakt dat het gfefixt moet worden en wordt het geheel niet openbaar gemaakt ongeacht of het gefixt is of niet.

Regels voor anderen, uitzonderingen voor jezelf.

[D11]

Ik was me hier niet van bewust. Heb je hier bronnen van?

Ondanks dat het dan misschien niet gepubliceerd wordt, worden de fouten wel opgelost binnen de 90 dagen?

[Armin]

Ondanks dat het dan misschien niet gepubliceerd wordt, worden de fouten wel opgelost binnen de 90 dagen?

Dat weet niemand, want Google publiceert niets. Dat is nu net mijn punt, regels voor anderen, uitzonderingen voor jezelf.

Overigens de bron is Google zelf. Zoek maar eens naar een bug in een Google product in haar eigen zero day database. Die zul je niet vinden

[D11]

Je weet dus niet of er een uitzondering is voor Google zelf.

[Armin]

Dat weet ik wel: er wordt immers niets gepubliceerd. Nooit niet! Voor alle andere bedrijven wordt het altijd gepubliceerd ongeacht of wel of niet gefixt is. Dat is de uitzondering.

En we weten daarnaast uit de mond van mensen die daadwerkelijk bugs gemeld hebben aan Google, dat ze inderdaad soms niet gefixt worden. Denk aan Android. Maar zelfs als ze altijd gefixt waren én ook altijd binnen hun arbitraire tijds-limiet was het nog een andere regel voor henzelf want men houdt de bugs onder de pet.

[D11]

Google verwacht toch niet van andere bedrijven dat ze erover publiceren?

[Armin]

Google verwacht toch niet van andere bedrijven dat ze erover publiceren?

Je mist het punt

1. Bug komt binnen
2. Is de bug in een Google product?
a. Nee. Melden na X dagen ongeacht of het gefixt is.
b. Ja. Nooit melden, ofwel onder de pet houden, ongeacht of het gefixt is.

Als je daar de hypocricie niet van inziet, ligt dat echt aan jou.

[D11]

Google heeft bepaalde regels waarop het omgaat met bugs. Op welke manier (ver)oordelen zij (over) een ander bedrijf dat niet conform hun eigen regels is?

Verwachten zij dat andere bedrijven publiceren over hun eigen bugs?

Heeft Google kritiek op mensen/instanties die 90 dagen na het melden bij Google een security issue publiceren?

Je kunt het met hun werkwijze oneens zijn, maar naar mijn idee zijn ze daarmee nog niet hypocriet.

[Croga]

Want ja, MS had gewoon de patch tuesday moeten pushen ondanks problemen.

JA MS had gewoon Patch Tuesday moeten pushen MET DIE PATCHES DIE NIET KAPOT ZIJN.

Het is ongelooflijk dat één probleem in één patch er voor zorgt dat er helemaal niets gepatched wordt. Klinkt een beetje als de jaren 80..... Als Spotify iedere dag een nieuwe release kan doen met wat op dat moment aan de kwaliteit voldoet, waarom kan MS dat dan niet? Waarom moeten die bij één probleem in één stuk code álle code die op dat moment klaar staat on hold zetten?

[batjes]

Omdat vaak het ene stukje code, afhankelijk is van een ander stukje code. Software is wat dat betreft soms echt enorm ingewikkeld. Het kan de combinatie van patches zijn die het probleem veroorzaken, of inderdaad, 1 enkele patch. Dit kost tijd en onderzoek.

Ik heb liever dat Microsoft gewoon zijn verantwoordelijkheid neemt en dan maar een patch tuesday aflast, dan gedeeltelijk pushen en dat straks mijn Windows naar de knoppen is.

Als de exploit actief misbruikt wordt (En Microsoft merkt dit doorgaans netjes), zal Microsoft de patch wel buiten de patch tuesdays rondes uitrollen.

[kidde]

Onzin, dat zou betekenen dat Windows emf nodig heeft om te kunnen werken, en dat emf diep in Windows verwerven zit, dat gelooft toch geen hond? Hoeveel mensen werken uberhaupt met die overbodige jaren 80 meuk?

Ik heb me helaas wel eens moeten verdiepen in emf, en het bestandsformaat is het ergste gedrocht waar ik ooit mee gewerkt heb. Als ik het me herinner een binair MS-only bestandsformaat, slecht gedocumenteerd nog ook. Screenshots van het beeld moeten nemen omdat omzetten met een scriptje niet werkte, na uren onderzoek. Het is bezopen en slecht ontwerp dat ondersteuning voor bestandsformaten niet modulair uitgeschakeld kan worden. Probleem in screensavers? Geen wezenlijk onderdeel van Windows dus schakel .scr tijdelijk uit totdat het opgelost is. Zelfde voor EMF. Maar nee, als een blaadje aan de kastanjeboom rot is, heeft de hele kastanjeboom er last van. Als .scr-bestandjes het besturingssysteem kunnen overnemen, loopt Windows bij iedereen weken lang gevaar.

[Argantonis]

[...]

JA MS had gewoon Patch Tuesday moeten pushen MET DIE PATCHES DIE NIET KAPOT ZIJN.

Het is ongelooflijk dat één probleem in één patch er voor zorgt dat er helemaal niets gepatched wordt. Klinkt een beetje als de jaren 80..... Als Spotify iedere dag een nieuwe release kan doen met wat op dat moment aan de kwaliteit voldoet, waarom kan MS dat dan niet? Waarom moeten die bij één probleem in één stuk code álle code die op dat moment klaar staat on hold zetten?

Je vergelijkt serieus een operating system wat tot op het laagste niveau allerlei configuraties en hardware moet ondersteunen en waarbij kapotte functionaliteit kan leiden tot mensen die totaal niet meer met hun pc kunnen werken met een muziekluisterprogramma?

[Croga]

Opvallend genoeg kan het bij Linux wel. En dat ondersteund ook tot op "het laagste niveau" allerlei configuraties en hardware (voornamelijk omdat daar die configuraties en hardware geen onderdeel zijn van de overweging door ze volledig los te koppelen van de kernel).

Het feit dat Microsoft keuzes maakt die er voor zorgen dat een lek ongedicht blijft betekend niet dat ze daar niet op aangesproken moeten worden. Uiteindelijk is de functionaliteit van belang en zou de doorslaggevende factor moeten zijn. Dat is het op dit moment niet; op dit moment is MS' proces de doorslaggevende factor.

[Argantonis]

Opvallend genoeg kan het bij Linux wel. En dat ondersteund ook tot op "het laagste niveau" allerlei configuraties en hardware (voornamelijk omdat daar die configuraties en hardware geen onderdeel zijn van de overweging door ze volledig los te koppelen van de kernel).

Het feit dat Microsoft keuzes maakt die er voor zorgen dat een lek ongedicht blijft betekend niet dat ze daar niet op aangesproken moeten worden. Uiteindelijk is de functionaliteit van belang en zou de doorslaggevende factor moeten zijn. Dat is het op dit moment niet; op dit moment is MS' proces de doorslaggevende factor.

Vergelijk dan Linux en Windows, dan heb je een punt. Niet met Spotify, wat in vergelijking een triviaal stuk software is. Het is niet zo dat bij Linux nooit wat mis gaat trouwens, maar uiteraard is daar wat meer de focus op security en net iets minder op de algehele user experience. Ook wordt verwacht dat gebruikers zelf wat dingen kunnen fixen als er eens wat mis gaat. Ik heb minimaal 2x gehad dat na een upgrade van een Linux distro (iig Ubuntu en iets in een ver verleden, Redhat of Suse) m'n hele OS niet meer bootte en ik zelf op zoek kon gaan naar een oplossing.

Uiteraard mag je Microsoft aanspreken op het niet dichten van een beveiligingslek en ik vind het ook een kwalijke zaak. Maar het is wel te begrijpen dat het wat complexer is in hun geval dan Spotify updaten of zelfs een Linux patch.

[Blokker_1999]

Maar dat gaat niet omdat dat niet getest is geweest. Snel een patch eruit halen introduceert nieuwe variabelen die weer enkele weken nodig hebben om alle testen goed te doorlopen. Zeker wanneer de problematische patch aanpassingen maakt die diep in het systeem zitten ga je die er niet zomaar uit tillen. Als dat al gaat met het huidige update mechanisme van Windows.

[FrankRicard]

Ja, Spotify is altijd supersnel met belangrijke updates:
nieuws: Spotify brengt update uit om issue van extreme schrijfbewerkingen op ...

[TRON]

De kans is aanwezig dat Spotify's code meer van elkaar is losgetrokken dan die van Windows. Daardoor gaat het bij Spotify makkelijker dan bij Windows.

[Tozz]

Als Microsoft zo veel tijd nodig heeft om een lek te dichten, dan is het risico dat de kwetsbaarheid in het wild wordt misbruikt groot.

Uiteindelijk is het beter als het bestaan van een kwetsbaarheid openbaar wordt gemaakt en dat Microsoft even moet bloeden, dan dat een kwetsbaarheid in het ' geheim ' wordt misbruikt door allerhande minder gure types (spammers, hackers, overheden, etc).

Het is te doen gebruikelijk dat een ontdekker van een kwetsbaarheid de leverancier van de software een deadline stelt om het te herstellen. Als Microsoft vervolgens zonder iets te laten weten niet een patch uitbrengt, dan is het te doen gebruikelijk om het lek te publiceren. Dat heet responsible disclosure. En 90 dagen is natuurlijk ook tijd zat. Dat is 3 maanden!

Nu is het Microsoft, maar als het een of andere kleine softwareboer was die niet reageert op z'n e-mail wanneer die wordt geinformeerd over een probleem had niemand hier een probleem van gemaakt.

[batjes]

Microsoft houd gemelde exploits in de gaten of deze actief in het wild misbruikt worden. Onder andere dankzij de telemetry data van Windows.

Actief misbruikte exploits krijgen een hogere prio en dan zal de ontwikkeling sneller gaan en als het nodig is pushed MS de patch wel buiten de dinsdagen. Het is niet aan Google, of aan ons, om te bepalen hoe snel Microsoft een gemelde exploit moet fixen.

3 maanden is niet eens zo bar veel tijd, het deftig ontwikkelen van een fix kan al bijna net zo lang duren... Laat staan het uitbundig testen. We weten niet hoe diep dit in het OS zit of hoeveel software dit eventueel kan slopen door het te quick en dirty te fixen.

We moeten niet willen dat Microsoft maar quick en dirty patches gaat uitrollen omdat Google druk uitoefend. Het is niet zo alsof Google een betere track record heeft betrekkende security vulnerabilities dan Microsoft. Microsoft doet het wat dat betreft vrij goed en het lijkt me beter als Microsoft zelf bepaald hoe ze met meldingen en patches om gaan, niet? Ze kennen hun OS en hoe deze gebruikt of misbruikt wordt beter dan wie dan ook.

Nu is het Microsoft, maar als het een of andere kleine softwareboer was die niet reageert op z'n e-mail wanneer die wordt geinformeerd over een probleem had niemand hier een probleem van gemaakt.

Google gebruikt Project Zero niet tegen kleine software boeren, als ik zo kijk, lijkt het speciaal voor Microsoft te zijn, alsof het een reactie is op Scroogled.

[Tourmaline]

Heb ik slecht nieuws voor je, telemetry kun je zo uitschakelen in Windows 10.

Een heleboel sites adviseren het zelfs.

[Reactie gewijzigd door Tourmaline op 25 juli 2024 07:44]

[Tozz]

Microsoft houd gemelde exploits in de gaten of deze actief in het wild misbruikt worden. Onder andere dankzij de telemetry data van Windows.

Dus dan ga je de put dempen als het kalf al verdronken is. In andere woorden: Dan is het al te laat.

Er is in de security wereld een soort van netiquette hoe om te gaan met het rapporteren van security bugs. Die stelt dat de leverancier een acceptabele tijd moet krijgen om te fixen, waarna een kwetsbaarheid openbaar gemaakt mag worden. 90 dagen is tijd zat. Dat zijn ook voor Microsoft 3 patch tuesdays die ze hebben laten liggen.

[batjes]

Het is altijd al te laat, er zijn ten aller tijde zero days in omloop waar MS, Google of Tweakers geen weet van heeft.

Het alternatief is lukraak maar patches pushen terwijl die nog niet uitbundig getest zijn waardoor er een boel systemen of software op hun gat gaat.

Het is een afweging, X procent systemen plat door de security flaw, of X procent systemen plat door een niet volledig geteste patch.

Google is zo'n beetje de enige die een fixed periode heeft. De overige zijn redelijk coulant en als men ziet dat MS er mee bezig is, schuiven ze de publicatie datum gewoon op.

Zelfs in Google's eigen melding staat bij dat MS er mee bezig is en dat een aantal van de problemen ondertussen al verholpen zijn. Het werkbare voorbeeld wat Google had, werkt ondertussen al niet meer en die put is al gedempt.

[SuperDre]

ja, echt, lekker mensen over de zeik jagen en onnodig bang maken terwijl dat het misschien maar op een hele kleine schaal misbruikt wordt. En misschien is het niet zo makkelijk om het probleem op te lossen zonder dat het invloed heeft op een hoop applicaties. 3 maanden is helemaal niet tijd zat, want jij hebt natuurlijk een goede inzicht op hun planning en jij hebt ook zeker perfecte inzicht wat er nu gefixed moet worden en wat daar weer dus de gevolgen van kunnen zijn.

[Anoniem: 55563]

Dit is het publiek wel helpen omdat het Microsoft wellicht motiveert om toekomstige lekken sneller te patchen. Daar is iedereen bij gebaat. Dat daarbij Microsoft onder druk wordt gezet vind ik minder belangrijk.

[rhuijben]

Ik kan alleen maar denken aan de oude "Do no evil."

[r2504]

Misschien moet men bij Microsoft ook maar alle lekken publiceren in Google z'n producten... nu ja, of ze gedicht worden maakt vaak zelfs niet uit omdat mensen gewoon geen updates krijgen op hun smartphone.

[Astrix]

Als Microsoft terug slaat, krijg je al gauw het zogenaamde modder gooien, ofwel een patchoorlog, tussen twee grootmachten, daar heeft niemand wat aan.

[matjojo]

als ze allebij gaan gooien met feature en safety-patches zeg ik geen nee om heel eerlijk te zijn.

[Astrix]

Dat zal misschien in het begin goed werken, maar naar verloop van tijd, na een aantal patch dinsdagen niet meer, dan is de nieuwigheid er vanaf, wanneer Google het vaker gaat doen bij Microsoft, krijg je al gauw irritatie vanuit de markt, zoiets van "daar heb je ze weer bij Google, hebben ze niet wat beters te melden, of te doen, dan Microsoft op de vingers te tikken." Dan gaan andere partijen, bedrijven op hun beurt weer Google bekritiseren over de kwetsbaarheid van Android en andere diensten. Concurrentie moet bestaan uit leveren van goede diensten,zeker niet elkaar over en weer, bekritiseren via de media, over wat goed en fout zou zijn bij de ander.

[Nik Du Bois]

juist wel. Iedereen zou dit moeten doen. Hoe meer problemen er gemeld en opgelost worden, hoe beter voor de eindgebruiker op het vlak van beveiliging.

[Astrix]

juist wel. Iedereen zou dit moeten doen. Hoe meer problemen er gemeld en opgelost worden, hoe beter voor de eindgebruiker op het vlak van beveiliging.

Iedereen zou het moeten doen, oké, belangeloze onafhankelijke partijen, maar zeker geen concurrerende partijen zoals Google, dat is zoiets als een slager die het vlees van zijn concurrerende collega keurt, en gaat bekritiseren.

[Nik Du Bois]

als de slager effectief gelijk heeft en kan bewijzen dat het vlees van de concurrent schadelijk kan zijn(denk dioxine) dan heb ik liefst dat hij het bekend maakt. Als de slager dit zou verzwijgen omdat de kans klein is dat er veel mensen ziek worden en dat vlees toch ooit vervangen zal worden dan vind ik het een groter probleem.

Als de 2e slager dan ook fouten vind bij slager 1 dan zijn we er als gebruikers alleen maar beter bij.

Fouten vinden bij jezelf/een ander is een goede zaak, geen schande voor in dit geval Microsoft. Fouten MOETEN bekend gemaakt worden. Dat is de reden achter alle momenteel bestaande security richtlijnen. Het idee dat fouten verzwegen moeten worden en de taboe daarrond zorgt juist dat dingen stagneren en op termijn fout lopen.

[Smuey]

Je krijgt een +2, maar je vergeet daarbij wel dat Google Android (waar je neem ik aan op doelt?) wel degelijk bijwerkt en patcht, maar de bedrijven die de telefoons maken simpelweg hun software niet updaten. Dit is deels een probleem van het model van Android, maar toch voornamelijk een punt voor de fabrikanten.

Overigens ben ik er 100% voor dat kwetsbaarheden in software openbaar moeten morgen gemaakt, ongeacht wie de software beheert.

[Glashelder]

Dit is deels een probleem van het model van Android, maar toch voornamelijk een punt voor de fabrikanten.

Vergeet je niet dat het Google is die dit model heeft verzonnen? Het is gewoon volledig te wijten aan Google.

[Smuey]

Niet mee eens. Google biedt gewoon aan alle fabrikanten dezelfde patches aan. Vervolgens is het aan de fabrikanten om die patches te verwerken en naar de telefoons te verspreiden. Dat is al vanaf het allerprilste begin zo geweest.

Overigens is het al een hele tijd zo dat écht kritiche problemen gewoon via Google Play service kunnen worden gepatcht, onafhankelijk van een tussenpartij, JUIST omdat de fabrikanten zo hard de bal hebben laten vallen.

[Maurits van Baerle]

Volgens mij kun je via Google Play alleen applicaties patchen. Een probleem in de kernel patchen via Play lijkt me erg stug.

[BikkelZ]

Niet mee eens. Google biedt gewoon aan alle fabrikanten dezelfde patches aan. Vervolgens is het aan de fabrikanten om die patches te verwerken en naar de telefoons te verspreiden. Dat is al vanaf het allerprilste begin zo geweest.

Gek genoeg hadden alle iPhones, Blackberries en Windows Phones (toch ook een multi-vendor platform!) daar nooit last van. Omdat de hele opzet van Android gewoon stuk is en dat is toch echt door Google zo gedaan.

Zo snel mogelijk een OS rushen en daarbij zo veel mogelijk de fabrikanten en telecomboeren paaien zonder naar de consument te kijken, om maar zo veel mogelijk advertentie inkomsten uit mobile te kunnen genereren.

[Nik Du Bois]

De reden dat er zo veel meer bugs gevonden worden is ook een groot deel doordat android open source is. Code die je kan lezen is makkelijker te kraken dan code die je moet reverse engineeren.

[BikkelZ]

Of Open Source wordt door hobbyisten geschreven die wat aankloten in hun vrije tijd terwijl closed source geschreven wordt door bedrijven met flinke budgetten en een reputatie die ze niet willen verliezen.

Aannames: altijd slecht.

Als iOS en Windows veiliger zijn doordat ze closed source zijn dan is closed source blijkbaar beter. Er zijn echt geen bergen geheime lekken in iOS anders betaalden ze niet zo veel voor 0-days.

Maar daar ligt het niet aan: Android moet gewoon veel beter worden qua updates en het probleem zit hem in de structuur van Android. Ik ben benieuwd hoe ze het gaan doen in Andromeda. Zou me niks verbazen als ze bij Google zo gauw dat volwassen is gewoon Android overboord kieperen en de API's in Andromeda kopiëren.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 07:44]

[tweaknico]

Probleem is dat fabrikanten een deel van de G-tools vervangen door eigen tools.
Als Google dan ALLES update ben je ook de Samsung shell etc. kwijt.

Het is dus aan de fabrikanten om hun toestellen van de juiste updates voorzien.

Een deel van de functionaliteit is niet makkelijk door fabrikanten aan te passen, dat zijn de delen die evt. door Google aangepast kunnen worden via de playstore.

[BikkelZ]

Geen enkel security gevoelig onderdeel zou door de fabrikant onderhouden moeten worden. Dat kunnen ze gewoon niet en ze verdienen er geen geld aan.

[tweaknico]

Eh ze verdienen aan het gebruik van het toestel en op het niet zelf hoeven te ontwikkelen van een compleet eco systeem.

Dat ontslaat ze niet van de verantwoording die er bij hoort. Het is eht gevolg van gebruik van software.

[BikkelZ]

Op een handje vol toestellen van slechts enkele fabrikanten wordt het goed gedaan, 80% van alle Android telefoons is gewoon slecht onderhouden bras. Verantwoordelijk of niet, geen enkele aandeelhouder wordt op korte termijn rijker van updates voor iets wat al verkocht is.

[tweaknico]

Wat mij betreft worden ze in de toekomst ook niet wijzer, door gebrek aan omzet voor nalatige leveranciers.

[Anoniem: 457607]

In het bedrijfsleven wordt onderscheid gemaakt tussen responsible en accountable. Google is niet responsible voor het patch probleem, maar is wel degelijk accountable.

[Glashelder]

Ja en dat idee is gewoon achterlijk. Dat het zo vanaf het begin is klopt en dat is precies wat ik met mijn post bedoel. Microsoft voert toch ook gewoon patches zelf door? Daar gaat het ook niet via de leverancier van je PC (indien van toepassing).

Google had patches gewoon vanaf het begin zelf uit moeten rollen, dan was er nu geen probleem geweest.

[Nerot1x]

Elk Windows systeem is ook hetzelfde, ik zie geen aangepast Samsung Windows die totaal anders is opgedeeld en andere beveiligingssystemen heeft. Elke Windows is hetzelfde dus dan is het makkelijk om alles door te patchen, niet te vergelijken dus met 1000 versies van Android.

[Glodenox]

Alleen had er dan vandaag geen Android geweest. De reden waarom Android zo groot is geworden was net omdat fabrikanten deze volledig naar hun eigen hand konden zetten en eigen apps konden toevoegen. Als ze allen hetzelfde operating systeem moesten installeren (wat een vereiste is om te kunnen patchen) had iedereen een apart platform opgebouwd.

[Wolfos]

Behalve dan dat de launcher + crapware geen onderdeel zijn van het OS maar losse apps. Het OS kan prima los daarvan geüpdated worden.

[Reactie gewijzigd door Wolfos op 25 juli 2024 07:44]

[rbr320]

Vergeet je niet dat het Google is die dit model heeft verzonnen? Het is gewoon volledig te wijten aan Google.

Dat ben ik niet met je eens. Het is vast ook mogelijk voor fabrikanten om hun devices direct door Google te laten updaten met de laatste patches voor Android. Ze kiezen hier echter niet voor omdat het dan lastiger wordt om hun eigen aanpassingen en meuk mee te leveren, al zullen ze het waarschijnlijk verantwoorden met het argument dat ze dan de kwaliteit niet meer kunnen waarborgen omdat ze niet elke patch kunnen testen.

Als jij een Nexus toestel hebt krijg jij gewoon alle updates direct van Google, zolang het toestel nog ondersteund wordt uiteraard.

[Glashelder]

Als Google het nou gewoon geforceert had dat beveiligingsupdates direct vanaf Google komen dan hadden fabrikanten geen keus gehad

[rbr320]

Dat is in de praktijk natuurlijk erg lastig omdat een beveiligingsupdate invloed zou kunnen hebben op andere delen van het systeem. Daarom loopt het uitrollen van patches via de fabrikanten van de telefoons, of je alles via Google.

[MadEgg]

Dan krijg je dus ofwel een telefoon met grote beveiligingsproblemen die niet (snel) opgelost worden omdat de fabrikant verzaakt de updates door te voeren naar hun klanten toe, ofwel een telefoon met geen grote beveiligingsproblemen maar wel problemen met de launcher of weet ik wat, omdat de beveiligingsupdate door Google aangeleverd wordt en de launcher door de fabrikant van het toestel.

Aangezien beveilgingsproblemen voor klanten vaak niet direct zichtbaar zijn en ze er dus niet zo zwaar aan zullen tillen, terwijl problemen met launchers of andere essentiële onderdelen van de UI wel direct waargenomen zullen worden en dus zwaarder opgenomen worden door klanten lijkt me die laatste aanpak veruit de beste: het dwingt de fabrikanten om snel hun software te updaten om ook op de gepatchte Android te kunnen werken.

Het is een onvergeeflijke ontwerpfout in Android geweest om patchen zo vrijblijvend over te laten aan de fabrikanten. Je ziet ook heel duidelijk waar Google's belangen zitten.

AOSP is open source en zou door elke fabrikant gebruikt kunnen worden zonder afhankelijkheid van Google. Dat is dan ook prima. Maar Google gaat fabrikanten vervolgens wel zo'n beetje dwingen om Google Play Services te installeren omdat gebruikers anders een groot deel van de apps uit de play store niet kunnen draaien, in combinatie met een bult andere Google Apps. Daar is de afhankelijkheid van Google dan weer terug.

Als het Google nou niet alleen om marktinvloed maar ook om de gebruiker ging, dan koppelen ze Google Play Services gelijk ook aan de versie van Android - Google Play Services werkt alleen op een goed gepatchte versie van Android.

Fabrikanten zijn laks en goedkoop, dus ze moeten wel voor het blok gezet worden om de boel goed te onderhouden, en daar heeft Google een zeer belangrijke rol in.

[halofreak1990]

Het is vast ook mogelijk voor fabrikanten om hun devices direct door Google te laten updaten met de laatste patches voor Android.

Nee, dat denk ik niet; veelal is voor dit soort devices de hele hardware support (drivers e.d.) in de kernel ingebouwd. Google kan dus niet zomaar een kernel update uitrollen zonder tussenkomst van de fabrikant. Microsoft heeft a) vaak een vaste set hardware, en b) de drivers zijn geen onderdeel van de kernel, dus zelfs als de fabrikant een exotische driver heeft, dan kan Microsoft de kernel gewoon updaten.

[Loller1]

Eerst en vooral is het online gooien van een exploit met werkende code op geen enkele manier goed te praten. Ten tweede is het niet alsof Google ieder lek dat men vind direct herstelt, zelfs niet binnen hun eigen artificiële tijdslimiet.

[Iblies]

Klopt niet wat je zegt.

Google/alphabet heeft namelijk een uniforme Android maar laat fabrikanten ook zelf de software aanpassen. Die kunnen ervoor kiezen om support voor bepaalde tijd te geven.

Verdienmodel van Android is gebaseerd op data van de gebruiker en wordt daarom praktisch voor niets weggegeven. Hoe het verder afloopt is secundair. Mede daarom vind ik het een rare actie van Google. Microsoft zou nu heel hard Android op de hak kunnen nemen.

Alleen verliezen dan alle fabrikanten. ICT wordt dan gewantrouwd.

[Smuey]

Maar in die gevallen waarin de software zo ver is aangepast, is Google dan toch niet eens partij meer? Nogmaals, ik vind het prima dat er openheid is over kwetsbaarheden in software. Ik ben het wel met je eens dat de fabrikanten van Android-toestellen dan collectief op hun muil gaan, want er zijn veel partijen die hier gewoon een potje van maken...

[batjes]

Dus, het is aan HP, Dell, Lenovo of whatever of onze Windows geupdate wordt of niet?

Google zou zijn verantwoordelijkheid eens moeten nemen, en niet het plaatje schetsen dat Microsoft zijn verantwoordelijkheid niet neemt.

[PostHEX]

Graag. Ik zie graag dat bedrijven elkaar onder druk zetten omtrent security. Hoe meer druk, hoe beter. In de AV wereld is het heel normaal om exploits (die door malware worden misbruikt) in producten of diensten te publiceren. Zie niet in waarom Google dat niet zou mogen. Nu had Google bij dit lek misschien langer moeten wachten gezien de omstandigheden, maar sommige mensen lopen al langer te zeiken dat Google überhaupt zoekt naar kwetsbaarheden bij concurrenten. Kwetsbaarheden die overigens ook mogelijk de werking van Googles producten en diensten kunnen aantasten (bijv. de invloed van anti-malware producten op Chrome). En laten we trouwens ook niet doen of dat MS heilig is: https://en.wikipedia.org/wiki/Scroogled

[Tweak3D]

Ik kan me niet aan de indruk onttrekken dat iemand hier wat erkenning nodig had. Ik snap wel dat de urgentie hierdoor een paar tandjes omhoog gaat, maar maak je nu geen slapende honden wakker? Of lopen onderzoekers achter de feiten aan omdat dit al lang bekend is in Exploiteria?

[phYzar]

Dat je geen geblaf hoort betekend niet dat de honden nog slapen Hoe langer je wacht hoe meer aannemelijk is dat derden het ook vinden en actief misbruiken. Dan is 90 dagen een ietwat arbitraire maar desondanks redelijke termijn om de boel te fixen. Vanaf dat moment lijkt het mij redelijk dat je potentieel slachtoffers (iedereen) waarschuwt welk risico ze lopen.

[Reactie gewijzigd door phYzar op 25 juli 2024 07:44]

[SuperDre]

Dan moet je er ook van uit gaan dat het lek al door anderen gevonden is, NU is het zeker dat het lek gevonden en misbruikt gaat worden.

[Tozz]

Dat weet je nooit. Nu heeft Google het lek _ook_ gevonden, maar wie zegt dat anderen dit lek niet al 5 jaar misbruiken? Of misschien heeft iemand hetzelfde probleem net na Google ook ontdekt. Je weet het gewoon niet, en daarom is het zo snel mogelijk patchen zo belangrijk.

[SuperDre]

Als men het al 5 jaar misbruikt dan is het blijkbaar niet zo'n groot probleem anders was het wel eerder naar boven gekomen, en nu weet je dus ZEKER dat mensen het lek vinden en gaan misbruiken.

[koelpasta]

Ja, en nu weten we ook zeker dat microsoft hier aandacht aan gaat geven....

[SuperDre]

Dat is nog steeds niet zeker, het kan dus ook zijn dat ze al veel aandacht er aan gaven, maar dat het dus diep in het systeem geworteld is dat het niet zo simpel te patchen is zonder dat dat gevolgen heeft voor veel software. Het is allemaal niet zo makkelijk als sommige tweakers denken.

[kikker81]

Dan weten de gebruikers nu in ieder geval dat ze een onveilig systeem gebruiken en kunnen ze zsm overstappen indien dat gewenst is.

[SuperDre]

overstappen naar wat? Linux is ook net zo onveilig, MacOS ook, elke OS heeft zo zijn problemen. Windows is al lang niet meer zo onveilig als 10 jaar geleden.

[kikker81]

Voor zover ik weet wordt er bij Linux niet zo lang gewacht met het patchen van bugs...
Microsoft heeft resources genoeg.

[SuperDre]

Nee, er wordt niet zo lang gewacht omdat daar het proces van release anders is, maar ook daar komt het vaak genoeg voor dat een schijnbaar simpele patch toch een hoop problemen geeft met andere bestaande software, puur omdat het niet voldoende getest is op verschillende systemen. Het patchen van een bug is vaak niet zo ingewikkeld, maar het inzichtelijk krijgen wat die patch voor bestaande software kan vernaggelen is wel een stuk ingewikkelder, en daar heeft een bedrijf zoals MS dus wel degelijk mee te maken.

[Koen1997]

Ik vind het nutteloos dat Microsoft 1 dag in de maand gebruikt om patchbundels uit te rollen. Maak er dan bijvoorbeeld een keer per week van. Op die manier heb je minder patches in 1x uit te rollen en kunnen ze vaker.

Nu vind ik 90 dagen ook wel heel lang. Microsoft lijkt zijn machtspositie te misbruiken ten nadelen van Google. Want als Google een lek heeft dichtten ze die blijkbaar direct. Of mijn laatste zin sarcastisch opgevat kan worden ligt volledig aan de lezer.

[Tozz]

Dat is verschil van visie. Die 1x per maand is juist bedacht om systeembeheerders het leven makkelijker te maken, zodat ze maar 1x per maand een set aan patches hoeven te testen i.p.v. elke week.

[the_shadow]

Nu is dat met WSUS natuurlijk eigenlijk al jaar en dag onzin. Wil je patches tegenhouden, dan kan dat met GPs, en/of je zet een WSUS server binnen je bedrijf om patches op te vangen, uit te rollen naar test machines en daarna richting productie. Dat kan je dan zelf nog steeds 1x per maand doen (je neemt de tweede dinsdag van de maand gewoon als cutoff voor je eigen cyclus), terwijl gewone consumenten wel dagelijks updates kunnen krijgen.

[TWyk]

Het uitrollen van patches kost met name in het bedrijfsleven geld vanwege bijvoorbeeld uitrol en testprocedures of het plannen van onbeschikbaarheid.
Het is dus niet evident om het aantal patchdagen te verviervoudigen.

[Lightning7]

Loop ik hierdoor nu risico doordat ik Chrome gebruik of ben ik gewoon veilig tot 14 maart?

[batjes]

De exploit is van toepassing op Internet Explorer.

[Evo94]

Zoals ik het begrijp uit het artikel is ieder programma dat gebruik maakt van GDI kwetsbaar. Ik heb even gekeken of Chrome GDI gebruikt maar het ziet er niet naar uit.

[Lightning7]

Haha dan voel ik me een stuk veiliger

[marco208]

Problemen of geen problemen, zoiets moet opgelost kunnen worden binnen 90 dagen. Als je er dan 3 maanden later achter komt dat je patch een probleempje heeft, moet je het niet weer een maand vooruit schuiven.

[Reactie gewijzigd door marco208 op 25 juli 2024 07:44]

[TWyk]

Als je er dan 3 maanden later achter komt dat je patch een probleempje heeft, moet je het niet weer een maand vooruit schuiven.

Wat een rare opmerking.
Als je iets vind in je patch wat een deel van je klanten met zekerheid schade zal doen dan ga je die toch niet releasen omdat er een nog niet gepubliceerde bug inzit waarover helemaal geen meldingen zijn dat er iemand schade van ondervindt.
Alleen een krankzinnige zou dan de patch toch releasen.

[marco208]

Als je al je tijd al hebt verspilt met wachten dan ga je niet als het niet werkt nog eens een maand vooruitschuiven terwijl je weet dat er een deadline is. Dan ga je er maar keihard aan werken dat het opgelost wordt of je maakt een workaround.

[TWyk]

Je hoeft juist geen workaround te maken omdat er nog niemand een probleem heeft bij een issue dat nog niet bekend is. Met het maken van een workaround zou je iedereen die de workaround niet toepast een onnodig risico laten lopen.
Dan is het beter om iedereen in 1 keer de volgende keer te patchen.

[LankHoar]

Dus moet er duidelijk iets verbeterd worden in de QA procedure bij MS. Indien je 90 dagen de tijd hebt om iets op te lossen, en dan een week ervoor pas daadwerkelijk je patch wilt gaan uitbrengen, is het logisch dat je geen tijd meer hebt om een eventueel euvel te verhelpen.

[SuperDre]

ja tuurlijk joh, een patch moet gewoon doorgevoerd worden ondanks dat je weet dat er fouten in zitten......... Overigens is het helemaal niet eens bekend of dit lek wel gefixed is in de patchronde die uitgesteld was.

[Jonathan-458]

Lekker begripvol weer, had MS tenminste de kans gegeven tot hen volgende patch ronde.

Stel nu dat Microsoft deze pachtronde niet uitgesteld had en de fix hier wel inzat maar er vervolgens stabiliteit issues optreden op een groot aantal computers?

Kijk als de wil er niet is om te patchen, heb ik er persoonlijk geen issue mee om lekken zo te openbaren echter is het niet duidelijk in dit geval.

[Reactie gewijzigd door Jonathan-458 op 25 juli 2024 07:44]

[hackerhater]

Dit is een veel oudere bug die ze niet goed gepatched hadden!
MS is al ruim een half jaar op de hoogte!

[Jonathan-458]

Het kan voorkomen dat een eerdere patch niet geheel goed werkt of toch niet alles fixed en een vervolg patch nodig is, daar lijkt in dit geval spraken van volgens dit bericht.

Ook is onduidelijk of deze fix onderdeel was van de uitgestelde patch Tuesday, ze hadden tenminste kunnen wachten tot de volgende patch ronde.

[hackerhater]

90 dagen is 90 dagen.
Waarom zou MS een voorkeursbehandeling moeten krijgen?

[Jonathan-458]

Okey, dus jij hebt liever een fix voor een issue waarbij mogelijk de stabiliteit aangetast wordt?

Zie ook "Batjes" post

[Reactie gewijzigd door Jonathan-458 op 25 juli 2024 07:44]

[hackerhater]

Nee ik heb liever dat MS hun kwaliteitscontrole eens op orde krijgt.
Er was geen enkele reden om al die patches in 1 grote blob te dumpen behalve dat het voor MS makkelijker is omdat mensen dan spullen niet meer kunnen ontwijken.

Ik neem het ze zeer kwalijk dat ze 2 "zero-days" open hebben laten staan deze maand.

[Jonathan-458]

persoonlijk vind ik MS huidige beleid veel beter dan dat het voorheen was.

Onthoud ook dat MS enorm veel verschillende configuraties en backwards compatibility in stand moet houden, dit brengt ook de nodige uitdagingen mee. Zoals Batjes, aangeeft kan het erg ingewikkeld zijn.

Het blijft natuurlijk vervelend dat je een Patch ronde moet uitstellen maar wij weten niet exact alle details en kunnen hierdoor niet correct beoordelen of dit nu wel of niet het juiste besluit is geweest.

Echter maakt Google, door het uitgebreid behandelen van dit lek voordat MS Met een antwoord komt, er niet veiliger op.

Als er onwill bij MS was, had ik dit begrepen.

[Reactie gewijzigd door Jonathan-458 op 25 juli 2024 07:44]

[hackerhater]

En de partijen achter Linux moeten dit niet?
Zolang je code en test-procedures in orde zijn is dat geen probleem.
Als je code spaghetti-code is, ja dan heb je een uitdaging maar dan heb je het zelf veroorzaakt.

Er staan op dit moment 3 zero-days open, dat is een potentiële ramp.
Het is niet alleen deze bug, dat flash-lek in IE en dat SMB-lek staan ook nog steeds open.

[Jonathan-458]

Ongetwijfeld, Ik begrijp ook dat er zo snel mogelijk gepatched moet worden echter kunnen er omstandigheden zijn waardoor er niet direct aan een deadline voldaan kan worden.

[ardvark99]

Ik vind dat Google op deze manier niet goed bezig is. Prima dat ze lekken vinden en dit doorgegeven aan de desbetreffende bedrijven, maar wie geeft Google het recht om het zo naar buiten te knikkeren na 90 dagen? Misschien heeft het fixen meer impact in het totale systeem, waardoor het langer duurt voordat de fix uitgerold kan worden. Bovendien maakt het de wereld kwetsbaar totdat de fix uitgerold is. Ik geloof niet dat dit onwil is van in dit geval Microsoft.

Laat Google Andriod aanpassen zodat in dat systeem updates makkelijker uitgerold kunnen worden, zonder afhankelijk te zijn van leveranciers e.d. Dan zijn ze pas goed bezig.

[bkor]

maar wie geeft Google het recht om het zo naar buiten te knikkeren na 90 dagen

Welke wet houd dit tegen dan? Google onderzoekt tenminste beveiligingsproblemen en maakt ze openbaar. D'r is een hele handel hierin, waarbij problemen geheim gehouden worden en worden verkocht (om zulke lekken te "gebruiken").

Ik heb verschillende beveilingsbugs gekregen van librsvg. D'r was geen maintainer. Dus uiteindelijk gevraagd of de verschillende onderzoekers deze bugs gewoon openbaar maken. Liever dat zulke bugs bekend zijn dan dat alleen de kwaadwillende het weten.

[Smuey]

Het argument dat Google hiermee een gevaar voor de consument veroorzaakt is natuurlijk niet helemaal correct. Als onderzoekers bij Google een lek kunnen vinden, kan een random hacker natuurlijk net zo hard zo'n lek vinden en actief misbruiken. Daarbij vind ik 90 dagen best een riante tijd om een kwetsbaarheid aan te pakken, of in ieder geval met een workaround te komen. Patches worden vaak in veel minder tijd dan dat gemaakt.

[batjes]

Het probleem is dat 3 maanden eigenlijk best kort is. Problemen kunnen soms best diep genesteld in het OS zitten en met Windows (of welk OS dan ook) kan het vrij pittig zijn sommige exploits te fixen zonder de backwards compatibility aan te tasten. Dat netjes ontwikkelen kan al rustig 90+ dagen in beslag nemen, laat staan het uitbundig testen van de fix. Ontwikkelen kost tijd en afhankelijk van het risico, in dit geval slechts medium, ligt het er ook aan hoe hoog de prioriteit is, kans is aanwezig dat er andere exploits oid zijn die meer aandacht vereisen.

Het is niet aan Google om te bepalen hoe lang Microsoft (of wie dan ook) nodig denkt te hebben om een probleem op te lossen.

Zodra een exploit bij MS gemeld wordt, gaat MS dit in de gaten houden o.a. door middel van de "privacy schendende" telemetry data. Zodra het actief in het wild misbruikt wordt zal MS de patch pushen zodra die klaar is, zo niet, wacht MS lekker tot de patch tuesdays.

[Belgar]

De US-CERT geeft 45 dagen als een guideline voor leveranciers die leveren aan de Amerikaanse regering (waar windows ook onder valt).

90 dagen vanuit Google is dus een redelijke tijd om een probleem op te lossen. Dat Microsoft er een andere filosofie op na houd is hun probleem, maar Google is hier niet uitzonderlijk bezig

[batjes]

US-CERT:

Q: Will all vulnerabilities be disclosed within 45 days?
A: No. There may often be circumstances that will cause us to adjust our publication schedule.

[Belgar]

En google geeft aan geen verzoek te hebben ontvangen om het uit te stellen, dus moet men niet gaan doen alsof ze verbaasd zijn dat het nu gepubliceerd is.

Bovendien is 45 dagen dus nog steeds de "standaard" en blijft staan tegenover de opmerking dat Google een "arbitraire" norm zou handhaven met 90 dagen. Het is niet arbitrair het is dubbel de guideline

[Blokker_1999]

Want US-Cert is de referentie die iedereen moet volgen?

Wanneer geweten is dat de tegenpartij aan een oplossing werkt geef ze dan ook de tijd om het goed te doen.

[Belgar]

Het is een veilige referentie: Als je responsible disclosure tijd langer is dan die van homeland security kan je als bedrijf stellen dat je meer tijd hebt gegeven dan de overheid had gedaan.

Als je korter gaat zitten stel je je bedrijf open voor de aanklacht dat je niet langer "responsible" bezig bent.

Ik heb verder geen mening over het vrijgeven door Google, behalve dat het consequent is en in lijn met wat andere beveiligingsbedrijven hanteren.

[bbob]

De vraag is of google wel had uitgesteld als ze een verzoek zouden krijgen. Gezien de acties in het verleden waarschijnlijk niet.

Maar goed google en MS zijn gewoon concurrenten dus dat speelt hier ook altijd een beetje mee.

[Toettoetdaan]

Maar binnen Google zullen zat MS pc's worden gebruikt, dus het is voor Google zelf ook belangrijk dat MS veilig is.

[batjes]

De vorige keer heeft MS wel contact met Google opgezocht om de publicatie uit te stellen. Google had hier lak aan en heeft toen wel de publicatie gemaakt.

Ondanks dat MS toen de put al gedempt had en de exploit remote vanaf het internet al dicht gezet was. Het was alleen nog lokaal te misbruiken en die patch stond toen al klaar voor de patch tuesday.

Gezien de vorige keer Google schijt had aan MS hun verzoek, waarom zou MS het nu weer proberen?

De norm van Google is arbitrair omdat ze zelf niet zo consequent zijn met hun eigen software en de enige zijn die een vaste publicatie grens hebben. Die van de rest is variabel en op de Project Zero pagina was door Google zelf al duidelijk gemaakt dat MS bezig was met het probleem te verhelpen, gezien een aantal van de gaten ondertussen al gedicht zijn en de proof of concept waar Google mee aankwam zetten, al lang niet meer werkt.

Google ziet gewoon zelf al dat MS bezig is met de vulnerability te fixen, waarom moet MS dan door Google onder de kont getrapt worden?

[TWyk]

US-CERT publiceert nooit exploits terwijl Google hier gewoon een proof of concept bij publiceert waardoor malwarebouwers niks zelf hoeven te onderzoeken of uit te vinden en binnen een week het lek in malware kunnen omzetten

Frequently Asked Questions

Q: Does this mean CERT/CC is going "full disclosure?"
A: We will not distribute exploits, if that's what "full disclosure" means. In our experience, the number of people who can benefit from the availability of exploits is small compared to the number of people who are harmed by people who use exploits maliciously. We will, however, disclose information about vulnerabilities that we might not have previously disclosed. Within the limits of our resources, we will publish information about as many vulnerabilities as we can.

[Belgar]

Dat is een ander deel van de discussie. Ze publiceren wel genoeg om een exploit mogelijk te maken, maar geen exploit. Persoonlijk vind ik dat een beter uitgangspunt, maar het is nog steeds snel beschikbaar

[catfish]

Ah kom zeg. Mensen die malware maken als "beroep" hebben aan een halve uitleg al genoeg om het lek te vinden en uit te buiten.
Een nieuw lek vinden is de uitdaging.
Een beschrijving publiceren is bijna hetzelfde als malware op de markt brengen. Het enige verschil is dat jij en ik er niets mee kan, een pro wel.

[sebastienbo]

3 maanden is lang voor een bedrijf dat een leger van programmeurs heeft.

Ze moeten er natuurlijk wel prioriteit van willen maken...

Bovendien als ze meer tijd wilden dan hadden ze maar een publieke communicatie moeten maken dat ze er nog even mee bezig zijn.
Nu communiceert microsoft helemaal niets, waardoor google het gevoel heeft dat Microsoft gewoon niets doet...(wat ook het geval zal zijn)
Ik ben zeker dat als Microsoft google op de hoogte hield van hun vooruitgang, dat google niet zou doen wat het nu vandaag doet.
Door wat ze doen vandaag kan er druk gezet worden, vergeet niet dat elke dag zo een zero day blijft bestaan, dat er vol tools uitkomen om die exploit te gebruiken en om complexe virussen of trojans te maken.

Wat google doet is de algemene populatie beschermen van Grote bedrijven die vinden dat security geen prioriteit is....
Je mag niet vergeten dat zo een veiligheidslek direct gevolgen voor google kan betekenen, ze worden onrechstreeks benadeeld als netwerken trager gaan of google accounts gehacked worden.

[Reactie gewijzigd door sebastienbo op 25 juli 2024 07:44]

[PolarBear]

3 maanden is lang voor een bedrijf dat een leger van programmeurs heeft.

Veel gemaakte fout is dat meer resources de oplossing sneller oplevert. Zo werkt het niet altijd. Je kan bepaalde problemen niet verder opdelen.

[sebastienbo]

Dan heb je slecht geprogrammeerd.

Als er goed geprogrammeerd is, dan heb je OO en zeer veel methoden.
Problemen kunnen dus altijd op een zeer klein niveau opgelsot worden.

Als je één hele grote functie/methode hebt , dan zit je inderdaad met een groot probleem.

Er zijn conventies over hoe je mooi kan programmeren en daarin komen ook voorschriften voor van hoe kort je een method moet proberen te houden (en dat is verbasend klein)

Grote functies == Zeer moeilijk om te debuggen

https://nicercode.github.io/guides/functions/

Function guidelines:

It's short
Performs a single operation
Uses intuitive names

Het tweed punt loopt bijna overal mis
Persoonlijk heb ik ook gemerkt dat nested loops altijd slecht is op termijn (beter de geneste loop in een functie steken, want eigenlijk is de geneste loop een single operation dat elke keer gebeurd in de outer loop)

[Reactie gewijzigd door sebastienbo op 25 juli 2024 07:44]

[batjes]

Er zijn meer zaken die prioriteit nodig kunnen hebben, weet jij (of Google) veel of MS een week eerder een veel serieusere exploit binnen kreeg waar ze mee bezig zijn.

Bij de vorige publicatie van Google heeft MS wel contact opgezocht met Google en Google wist zelf (of had kunnen weten) dat MS al bezig was met een oplossing (gezien er al een patch de deur uit gegaan was die misbruik vanaf het internet voorkwam). Waarom zou Microsoft weer contact op nemen gezien het duidelijk is dat Google daar toch maling aan heeft?

Google is niet de algemene populatie aan het beschermen, Google is een politiek spel a la Scroogled aan het spelen.

[Croga]

Je maakt hiermee de fout die nagenoeg alle software ontwikkelaars maken. Je gaat uit van het software ontwikkel proces.

Mij, als gebruiker, interesseert dat hele proces geen drol. Om te bepalen hoe lang te wachten met het publiceren van een bug is het ontwikkel proces absoluut oninteressant. De vraag is: Als Google deze fout nu gevonden heeft, hoe lang gaat het dan duren voordat de gebruiker hier last van ondervind? En ik denk dat 3 maanden eerder te ruim is dan te kort.

Als Microsoft meer dan 3 maanden nodig heeft om mijn gebruik van hun systeem weer veilig te maken dan heeft Microsoft een probleem wat ze moeten oplossen. Ik, persoonlijk, wil heel graag weten wanneer mijn veiligheid in het geding is. En dan liefst niet 3 maanden nadat iemand anders het weet. Google is dus extreem aardig dat ze 3 maanden wachten.

[batjes]

Als gebruiker zou dit wel moeten boeien.

Want doordat Google exploits gaat lopen publishen, verhoogd het de kans enorm dat het actief misbruikt gaat worden, terwijl het anders gewoon buiten zicht gebleven zou kunnen blijven.

Niet alleen dat, als Google dankzij deze acties de mensen tegen Microsoft weet op te zetten. Gaat Microsoft misschien breken onder de druk en quick en dirty fixes uitrollen om de gemoederen maar stil te krijgen. Wat in kan houden dat de afgelopen patch tuesday gewoon gepushed zou worden en jou PC straks na de update ronde niet meer opstart.

Wat zit jou dan als gebruiker meer dwars? De exploit? of de niet opstartende Windows?

[Jorick]

Als Microsoft binnen 90 dagen het gat dicht is er niets aan de hand. Vergeet niet dat als Google het gat kan vinden dan kunnen anderen, die misschien minder goede intenties hebben, het gat óók vinden.

En zoals hieronder al aangegeven wordt is de richtlijn voor het oplossen van dergelijke lekken 45 dagen, Google hanteert 90 dagen. Als je binnen 90 dagen een lek niet kunt dichten dan heb je mijns inziens als bedrijf je prioriteiten niet op orde.

Overigens denk ik dat het publiceren van een lek er niet direct voor zorgt dat mensen direct een groot gevaar lopen. Mensen die een dergelijk lek willen exploiteren kunnen ervan uit gaan dat het lek op korte termijn gedicht gaat worden en ze zullen zich afvragen of het nog loont om dergelijke lek uit te gaan buiten. Ze hebben waarschijnlijk meer succes met een zero-day-exploit.

[Raventhorn]

En zoals hieronder al aangegeven wordt is de richtlijn voor het oplossen van dergelijke lekken 45 dagen...

Als je de richtlijn van US-CERT bedoeld, die is 45 dagen voor publicatie. En zelfs dan kan, afhankelijk van de impact die de exploit heeft, daar van afgezien worden (zodat de partij in kwestie meer tijd heeft om het probleem goed op te lossen).

Als je binnen 90 dagen een lek niet kunt dichten dan heb je mijns inziens als bedrijf je prioriteiten niet op orde.

Of je hebt te maken met bug in een dusdanig veelgebruikt en complex pakket, dat niet alleen zijn eigen acties moet ondersteunen maar ook de acties van duizenden zo niet miljoenen andere pakketten, dat je alleen al een week nodig hebt om de bron van het probleem te vinden.

Dan blijkt uiteindelijk dat het probleem zich in een core component bevind, waarbij de benodigde aanpassing problemen oplevert met de interactie met reeds bekende en veelgebruikte softwarepakketten.
Vervolgens zal ook met die leverancier(s) gecommuniceerd (moeten) worden om te zien of die iets kunnen doen aan de manier van gebruik van dat component, maar eigenlijk wil je natuurlijk dat het allemaal backwards compatible blijft omdat veel mensen niet updaten/upgraden.

Het softwarematige fundament van een computersysteem kan je niet altijd aanpassen zonder dat andere zaken omvallen.

Overigens denk ik dat het publiceren van een lek er niet direct voor zorgt dat mensen direct een groot gevaar lopen. Mensen die een dergelijk lek willen exploiteren kunnen ervan uit gaan dat het lek op korte termijn gedicht gaat worden en ze zullen zich afvragen of het nog loont om dergelijke lek uit te gaan buiten. Ze hebben waarschijnlijk meer succes met een zero-day-exploit.

Vrijwel ieder lek is op een zeker moment een zero-day, namelijk zolang de fabrikant er niet van op de hoogte is. Het is altijd hopen dat de eerste die het lek vind goede intenties heeft en het meld.
En dat een lek wordt gedicht, betekent niet dat het lek niet meer in het wild voorkomt. Genoeg mensen die niet (tijdig) (kunnen) updaten.
Zie bijv. ook Stagefright in Android.

In dit geval heeft Google het gevonden en gemeld, dat staat vast en is gepubliceerd. Maar denk je echt dat criminelen aan Microsoft melden welke lekken ze gevonden hebben?
Óf het lek door een ander gevonden is, is dus niet duidelijk. Daarmee kan je dus ook niet inschatten of het wel of niet gebruikers in gevaar brengt.
Wat Google nu wél (wéér) heeft gedaan, is het ontzettend makkelijk maken voor kwaadwillenden om het te misbruiken, eventueel in combinatie met hun reeds ontwikkelde, eigen, exploits.

[Jorick]

Ongeacht in welk component het probleem zit zal het lek linksom of rechtsom gedicht moeten worden. Dat er dan mogelijk andere software breekt kan zo zijn maar zou geen reden moeten zijn om het lek maar langer dan nodig te laten bestaan. Overigens ben je met software redelijk flexibel, voor veel problemen zijn meerdere oplossingen te vinden en het zal zelden het geval zijn dat de enige oplossing een oplossing is die afhankelijke software sloopt. Voor dit soort zaken hebben bedrijven IT'ers in dienst die software/updates eerst testen voordat ze het uitrollen.

Dat er mogelijk iets stuk zou kunnen gaan is geen reden om maar uitgebreid je tijd te nemen voor repareren van beveiligingslekken. Daarnaast weerhoudt het Microsoft er niet van om updates uit te rollen die de boel slopen (is de afgelopen jaren een aantal keer voorgekomen) dus echt een goed argument vind ik dat niet.

Als software van derden niet meer werkt door een update van Windows dan is het aan die softwareleveranciers om zo spoedig mogelijk met een update te komen om het probleem te verhelpen. Voor softwareontwikkelaars is dit dagelijkse kost en is onderdeel van de ondersteuning die ze op hun software geven (al geef ik toe dat sommige partijen hier wat laks mee zijn).

Dat ieder lek op een zeker moment een zero-day is doet in dit geval niet ter zake omdat Microsoft al een hele tijd op de hoogte is en het probleem zelfs al deels heeft opgelost. Om beveiligingslekken maar stil/geheim te houden omdat het anders mogelijk misbruikt zou kunnen worden lijkt mij geen goed beveiligingsbeleid.

Wat betreft het Stagefright lek dat je aanhaalt, hier op Tweakers schreeuwden een aantal mensen moord en brand mede door het updatemodel van Android (wat inderdaad niet optimaal is). Een goede anderhalf jaar later blijkt dat, ondanks 95 procent van de Android apparaten kwetsbaars was (en deels nog is), tot op de dag van vandaag nog geen enkele besmetting is waargenomen dat gebruik heeft gemaakt van het Stagefright lek (bron). Het bekendmaken van een exploit hoeft dus niet per definitie te betekenen dat deze actief misbruikt gaat worden.

[Reactie gewijzigd door Jorick op 25 juli 2024 07:44]

[Raventhorn]

Ongeacht in welk component het probleem zit zal het lek linksom of rechtsom gedicht moeten worden.

Absoluut mee eens.
Maar ik heb liever dat ze het goed doen, dan dat mijn pc niet meer wil booten.

Overigens ben je met software redelijk flexibel, voor veel problemen zijn meerdere oplossingen te vinden en het zal zelden het geval zijn dat de enige oplossing een oplossing is die afhankelijke software sloopt.

Ook bij software development heb je te maken met beperkingen door architectuur en beperkingen door gebruikte componenten en hardware waarop het moet werken.
Daarnaast zijn er meer manieren om dingen stuk te maken dan om de problemen daadwerkelijk op te lossen, en lang niet alle mogelijke oplossingen zijn ook duurzaam op langere termijn.

Dit betreft een bug in het GDI+ systeem, wat al best oud is. Kan best zijn dat er een hoop technical debt in de weg zit om een goede of duurzame oplossing te vinden.
Zolang we de source niet kunnen inzien, blijft het bij speculatie.

Voor dit soort zaken hebben bedrijven IT'ers in dienst die software/updates eerst testen voordat ze het uitrollen.

Ook software testers kunnen lang niet alles vinden, zelfs niet in combinatie met automatische testen (Coded UI, Unit, integratie etc).
100% coverage is a myth, zowel omdat het functioneel niet te doen is, als tijdtechnisch niet te doen is (testen vereisen ook onderhoud), als dat het kostentechnisch niet rendabel is.

Omdat Windows op zoveel verschillende hardware draait, is het niet te doen om alle mogelijke combinaties van gebruikte drivers en gebruikte software te testen. Een van de manieren waarop ze dat proberen te tackelen is d.m.v het Insider programma, waarmee ze eerder feedback krijgen vanuit systemen bij consumenten. Maar zoals daar ook te zien is, krijg je zelfs dan nog lang niet alles er uit, getuige de updates die soms de boel stuk maken.

Als software van derden niet meer werkt door een update van Windows dan is het aan die softwareleveranciers om zo spoedig mogelijk met een update te komen om het probleem te verhelpen. Voor softwareontwikkelaars is dit dagelijkse kost en is onderdeel van de ondersteuning die ze op hun software geven (al geef ik toe dat sommige partijen hier wat laks mee zijn).

Mee eens. Maar niet altijd realistisch, zeker niet als je ziet hoeveel oude software nog dagelijks gebruikt wordt, 'omdat het nog werkt' en 'omdat het goed genoeg is'.
Ik ken bijvoorbeeld mensen bij meerdere, vooral kleinere, bedrijven waar bijvoorbeeld nog actief gebruik gemaakt wordt van Adobe Photoshop CS2, of Office 2003 (omdat Office XP niet meer wilde werken en hier nog een paar licenties van over waren).
Beide worden niet meer ondersteund, maar de gebruikers verwachten wel dat hun pakket dan ook gefixt wordt. Wat natuurlijk niet gaat gebeuren, en ze geforceerd worden om óf de update niet te installeren, óf te upgraden.

Dat ieder lek op een zeker moment een zero-day is doet in dit geval niet ter zake omdat Microsoft al een hele tijd op de hoogte is en het probleem zelfs al deels heeft opgelost.

Waar bij het oplossen van de overige problemen, mogelijk, een ander probleem optreedt.
Zolang Microsoft niet laat weten waarom ze Patch Tuesday hebben uitgesteld, is het speculeren.
Juist omdat ze in het verleden wel eens vaker een patch hebben uitgebracht waar het een en ander kapot ging, ga ik er van uit dat dit niet zomaar gedaan is.

Om beveiligingslekken maar stil/geheim te houden omdat het anders mogelijk misbruikt zou kunnen worden lijkt mij geen goed beveiligingsbeleid.

Absoluut mee eens. Security through obscurity is nooit een goede aanpak.
Maar het lek was al bekend. Alleen was er nog wat research nodig voordat iedereen het zomaar kon misbruiken.
Nu Google een PoC heeft vrijgegeven, is het veel makkelijker op te nemen in exploit kits.

Wat betreft het Stagefright lek dat je aanhaalt, hier op Tweakers schreeuwden een aantal mensen moord en brand mede door het updatemodel van Android (wat inderdaad niet optimaal is). Een goede anderhalf jaar later blijkt dat, ondanks 95 procent van de Android apparaten kwetsbaars was (en deels nog is), tot op de dag van vandaag nog geen enkele besmetting is waargenomen dat gebruikt heeft gemaakt van het Stagefright lek (bron). Het bekendmaken van een exploit hoeft dus niet per definitie te betekenen dat deze actief misbruikt gaat worden.

De bron die je hiervoor aanhaalt is zowel beperkt als dat het riekt naar 'Wij van WC Eend..'.
Het betreft alléén de devices welke de Google Services meeleveren, en het statement komt van het hoofd Android Security... Van Google.

Niet dat het niet goed is om dit soort cijfers te horen, maar gezien de belangenverstrengeling (een Google-medewerker laat zich uit over een Google-dienst) en het gebrek aan verder bewijs, doen mij niet zomaar geloven dat deze cijfers ook kloppen. Als blijkt dat Android zo lek als een mandje is, haken mogelijk veel leveranciers af, waardoor Google geen geld meer kan verdienen aan alle gebruikersinfo.

Echter, het voorbeeld was alleen bedoeld om te laten zien dat lang niet alle gebruikers zomaar kunnen updaten (want, Android update policy van leveranciers, maar kan ook door antieke hardware of zeer specifieke antieke software), of überhaupt updaten...

[SuperDre]

tja, jij gaat hiermee de fout die nagenoeg alle gebruikers maken. Jij gaat NIET Uit van het software ontwikkel proces..

Tja jou interesseert het hele proces geen drol, maar het moet allemaal wel gedaan worden met de bezetting/middelen die een softwarebedrijf tot beschikking heeft.
als jij denkt dat 3 maanden lang is, dan heb je dat helemaal mis, ja voor een simpel losstaand programmaatje kan dat best zo zijn, maar voor een OS systemwide feature wordt het al een stuk lastiger (waarbij je dus ook rekening moet houden met software/processen die al lang draaien).
Is goed, MS fixed dit lek binnen 2 dagen, BAM ineens werkt de helft van jouw andere software niet meer omdat de patch zijn werk doet. Denk dat je dan nog harder staat te schreeuwen dan voordat je van het lek op de hoogte was.

[Croga]

tja, jij gaat hiermee de fout die nagenoeg alle gebruikers maken. Jij gaat NIET Uit van het software ontwikkel proces..

Ik ga niet uit van het software ontwikkel proces omdat je daar geen geld mee verdient. Je verdient geld met gebruikers en met software. Hoe die software ontstaat interesseert de gebruiker niets.

Is goed, MS fixed dit lek binnen 2 dagen, BAM ineens werkt de helft van jouw andere software niet meer omdat de patch zijn werk doet. Denk dat je dan nog harder staat te schreeuwen dan voordat je van het lek op de hoogte was.

als alle andere software plots niet meer werkt heeft de programmeur het verkloot. Ook dat interesseert mij als gebruiker niet heel erg veel. Ja, mijn software doet het niet meer dus is er een kans dat jij een klant kwijt raakt. Had je je werk maar moeten doen.

[SuperDre]

So over onrealistisch gesproken zeg. Dus als een OS maker een functie patched waarvan jij gebruik maakt voor een belangrijk deel, dan vind jij dat de softwareleveranciers maar zijn werk had moeten doen, terwijl die dat ook heeft gedaan. Is een beetje zoals met die bagger anti-virusapplicaties die een hoop smerige truukjes uithalen om zo dingen te kunnen detecteren maar wat wel weer kan leiden tot jouw software die dan niet meer werkt, terwijl jij niets fout hebt gedaan..

Hoe software onstaat interesseert jou misschien niet, dat kan dan wel zo zijn, maar software ontstaat niet zomaar uit het niets, net zoals jij ook niet zomaar uit het niets bent ontstaan, daar is ook een heel proces aan vooraf gegaan.

[Croga]

Dus als een OS maker een functie patched waarvan jij gebruik maakt voor een belangrijk deel, dan vind jij dat de softwareleveranciers maar zijn werk had moeten doen, terwijl die dat ook heeft gedaan.

Als een stuk software op dat OS draait en de functies van het OS gebruikt en de maker van het OS vervolgens die functionaliteit kapot maakt met een patch dan heeft de maker van dat OS zijn werk duidelijk niet gedaan. Daar is niets onrealistisch aan.

Hoe software onstaat interesseert jou misschien niet, dat kan dan wel zo zijn, maar software ontstaat niet zomaar uit het niets, net zoals jij ook niet zomaar uit het niets bent ontstaan, daar is ook een heel proces aan vooraf gegaan.

Mooi. Dat proces is absoluut oninteressant. Dat proces levert mij als klant geen waarde. En zolang software makers alleen naar het proces kijken gaat de software ook niet beter worden. Als klant betaal ik niet voor het proces, ik betaal voor de waarde die ik uit de software haal.

Helaas is de manier van denken "proces is belangrijker" te ver door gedrongen. Dat is ook exact de reden dat Ford een fout in zijn autos die tot fatale ongelukken leidde niet oplostte. Het was goedkoper voor ze om de mensen die zich dood reden schadeloos te stellen dan de fout op te lossen. Dát is wat je krijgt als je proces voor functionaliteit stelt. En dat is exact wat Microsoft hier ook doet: Het is goedkoper voor ze om hun klanten te laten hacken dan om het probleem voor de klant op te lossen.
"Processes and tools over individuals and delivering value".....

[SuperDre]

Mijn god, jij begrijpt het echt niet he.. Patchen, software schrijven is een process, je doet niet even 'simsalabim' en de software staat er. Je doet net even maar ff 3 regeltjes code wijzigen en hopen dat het allemaal wel goed komt (en zelfs dat is een process)..
Als ik zo jouw redenatie lees, en dan jouw profiel bekijk, dan kan ik eigenlijk alleen maar tot de conclusie komen dat jouw profiel complete gelogen is, anders zou je namelijk niet zulke opmerkingen maken.

[TWyk]

Als onderzoekers bij Google een lek kunnen vinden, kan een random hacker natuurlijk net zo hard zo'n lek vinden en actief misbruiken

Dat is theorie.
Verreweg de meeste lekken worden gevonden door security onderzoekers en slecht zelden wordt een spontaan een lek gevonden door hackers. Hacktools zitten vol met hacks die gepubliceerd zijn door security onderzoekers (vaak ook al gepatched). Hoogstens een paar keer per jaar komt er een zero day vanuit de hacking community en dan meestal ook nog van state sponsored hackers.
Ik denk dat de kans dat een random hacker een lek vind een factor 1000 kleiner is dan dat ene security onderzoeker van een software bedrijf of een security bedrijf een lek vindt.
Dat maakt elk gepubliceerd lek waarvoor nog geen patch is ook vele malen gevaarlijk dan een gemiddeld ongepubliceerd lek.
En daarom is het wel degelijk slecht voor de consumenten als er lekken gepubliceerd worden voordat ze gepatched worden.

[Nik Du Bois]

de meeste PUBLIEK gekende exploits misschien.De security teams van grote bedrijven hebben geen superpowers. Ze worden betaald om dit te doen, zijn getraind en werken er hele dagen aan. Blackhats die 0 days verkopen kunnen er ook hele dagen aan werken en dezelfde kennis/training hebben.

verder vergeet je dat ook vaak de dingen die security researchers publiceren gebaseert is op malware/traces van malware die het al misbruikt.

[TWyk]

verder vergeet je dat ook vaak de dingen die security researchers publiceren gebaseert is op malware/traces van malware die het al misbruikt.

Voor kritieke zero-days die in het wild gebruikt worden wordt ook door Microsoft af en toe afgeweken van de maandelijkse patchdag. Maar dat is dan 1 of 2 keer per jaar.

[bwerg]

Het argument dat Google hiermee een gevaar voor de consument veroorzaakt is natuurlijk niet helemaal correct. Als onderzoekers bij Google een lek kunnen vinden, kan een random hacker natuurlijk net zo hard zo'n lek vinden en actief misbruiken.

Je leest de kritiek van Microsoft 'verkeerd om': het niet bekend maken van dit lek wil niet zeggen dat niet iemand (met kwade bedoelingen) op aarde er al vanaf weet, maar het wel bekend maken van dit lek betekent wel dat er nu waarschijnlijk ook wel mensen met kwade bedoelingen vanaf weten (en in ieder geval, meer dan voor bekendmaking).

Jouw reactie is een goede op bedrijven die zeggen dat een white hat ze überhaupt niet mag proberen te hacken, omdat dat gevaarlijk is voor de eindgebruiker (en dat responsible disclosure dus geheel een slecht idee zou zijn). Als Microsoft er op dit moment alles aan doet om zo snel mogelijk te patchen, voegt publieke bekendmaking niets meer toe aan veiligheid behalve een waarschuwing aan consumenten om producten met dit lek überhaupt niet meer te gebruiken.

Dan ontstaat er natuurlijk discussie over of Microsoft wel genoeg opschiet met patchen, daar is die deadline van 90 dagen is dan ook voor.

[Reactie gewijzigd door bwerg op 25 juli 2024 07:44]

[Smuey]

https://googleprojectzero.blogspot.nl/ Lees het anders even door en vertel me dan nog eens hoe ze niet naar hun eigen software kijken

[catfish]

Sorry, maar niet alle Google software blinkt uit in stabiliteit.

[Smuey]

Dat beweer ik ook niet, sterker nog, dat wordt juist bevestigd door bovenstaande link Alfa1970 beweerde dat Project Zero niet naar software van Google zou kijken, maar daar staan ook gewoon voorbeelden van op de lijst. Je ziet mij nergens beweren dat software van Google foutloos zou zijn hoor.

[mikkie1]

Zoals? Oprecht geïnteresseerd!

[HansvDr]

Misschien moet Microsoft de grootste spyware producten, google adsense en google analytics eens Windows breed blokkeren met de volgende update.

[BikkelZ]

Stond no tracking niet ooit standaard aan al? Daarom werd dat ook nooit een succes. Maar inderdaad gewoon een keuzemenuutje a la browser keuze menu geven als men voor het eerst het internet op gaat.

"Wilt u dat alles wat u doet op het internet wordt opgeslagen door derde partijen en gebruikt voor commerciële doeleinden? Let op: bij blokkeren krijgt u géén cookie pop-ups meer als u Europese websites bezoekt"

[Volg alles wat ik doe] [Blokkeer tracking]

[TWyk]

Stond no tracking niet ooit standaard aan al? Daarom werd dat ook nooit een succes.

Het zou standaard aan moeten staan maar dat kan alleen werken als een wetgevende partij dat afdwingt.
Bijvoorbeeld de EU zou moeten regelen dat browsers die voorkeur default op "No tracking zouden moeten zetten of de gebruiker moeten laten kiezen. En de EU zou ook moeten eisen dat alle sites die zich richten de browserinstelling zouden moeten respecteren op straffe van zware boetes.

Alternatief (en mijn voorkeur) zou de EU gewoon moet verbieden dat EU burgers over meerdere websites heen gevolgd mogen worden. Websites mogen dan alleen eigen bezoeker tracken en mogen gegevens uit iemand surfgedrag niet delen/combineren met andere websites.