Google: lekken na 60 dagen onthullen
Google spreekt zich uit tegen het stilhouden van lekken tot een softwareleverancier toekomt aan het dichten daarvan. Wachten is niet in het belang van gebruikers en beveiliging.
Google spreekt zich uit tegen het stilhouden van lekken tot een softwareleverancier toekomt aan het dichten daarvan. Wachten is niet in het belang van gebruikers en beveiliging.
Google: lekken na 60 dagen onthullen
Google spreekt zich uit tegen het stilhouden van lekken tot een softwareleverancier toekomt aan het dichten daarvan. Wachten is niet in het belang van gebruikers en beveiliging.
De internetgigant onderschrijft daarmee de handelingen van werknemer Tavis Ormandy die eerder kritieke lekken in Windows, maar ook Linux, heeft ontdekt en geopenbaard. De security-onderzoeker is daarvoor flink bekritiseerd, maar ook geprezen. Hij heeft de lekken niet meteen onthuld, maar de betrokken leverancier 60 dagen de tijd gegeven om een patch uit te brengen. Dat is Microsoft laatst wel gelukt.
Maanden of jaren openstaan
Google hekelt nu de term 'responsible disclosure', dat is het melden van het lek aan de maker van de software, en dat verder stilhouden. Het bedrijf stelt dat het netjes melden van gaten bij softwareproducenten en het vervolgens stilhouden ervan helemaal niet verantwoord is. Gebruikers zijn daar namelijk niet mee geholpen, zeker niet als gaten daardoor maanden of zelfs jaren open blijven staan.
Terwijl een softwareleverancier niet aan een patch werkt, of daar ruim de tijd voor neemt, is de kans zeer groot dat de stilgehouden gaten herontdekt worden. Dat kan dan ook door een kwaadwillende ontdekker zijn.
Aanvallers met veel kennis en ervaring gebruiken 0-day kwetsbaarheden in de praktijk, blogt het securityteam van Google. "Er is een toenemend aantal gevallen van 0-day aanvallen die kwetsbaarheden gebruiken die al enige tijd bekend zijn bij de softwareleverancier, en situaties waarbij het duidelijk is geworden dat een kwetsbaarheid actief werd misbruikt nadat de bug is gedicht of onthuld."
Binnen 60 dagen
Google nuanceert in de blogpost nog wel de kritiek op de twee tegengestelde modellen (full en responsible disclosure) die gebruikt worden bij het omgaan met lekken. "Wij menen dat 'responsible disclosure' twee kanten op moet werken. Leveranciers moeten zich, net als onderzoekers, verantwoord gedragen. Serieuze bugs moeten binnen een redelijke termijn worden opgelost."
De security-experts erkennen dat elke bug uniek is, maar stellen dat een periode van 60 dagen toch echt wel een redelijk maximum is voor het dichten van een echt kritiek gat in software die breed ingezet is. Zoals het marktdominante Windows, hoewel ze dat besturingssysteem niet met naam noemen.
"Deze termijn is alleen bedoeld om van toepassing te zijn op kritieke zaken. Sommige bugs worden verkeerd als 'kritiek' aangemerkt, maar wij kijken naar geaccepteerde richtlijnen om dat belangrijke onderscheid te maken." De experts verwijzen naar Google's eigen 'severity guidelines' voor Chromium (de open source-uitvoering van de Chrome-browser) en naar de richtlijnen van Firefox-maker Mozilla.
Bugs-premie verhoogd
Ondertussen heeft Google ook de premie verhoogd voor kritieke lekken die ontdekkers bij het bedrijf melden. Sinds begin dit jaar betaalt Google het symbolische bedrag van 1337 dollar per gemeld serieus lek in zijn browser Chrome. Nu bedraagt die beloning 3.133,70 dollar. De verhoging volgt vlak na een verhoging die Mozilla doorvoerde van 500 naar 3000 dollar per lek.
Dat vraag ik me af. Sommige regressietests zijn erg lastig, waardoor je zelfs met 60 dagen nog best in tijdnood kan komen.
Fuzzing is handig als je bibliotheken of delen van code op fouten wil testen. Voor programma's is het niet erg geschikt omdat je na elke opgevangen fout het programma opnieuw kan gaan starten voor de volgende fuzzing test.
Ik betwijfel dus of Blieb echt een sterk punt heeft.
De meeste automatische exploits worden gevonden door een compare van de voor en na patch situatie.
Ik denk niet dat Steve achter zijn oren krabt. Heb je de omzet cijfers gezien van Apple. Ze zijn bezig Microsoft in te halen. Microsoft heeft wel een (veel) hogere winst marge. Het is echter wel een indicatie dat alles waar wij het hier altijd over hebben voor de gemiddelde koper niet van invloed is.
;-)
Waar je de grens ook legt, er zullen gevallen zijn waar een bug sneller gefixt is en er zullen gevallen zijn waar de leverancier meer tijd nodig heeft om de fix te maken en te testen. In veel gevallen zal 30 dagen genoeg zijn, en binnen 60 dagen kunnen ook lastige problemen gefixt (en getest) worden.
De onderzoeker kan zijn publicatie ook (op verzoek van de bug-/softwarebakker) uitstellen, als hij overtuigd is dat er serieus aan de bug gewerkt wordt.
Het meest praktische van opensource software is natuurlijk wel dat de persoon die het lek ontdekt ook een patch kan bouwen. Hier zit een lek, dit is de patch!
Peter,
Blieb heeft hier wel een punt.
Fuzzing wordt al enige tijd gebruikt om bugs te vinden in het uiteindelijke resultaat na het compileren. Microsoft is een van de bedrijven die fuzzing gebruikt om de input-handeling van hun software na te kijken.
Soms kan de bug niet in de source zitten, maar in de wijze waarop men de compiler gebruikt. Linux heeft daar al een last van gehad.
Ik denk dat Steve Jobs wel even achter zijn oren krabt, want bij OSX zijn de lekken vaak langer ongepatcht dan bij welk OS dan ook. Daarnaast is het natuurlijk voor elke hacker een vrijbrief om elk gat in Google's software en OS direct openbaar te maken. Of de wereld daar nu beter van wordt...
Ik vind een harde grens van 60 dagen te kort door de bocht. Vaak zal het genoeg zijn, maar vast niet altijd.
Ik weet dat het eenvoudig is om aan de hand van de patch het lek te vinden en misbruiken. Fuzzing als methode om exploits te ontwikkelen? Het zou best kunnen, maar dan ben ik wel benieuwd naar een link.
Verder hang je dezelfde verhalen op als altijd. Je argumenten rammelen naar mijn mening, maar daar hebben we pas 100+ discussies over gevoerd.
Je kunt lekken makkelijker op executables opsporen met bijvoorbeeld fuzzing softwaree dan in source code dus dat de source code open source is zegt weinig. Het maatk het hoogstens makkelijker om exploits te maken.
En open source betekent bepaald niet dat alle bugs in de bugs database open zijn en daar kunnen makkelijk jarenlang kritike lekken blijven zitten bijvoorbeeld omdat er andere zaken een hogere prioriteit hebben.
Blieb, heb je enig idee wat de term "open source" inhoud? Ik zal het even uitleggen: Het is "source" code die "open" is. Oftewel beschikbaar, niet gesloten of verborgen. Lekken in Open Source software zijn net als de rest van de source per definitie niet " zorgvuldig verborgen voor de ogen van potentieele aanvallers".
Het is wel zo dat er de dreiging van het bekend maken van lekken vendors kan motiveren hun "Patch development time" te verkorten. Wanneer deze dreiging er niet is wordt de tijd alleen maar langer. Daarnaast is het zo dat er geen enkele reden is om aan te nemen dat de betreffende security expert de eerste is die het lek ontdekt. Het is goed mogelijk dat er reeds een aantal expoits beschikbaar zijn. Microsoft heeft pas na de disclosure een advies uitgebracht voor de eindgebruikers.
Dat is strijdig met responsible disclosure en heeft daar niets mee te maken. Na 60 dagen vervalt de ""afspraak"" immers.
Dus google en MS liggen hier dichter bij elkaar dsan de suggestie van dit artikel wil wekken ;)
Hmm, verlaat Google hiermee zijn bekende motto "Do not do evil"?
Als er iets niet in het belang is van gebruikers dan zijn het wel exploit publicerende security 'researchers'.
Daardoor worden over het algemeen tienduizenden zo niet honderduizenden mensen gecontronteerd met malware waar ze niet tegen beschermd zijn.
Het verleden van responsible disclosre heeft al aangetoond dat dit leidt tot oplossing van heel bugs zonder dat de gebruikers risico hoeven lopen. Zelfs als er een keer een lek alsnog in de publiciteit komt voordat het is gepathed dan is de patchtijd vaak laag omdat de softwareaanpasing meest al beschikbaar is en alleen nog getest hoeft te worden.
Dat zorgt zelfs in worst case scenario's al voor veel betere beveiliging dan onverantwoordelijke publicatie van epxloits zoals de betreffende google reasearcher deed minder dan een week na het doorgeven van de bug aan Microsoft
Ook open source software bouwers gebruiker responsible disclosere met succes in de beveiliging van hun software. Ook daar worden kritieke lekken zorgvuldig verborgen voor de ogen van potentieele aanvallers en kunnen kritieke lekken ook daar makkelijk meer dan een jaar openstaan.
Google heeft dus een hekel aan irresponsible obscurity.
Reageer
Preview