Microsoft dicht door Google ontdekt lek in Windows

Microsoft heeft een patch uitgebracht voor een lek in Windows dat Google vorige week publiceerde. Kwaadwillenden konden via dat lek een privelege escalation verkrijgen. De kwetsbaarheid wordt actief misbruikt via spearphishing-aanvallen.

Het beveiligingsbulletin van de patch heeft aanduiding MS16-135 en de update dicht een kwetsbaarheid in nagenoeg alle ondersteunde versies van Windows, vanaf Vista. Alleen gebruikers van Windows 10 Anniversary Update in combinatie met een browser die is bijgewerkt naar de laatste versie zijn niet kwetsbaar.

In zijn securitybulletin stelt Microsoft dat de update meerdere kwetsbaarheden voor het verhogen van rechten aanpakt. De privilege escalation was mogelijk vanwege fouten in de manier waarop de kernel geheugenadressen aansprak. Een aanvaller kon de address space layout randomization met een exploit omzeilen. Om dit uit te buiten, zou de aanvaller een ingelogde gebruiker moeten verleiden om een speciaal vervaardigde applicatie te installeren.

Google onthulde de kwetsbaarheid vorige week, samen met een andere component die gebruikt zou kunnen worden bij een aanval en die te maken heeft met een kwetsbaarheid in Adobe's Flash. Microsoft had kritiek op Google vanwege de korte periode tussen ontdekken en publiceren: Microsoft kreeg tien dagen om een patch uit te brengen. Volgens Microsoft werd de zero-day actief misbruikt, zij het op kleine schaal, door een Russische groep die ook verantwoordelijk was voor politiek getinte aanvallen in de VS.

Reacties (62)

[A4553]

Zou mooi zijn als Google ook naar zichzelf kijkt en de Dirty Cow bug in Android zou hebben gepatched in de november update.

Wel exploits e.d. van derden binnen een week bekend maken, maar eigen spul op orde hebben niet.
Ben benieuwd hoe Google gereageerd zouden hebben als Microsoft Dirty Cow binnen een week openbaar had gemaakt.

[Muna34]

Dirty Cow is bekend bij Google alleen Android loopt niet direct gevaar. Ze hebben dit getest en er zijn geen directe exploits uit te voeren op android phones.

Daarmee zegende. Google heeft een heftig bounty program op bugs lopen. Het is juist een van de bedrijven die heel erg veel bezig is met bugs. De onderstaande links als een zijstraat.

https://www.google.com/ab...chrome-rewards/index.html
https://googleprojectzero.blogspot.nl/

Als je denkt dat Google die bug links laat liggen heb je het echt mis.

[DrSnuggles]

Niet helemaal waar, het probleem is alleen dat de bug die hier wordt aangehaald niet zozeer Android specifiek is, maar linux generiek. Al zijn Google en de gebruikers van haar producten wel degelijk gebaat bij een fix van deze bug, ligt die verantwoordelijkheid niet inherent bij Google, waar Microsoft wel verantwoordelijk is voor bugs in Windows.

[OddesE]

Al zijn Google en de gebruikers van haar producten wel degelijk gebaat bij een fix van deze bug, ligt die verantwoordelijkheid niet inherent bij Google, waar Microsoft wel verantwoordelijk is voor bugs in Windows.

Je legt de vinger op de zere plek; Android is een gefragmenteerd OS; stukje Linux, stukje Java, stukje Android, stukje hardware vendor... bij dit soort bugs moeten 3 partijen samen hun best doen voor de fix bij de gebruiker aankomt. Als gebruiker heb je niks aan de redenen waarom de fix er niet is en MS kan tenminste in haar eentje de verantwoordelijkheid nemen

[CivLord]

De vraag is of Google een 'patch' voor Android kan maken die de vulnerability van de Linux kernel af kan vangen.
Wanneer mijn huisbaas verantwoordelijk is voor het slot op mijn achterdeur dat met een schroevendraaier is te openen kan ik daarover bij mijn huisbaas blijven zeuren. Ik kan ook (evt. tijdelijk, wanneer mijn huisbaas volgende maand pas langskomt) zelf een grendel aan de binnenkant monteren.

[Zarc.oh]

Je realiseert je hopelijk wel dat Google ook een patch kan maken voor Linux

[CivLord]

Dat ook natuurlijk, maar Google heeft er geen invloed op wanneer die patch dan geïmplementeerd gaat worden, terwijl het die invloed wel op Android heeft.

[Nexz]

Hoe kom je daar nou bij? Dirty Cow valt wel zeker te gebruiken op Android.

http://androiding.how/dirty-cow-root-android/

Momenteel nog als een manier om root-toegang te verkrijgen, maar dat wil niet zeggen dat er geen exploits gemaakt zijn. Een artikel van Phone Arena haalt zelfs aan dat er apps in de Play Store staan die hier misbruik van maken (overigens zelf niet getest):

http://www.phonearena.com...id-security-patch_id87557

[A4553]

'Dirty Cow, as some people are calling the vulnerability, was introduced into the core Linux kernel in 2007. It's extremely easy to exploit, making it one of the worst privilege-elevation flaws ever to hit the open-source OS.'

[...]

'"Manouchehri said of the exploit. "From what I can tell, in theory it should be able to root every device since Android 1.0. Android 1.0 started on [Linux] kernel [version] 2.6.25, and this exploit has been around since [Linux kernel version] 2.6.22."'

Aldus arstechnica. Goed dat Google een buy bounty policy heeft. Dat kan ik alleen maar toejuichen. Wees alleen niet hypocriet als je anderen op gaten in de software wijst.

[iTeV]

Er is gister vorige week nog een beveiligingsupdate uitgekomen voor Android die o.a Dirty Cow en Drammer patched.

https://source.android.com/security/bulletin/2016-11-01.html

[Reactie gewijzigd door iTeV op 22 juli 2024 15:20]

[Titan_Fox]

2016-11-01 is natuurlijk niet gisteren, maar ruim een week geleden.

[iTeV]

Fixed

[P1nGu1n]

Security patch level 2016-11-05 of hoger hebben inderdaad row hammer (CVE-2016-6728) gepatched, en sinds 2016-11-06 ook Dirty Cow (CVE-2016-5195)

Dus zoek naar die data, als je wil weten of je veilig bent

[Reactie gewijzigd door P1nGu1n op 22 juli 2024 15:20]

[Vexxon]

Volgens het volgende artikel wordt deze pas in december gepatched:
bron

]A Google spokesman told Ars the Dirty Cow patch will be released in December. As is the case with all security fixes Google releases for Android, it will be available only for Nexus devices and a small list of other qualifying handsets. The spokesman didn't say why the Dirty Cow patch wasn't included in the patch bundle being released this month.

Dus ja, Google heeft haast met het melden van bugs in software van concurrenten, maar niet met het fixen van hun eigen software. Do no evil...

[Armin]

Wel exploits e.d. van derden binnen een week bekend maken, maar eigen spul op orde hebben niet.

Dat is ook wat Google Zero Day doet. Als je een melding maakt van een lek in een Google programma, wordt dat niet opgenomen in dat programma, is er geen meldingsplicht laat staan een 10 dagen deadline.

[Vexxon]

Dat is wat men 'meten met twee maten' noemt

[rbr320]

Ben benieuwd hoe Google gereageerd zouden hebben als Microsoft Dirty Cow binnen een week openbaar had gemaakt.

Deze zin slaat nergens op, aangezien Microsoft de Dirty COW bug niet heeft ontdekt en het geen specifieke Android bug betreft maar een algemene bug in de Linux kernel, waar Android toevallig gebruik van maakt. Daarnaast is Dirty COW wel degelijk snel bekend gemaakt nadat was ontdekt dat deze bug na 9 jaar nog steeds in de kernel zat. Echter was hij sneller gedicht dan dat het in de media werd opgepakt.

Helaas beheert Google niet de hardware waarop hun OS draait. Dus zelfs als ze een gepatchte kernel in de nieuwe versie van Android opnemen zijn ze nog steeds afhankelijk van de OEM's en carriers om de updates uit te rollen. Nog afgezien van dat oudere toestellen vaak niet meer worden ondersteund met Android 7.

[Vexxon]

Maar dirty cow is uberhaupt nog niet gepatched, dus Google loopt gewoon keihard achter volgens hun eigen protocol, maar ineens is dat geen issue. En dit is niet de eerste keer he, bij Stagefright ging het net zo.
En als die uiteindelijk gepatched wordt is het nog maar de vraag of jouw Android-toestel die patch ooit gaat krijgen en op welk termijn. En ja ja, ligt nooit aan Google die heeft daar natuurlijk helemaal geen schuld aan, maar het zou Google wel sieren als ze dat nou eindelijk eens net zoveel aandacht zouden schenken als de bugs in software van concurrenten.

[Reactie gewijzigd door Vexxon op 22 juli 2024 15:20]

[Verwijderd]

I'm just gonna say this and leave it at that:

Een aanvaller kon de address space layout randomization met een exploit omzeilen. Om dit uit te buiten, zou de aanvaller een ingelogde gebruiker moeten verleiden om een speciaal vervaardigde applicatie te installeren.

[StefanDingenout]

Social engineering werkt. Oh deze website zegt dat ik groot gevaar loop gehackt te worden tenzij ik deze tool installeer, beter doen dan...

Zat mensen die in dat soort dingen trappen, hoewel het voor bedrijven natuurlijk meestal minder een probleem omdat de administrator vaak ingesteld heeft dat mensen niet zelf iets mogen installeren.

[Verwijderd]

heel erg waar.. social engineering werkt gewoon nog beter in deze tijd als in de 90's... echt bizar..

ik bedoel ik werd minimaal 2x per jaar gebeld uit india door 'microsoft' omdat ik een 'fout' in mijn pc heb.. die ze met een 'tool' kunnen verhelpen..

tot ik een mooie tape op mn antwoord apparaat had gezet met: you've reached the Federal Bureau of Intelligence... toen ging de telefoon een stuk minder vaak annoniem over let me tell you

[OddesE]

Niet bizar. Het probleem is heel fundamenteel; hoe zie je het verschil tussen de vertrouwde omgeving en een namaak? Als Windows om je wachtwoord vraagt, hoe weet je dan zeker dat het echt Windows is die het vraagt en niet een applicatie die de gui van Windows nabootst?

Voor mensen die er weinig van weten is het verschil nauwelijks te zien. Daar maken mensen misbruik van en helaas niet alleen criminelen. Ik snap overigens niet waarom men niet harder tegen zulke praktijken optreedt. Waarom staat MS bijvoorbeeld dit soort ads toe in Skype??

[tabashi]

Dit is inderdaad schandalig... Dit komt echt niet professioneel over.

[Vexxon]

Ja social engineering werkt, maar een echt goede social engineer zal deze exploit niet zo snel gebruiken. Een phishing mail lijkt me hierbij een logischere manier om het te misbruiken, aangezien social engineering vaak gericht is op 1 specifiek persoon of een klein aantal mensen.

[StefanDingenout]

Ik wil alleen maar aangeven dat het feit dat een applicatie geïnstalleerd moet worden geen reden is waarom een lek geen problemen zou opleveren (zoals tigermonk suggereert). Het punt is dat gebruikers echt wel zover te krijgen zijn dat ze een onbekende applicatie installeren, als ze al doorhebben dat ze dat doen. Wat de meest waarschijnlijke benadering is om dat te doen is beside the point

Trouwens, de meeste social engineering die ik gezien heb is: iedereen die dit mailtje toevallig ontvangt en ook daadwerkelijk een account bij deze bank heeft. Of: iedereen die op deze website komt. Of: iedereen die dit bericht deelt op Facebook. Niet bepaald gericht op een klein aantal mensen. Het zal naar mijn gevoel eerder zo zijn dat die gericht op 1 persoon of een klein aantal mensen een hoger slagingspercentage hebben dan dat het het merendeel van de social engineering pogingen zijn.

[CivLord]

Die speciaal vervaardigde applicatie kan een spelletje zijn of een shareware tool.
Het hoeft geen per email verspreide ExploitTool.exe zijn.

(Al zijn er genoeg mensen die op een gemaild bestandje zullen klikken met de naam LeukPlaatje.jpg.exe

[Verwijderd]

het punt alleen al dat het desnoods een spelletje is.. antivirus op je telefoon wil ook nogwel (enigzins) helpen.

[OddesE]

Zijn punt is alleen dat als je een applicatie gaat installeren, je al heel kwetsbaar bent. Een applicatie mag heel veel onder standaard gebruikersrechten. Wordt wel elke versie van Windows iets verder dicht gezet gelukkig.

De bug hier is dat de code vanaf standaard gebruikersrechten zonder toestemming hogere privileges kan krijgen, zoals beheerdersrechten. Echter als een gebruiker eenmaal in de installatie procedure zit dan kun je hem ook gewoon vragen om het beheerderswachtwoord; 9 v.d. 10 typed dat dan ook gewoon in

[mdj84nl]

sub7 anyone

[eazyq]

dat is lang geleden!

[mdj84nl]

Beetje hetzelfde principe, je stuurde een mijnfoto.exe naar een dom chickie dmv ICQ en hoppa, je kon zo der laatje openen

[eazyq]

MIRC en sub7, zo'n leuke combo was dat.....

[BrBuggyB]

Stevige update deze patch tuesday. Mijn laptop heeft er zeker een uur op lopen stampen. Geduld dus en niet afbreken! het is schijnbaar een ingrijpende patch/update.

[TunefulDJ_Mike]

Klopt inderdaad beide mijn desktop en laptop waren even bezig met updaten.

[Inverted_World]

Ik vind dit maar een stukje smerige marketing van Google, het was niet de eerste keer dat Google dit deed.

Google heeft er zelf een handje van met Android om gebruikers in de kou te laten staan en zijn update beleid m.b.t. Android zeer slecht onder controle heeft. Bah.

Microsoft heeft er dus 20 dagen over gedaan dit lek te dichten, waar google 120 dagen nodig had om een gerapporteerde bug te fixen.

Edit: Downmodden, serieus?

[Reactie gewijzigd door Inverted_World op 22 juli 2024 15:20]

[Verwijderd]

Helemaal mee eens. Ik vind het extreem arrogant dat Google meent een ander bedrijf de wil op te leggen. Ik ben ervan overtuigd dat indien Google de communicatie omtrent een lek intern met Microsoft houd, er ook een oplossing komt.

Met deze publieke ultimatums maken ze zichzelf niet alleen vijandig, ze leveren ook nog eens direct gevaar op voor gebruikers.

[TheGhostInc]

Ik vind dit maar een stukje smerige marketing van Google, het was niet de eerste keer dat Google dit deed.

Microsoft en Google zijn gewoon concurrenten en moeten gewoon allebei hun zaakjes op orde houden. Concurrentie is er niet om 'lief te zijn', maar om de ander scherp te houden.
In dit geval zit Microsoft gewoon FOUT:
Er wordt actief een bug misbruikt in een product van MS en MS weet dat niet, maar Google wel? Het is in de eerste instantie de verantwoordelijkheid van MS om dit soort dingen op te sporen en in de gaten te houden!
Dat Google eerder weet/communiceert van misbruik betekent dat MS of heeft lopen te slapen of geprobeerd heeft dit onder het tapijt te vegen.

Daarnaast is deze marketing vooral richting professionals, de normale consument krijgt hier niks van mee. Dus ik vind het prima dat ze elkaar gewoon elke keer aan de schandpaal nagelen. Het zijn maar een paar honderd miljoen gebruikers die gevaar lopen!!! En die verantwoordelijkheid ligt bij de producent, niet bij de concurrent/onderzoeker/hacker/...

[MrAndy9797]

Ik heb even een bak onder je reactie gehouden, voor al die zever op te vangen die daar uit kwam...

Nee even serieus... Google bepaalt welke termijn MS nodig heeft om een bug te patchen?! En het is al helemaal niet aan Google om dit publiek te brengen. Het brengt gebruikers onnodig extra in gevaar. Ik wil wel eens zien hoe zij hun Android-systeem op orde gaan krijgen op slechts 10 dagen. Vervolgens ook eens alle mogelijke dreigingen voor Android uitleggen en publiek online zetten... Eens zien hoe snel het gaat met Android?

Het feit dat Google hiernaar gezocht heeft wilt niet zeggen dat MS er niets aan gedaan heeft. Want je zwijgt (wijselijk?) over al die andere bugs en lekken die MS wel vond en opgelost heeft.

[Titan_Fox]

Veel softwarefabrikanten zijn laks met het uitbrengen voor patches. Vaak is het uitbrengen van zo'n lek de enige manier om zo'n fabrikant te bewegen om eindelijk te patchen.

[daanb14]

Als er een bedrijf is met een goed beleid wat betreft lekken patchen, dan is het Microsoft wel. 20 Dagen is niks in vergelijking met hoe lang Google erover doet om Dirty Cow of Stagefright te dichten. Google moet maar mooi naar zichzelf kijken. Daar kunnen ze nog veel leren van Microsoft.

[Nha]

The Stagefright bug was discovered by Joshua Drake from the Zimperium security firm, and was publicly announced for the first time on July 27, 2015. Prior to the announcement, Drake reported the bug to Google in April 2015, which incorporated a related bugfix into its internal source code repositories two days after the report.

Phew, 2 dagen, zo laaaaaaaaaaaaaaaaaaaaaaaaaaaang... 20 is inderdaad veel rapper.

Oh wait.

Ik vind dit wel goed, volgende keer misschien MS die Google of zo aanspoort iets rapper te fixen.
Er zijn er wel die zeggen dat 20 dagen niet genoeg tijd is, maar dat is enkel als je je fix niet goed hebt en er extra problemen voort komen in je tests. In een paar uur, hoogstens paar dagen heb je wel een idee voor de code voor de fix, de rest van de dagen, toch zeker een stuk of 12, zou toch moeten voldoende zijn om te testen?
Zelfs "goed geteste" fixes kunnen nieuwe exploits of bugs introduceren. Zo kan je eeuwig blijven testen. Zelfs MS fixes die er lang over gedaan hebben om gereleased te worden hebben wel nieuwe exploits of bugs gecreeerd, om nog maar te zwijgen van "fixes" die hetzelfde probleem enkel erger maken en helemaal niks fixen. (MS is zeker niet het enige bedrijf dat dit al gedaan heeft, en het is niet iets dat makkelijk op te lossen valt, maakt niet uit hoeveel unit tests je hebt, als je niet de "juiste" hebt, en die bedenken vraagt wat meer creativiteit dan wat zo'n bugfixteam op dat moment kan bovenhalen (geen steek op de mensen)).

Liever iets vlugger een fix die wel nog altijd vrij goed getest is, en een iets hoger risico op nieuwe exploits/bugs, want dan is de oude toch al dicht (fingers crossed) en moeten de stoutaards op zoek naar een nieuwe. Zolang nieuwe exploits/bugs dan ook aan gelijkaardig vlugger tempo gefixed geraken.
Ik vind 20 dagen echt wel heel lang, dat zijn 20 dagen dat niemand veilig was voor die bug (buiten die kleine groep die in het artikel vermeld was). MS heeft er zeker al een gewoonte van gemaakt van vrij traag te zijn met fixes dus een trap onder de kont kan geen kwaad imo. Zolang andere trage bedrijven ook maar een trap onder de kont krijgen.

[daanb14]

Als Google die bug niet gepubliceerd had, dan had helemaal niemand gevaar gelopen.
Even een tijdsverloop van Stagefright:
-27 April 2015 licht Joshua Drake Google in over Stagefright.
-29 April 2015 komt google met een fix.
-augustus 2015Google maakt patch Stagefright publiek

[Reactie gewijzigd door daanb14 op 22 juli 2024 15:20]

[Nha]

Als Google die bug niet gepubliceerd had, dan had helemaal niemand gevaar gelopen.

Verkeerd. Die werd al gebruikt.
Als je echt denkt dat het verzwijgen van exploits jouw beveilliging helpt dan ben je serieus mis. Heel wat exploits worden al voor kortere of langere periode misbruikt door groepen die er actief op zoek naar gaan (of gevonden exploits overkopen van zo'n groepen die er actief naar op zoek gaan). Wat jij beschrijft is "security through obscurity". En in geval van exploits die actief misbruikt worden kan dit toch echt geen security genoemd worden.

Ik zie dat ik in mijn vorige post 20 dagen zei, en dat het artikel 10 dagen zegt. 10 dagen vind ik wel weer wat aan de vroege kant, maar ah.

[OddesE]

-augustus 2015Google maakt patch Stagefright publiek

Precies! De code aanpassen is een belangrijke stap, maar niet het enige dat moet gebeuren. 10 dagen voor een update voor een OS dat op zulke diverse hardware draait is gewoon heel goed.

[Loller1]

Alleen was die patch die 2 dagen later kwam niet de oplossing, het heeft maanden geduurd voordat Stagefright herstelt was.

[Nha]

De dirty details van het hele Stagefright verhaal ken ik niet, maar na 2 dagen kwamen ze met een "gerelateerde bugfix", en een paar maand later kwam er iemand anders af met 2 gelijkaardige (maar dus nieuwe) bugs in "de Stagefright library". Dus niet 1 maar 3 bugs, op z'n minst.
En dan nog dit stukje uit een artikel:

The bug was reported by Joshua Drake, from Zimperium zLabs, in April in order to give Google enough time to fix the problem and send patches out to its partners. Drake says that Google has done so -- but that most manufacturers have not reissued them to users, working to the traditionally slow pace of Android phone partners.

Dus diegene die de bug ontdekt en paar maand later bekend gemaakt heeft aan het grote publiek, zegt zelf dat Google het gefixed had, maar dat dus (zoals bij Android wel meer gebeurd) de fabrikanten het niet gepatched hebben. Wil jij dan zeggen dat Google het toch niet gefixed heeft?
Als MS nu met een fix komt voor deze exploit en jij installeert die niet, is het dan wel rechtvaardig om te lopen roepen dat ze het niet gefixed hebben?

Het heeft maanden geduurd omdat de Android telefoon fabrikanten traag waren in het updaten van hun eigen versies, niet omdat Google met de vingers in de neus zat.
Al vind ik niet meteen informatie of dat uit die quote hier vlakboven over die fix 2 dagen later gaat of een andere die ze op een later tijdstip gereleased hebben. Maar het gaat hier over Android, en er is geen twijfel over het feit dat fabrikanten enorm traag zijn in het updaten van hun Android versie/skin. Dus wat lijkt jou het waarschijnlijkst? Dat Samsung e.d. hun zoete tijd namen, of dat Google met de vingers zat te draaien?

[OddesE]

Tja maar e.e.a is ook gevolg van het update beleid (of gebrek daaraan) op Android, dus kom je toch weer bij Google uit. Vergeet niet dat MS ook met partners werkt en in potentie dezelfde problemen heeft.

[Nha]

Behalve dan dat je bij MS niet afhankelijk bent van hun partners of de OEM's om jou van een update te voorzien, die kan je lekker bij MS zelf halen (ik heb geen ervaring met het phone gedeelte dus ik spreek over de desktop variant). Wat je bij Android niet hebt, dus nee, het is niet hetzelfde, en dat Android zo geen updatemogelijkheid heeft kan je, als je dat echt wilt, inderdaad naar Google wijzen.
Bij een AOSP die OTA's aanbiedt zou je toch vrij rap je updates moeten kunnen krijgen. Maar ik weet niet of Google dat zelf voorziet.

Android is in ieder geval inderdaad nogal een ramp wanneer het op updates leveren aankomt, maar dit is een ander probleem dan wat er hier eigenlijk besproken wordt. (maar nog altijd een serieus probleem)
Gelukkig gebeurt dit niet voor Windows. Moeten wachten op HP om een update beschikbaar te stellen die MS al 3 maand eerder had afgewerkt zou een ramp zijn.

[OddesE]

Behalve dan dat je bij MS niet afhankelijk bent van hun partners of de OEM's om jou van een update te voorzien

Yup. Ik zei het een beetje onduidelijk maar dat bedoelde ik inderdaad. Hoewel ook MS met partners werkt, heeft MS het zo geregeld dat ze niet (en hun gebruikers dus ook niet) afhankelijk zijn van die partners om fixes uit te rollen. En dus is het wel degelijk eerlijk om op dezelfde manier te vergelijken: Van melding van het issue totdat het beschikbaar is voor (alle) gebruikers. Dat Google daarvoor afhankelijk is van partners waardoor fixes niet / laat aankomen bij gebruikers valt Google te verwijten.

[Nha]

Het zou mooi zijn dat de Android updates rapper bij de gebruikers terecht komen, maar tenzij Google zoiets gaat afdwingen zal dat jammer genoeg niet gebeuren. Ze waren wel op weg om daar iets aan te doen door bijvoorbeeld hun framework al apart updatebaar te maken via de store.

Moest er nu gewoon de mogelijkheid zijn om de fabrikanten skin helemaal los van het systeem te hebben, dat zou de update problemen volgens mij toch oplossen. Ik heb nooit gesnapt waarom er zoveel aan de fabrikanten overgelaten wordt.

[Loller1]

Iets dat in dit geval absoluut niet het geval was. 20 dagen is een uiterst korte tijd, zelfs ergens zorgbarend: als dit in haast is gedaan kunnen er alleen maar meer problemen komen. Googles 7 dagen limiet is belachelijk, en iets wat ze zelf niet eens kunnen evenaren.

[Reactie gewijzigd door Loller1 op 22 juli 2024 15:20]

[CAPSLOCK2000]

Iets dat in dit geval absoluut niet het geval was. 20 dagen is een uiterst korte tijd, zelfs ergens zorgbarend: als dit in haast is gedaan kunnen er alleen maar meer problemen komen. Googles 7 dagen limiet is belachelijk, en iets wat ze zelf niet eens kunnen evenaren.

Eigenlijk vind ik 7 dagen prima maar je kan het niet eenzijdig aan een ander opleggen. Als bedrijven voor zichzelf een limiet van 7 dagen aanhouden kan ik dat alleen maar toejuichen.
Typisch kost het testen van zo'n fix meer werk dan het vinden van de bug en het schrijven van een oplossing, in veel gevallen is zo'n fix niet meer dan een paar regels code.
Testen kost wel veel tijd maar is ook goed te automatiseren. In een ideale wereld zou alle software zijn voorzien van unit-tests waardoor je de volledige testprocedure in een paar minuten kan doorlopen.
Zodra je met grote zekerheid de betrouwbaarheid van een patch kan controleren (bugfix of anderszins) dan kun je het hele release traject drastisch inkorten. Hoe sneller en betrouwbaarder het testen is, hoe makkelijker het wordt om snel kleine verbeteringen te doen. Er is een hele beweging rond dat idee gestaan onder de naam "Continous Integration", dat loopt al sinds de jaren 90, iedere professionele programmeur zou er bekend mee moeten zijn.

[Verwijderd]

Je vergist je behoorlijk. Voor applicaties kun je misschien bugs redelijk makkelijk fixen. Maar dit soort bugs grijpen heel diep op het systeem in. Het gaat hier niet alleen over het programma maar ook over de werking van de CPU en de MMU. Het oplossen van zo'n bug kan een domino effect te weeg brengen waar je van alles moet omschrijven om het op een plek goed te krijgen. Dit is ook precies de reden waarom kernels zo moeilijk te programmeren zijn. Het vereist behoorlijke expertise van software en hoe de CPU echt werkt. Om exploits te maken op dit niveau moet je soort gelijke expertise hebben. Dit is ook de reden waarom men vaak voor bestaande kernels kiest voor nieuwe besturingssystemen en er niet even eentje zelf schrijven. Het kost gewoon heel veel om te ontwikkelen en te onderhouden.

[CAPSLOCK2000]

Je vergist je behoorlijk. Voor applicaties kun je misschien bugs redelijk makkelijk fixen. Maar dit soort bugs grijpen heel diep op het systeem in. Het gaat hier niet alleen over het programma maar ook over de werking van de CPU en de MMU. Het oplossen van zo'n bug kan een domino effect te weeg brengen waar je van alles moet omschrijven om het op een plek goed te krijgen.

Ik wil het niet hebben over één specifieke bug, sommige bugs zijn inderdaad lastig om te vinden en/of te verhelpen. Dat is echter maar een klein deel van de bugs, ook als het om kernel bugs gaat, de meeste van die bugs zijn triviaal en oplosbaar zonder dat je neveneffecten hoeft te verwachten.
Helemaal zeker zul je het nooit weten, maar dat hoeft ook niet, het kan niet eens, maar ergens moet je een afweging maken tussen de gevolgen van de bug en de eventuele gevolgen van een slechte patch.

Trouwens, in de praktijk bewijzen talloze Linux-distributies dat het kan. De meeste distributies hebben er geen enkel probleem mee om belangrijke bugs binnen 24 uur te repareren. Uiteraard is zo'n oplossing dan maar beperkt getest en dat gaat wel eens fout maar dan heb je als beheerder in ieder geval iets te kiezen.

Om nog even op deze specifieke bug terug te komen, deze bug wordt actief gebruikt om systemen mee aan te vallen. Dat is een goede reden om een fix versneld uit te rollen en het risico op een slechte patch voor lief te nemen.
Klanten/gebruikers kunnen er immers zelf niks aan doen, die hebben de keuze tussen zich te laten hacken of de systemen helemaal te zetten. Een slechts kort geteste patch klinkt dan een stuk beter.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 15:20]

[Arumes]

Het is 7 dagen als er al misbruik van de exploit ontdekt is. Als er wel een exploit is, maar deze nog niet misbruikt wordt, is de limiet 60 dagen. Dat stond ook in het vorige artikel, en in de reacties daaronder heb ik het nog een paar keer herhaald. Maar veel Tweakers hebben blijkbaar een erg selectief geheugen als ze een kansje zien om Google te bashen.

Twee maanden is genoeg tijd om een bug te fixen, en als een bug al misbruikt wordt is publicatie nuttig omdat andere partijen (ook eindgebruikers) rekening met die bug kunnen houden (door bijvoorbeeld even geen Flash te gebruiken).

[BikkelZ]

Google is toch wel hard afgegleden van het bedrijf wat niks mis kon doen en als super integer bekend stond tot een bedrijf wat de slechtste reputatie op het gebied van security én privacy heeft van de Grote Drie. Als dit artikel in 2006 was gepost op Tweakers waren de Micro$oft $uck$ opmerkingen niet van de lucht geweest, nu wordt hier in de reacties de vloer aangeveegd met Google terwijl het om een Windows bug gaat.

Ze moeten zich daar echt eens achter de oren gaan krabben. Ik raad in mijn kennissen-, familie- en vriendenkring in ieder geval af Google producten te gebruiken. Search daar kom je niet onderuit maar Outlook is een prima gratis e-mail dienst die je niet trackt omdat je toch nooit Bing gebruikt, combineer dat met Firefox op een niet Google OS met een ad- en trackingblocker en je zit redelijk goed.

Op een Android telefoon weten ze álles over je, nog bovenop het feit dat qua effectieve security het een ramp is.

[zonoskar]

Duckduckgo.com werkt anders best aardig als google search vervanging.

[Arumes]

Als dit artikel in 2006 was gepost op Tweakers waren de Micro$oft $uck$ opmerkingen niet van de lucht geweest, nu wordt hier in de reacties de vloer aangeveegd met Google terwijl het om een Windows bug gaat.

Ze moeten zich daar echt eens achter de oren gaan krabben. Ik raad in mijn kennissen-, familie- en vriendenkring in ieder geval af Google producten te gebruiken

Volgens mij geef je hier eerst zelf aan hoe krom die situatie is, om er vervolgens zelf aan mee te doen.