Google Project Zero wacht dertig dagen na fix met publicatie kwetsbaarheden

Google Project Zero, de afdeling van Google die kwetsbaarheden in software onderzoekt, zal in 2021 dertig dagen extra wachten voordat het technische informatie over ontdekte kwetsbaarheden publiceert. Het team wil mensen langer de tijd geven om patches en fixes te installeren.

Ontwikkelaars krijgen van Google Project Zero nog steeds negentig dagen de tijd om een kwetsbaarheid te verhelpen. Als de kwetsbaarheid na deze periode nog niet verholpen is, publiceert Project Zero de technische details meteen. Als de kwetsbaarheid in deze periode wel werd verholpen, dan publiceert het team de details pas dertig dagen nadat de fix werd toegepast. Ontwikkelaars kunnen om uitstel van de kennisgeving vragen van maximaal veertien dagen.

Als een kwetsbaarheid actief wordt misbruikt, krijgt de ontwikkelaar of het bedrijf in kwestie slechts zeven dagen de tijd om deze te patchen. Als de patch er na zeven dagen nog niet is, publiceert Project Zero onmiddellijk alle technische details. Men kan drie dagen uitstel vragen. Als een ontdekte kwetsbaarheid werd verholpen binnen de zeven dagen, worden de details pas dertig dagen na de fix gepubliceerd.

De uitstelperiodes die bedrijven en ontwikkelaars kunnen aanvragen worden afgetrokken van de daaropvolgende termijn van dertig dagen die Project Zero hanteert om te wachten met de publicatie.

Met deze maatregelen wil Project Zero nog steeds dat ontwikkelaars sneller bugfixes en patches uitbrengen. Het team ontdekte echter dat de ontwikkeling van bugfixes of patches niet versnelde. Bovendien kreeg het te horen dat de technische details te snel gepubliceerd werden waardoor gebruikers die de fixes of patches nog niet hadden geïnstalleerd heel wat gevaar liepen.

Volgens Project Zero is deze nieuwe regeling duidelijker en veiliger. Ontwikkelaars krijgen, in de meeste gevallen, negentig dagen de tijd om te werken aan een fix en omdat er dertig dagen extra worden uitgetrokken om de adaptatie van de fixes te verhogen, stelt het team dat dit een veiliger protocol is. Elk jaar herbekijkt Project Zero of het zijn protocollen moet aanpassen.

Reacties (52)

[robvanwijk]

Volgens Project Zero is deze nieuwe regeling duidelijker en veiliger.

Is "regeling" echt het goede woord? Dat suggereert dat beide partijen het erover eens zijn. Met de manier waarop Project Zero opereert zou ik het eerder een ultimatum noemen.

Ja, ik begrijp waarom ze er druk op willen zetten. Maar deze aanpassing komt voort uit het feit dat zelfs zijzelf toegeven dat hun aanpak tot nog toe niet heeft gewerkt. (Andere Google teams wel uitstel van executie geven terwijl externen nooit uitzonderingen krijgen helpt ook niet mee met hun geloofwaardigheid...) Zelfs als ze de beste bedoelingen hebben, het lijkt erop dat tot nog toe het middel erger is dan de kwaal.

[Reactie gewijzigd door robvanwijk op 25 juli 2024 20:51]

[azortje]

Andere Google teams wel uitstel van executie geven terwijl externen nooit uitzonderingen krijgen helpt ook niet mee met hun geloofwaardigheid...

Kun je dit statement ook onderbouwen?

[robvanwijk]

Helaas wist ik niet meer uit mijn hoofd in welke software het probleem indertijd zat en zoeken op "project zero google bug" werkt natuurlijk niet zo handig. Na wat zoekwerk denk ik dat ik Stagefright in gedachte had. Je hebt gelijk dat ik een detail verkeerd onthouden heb: dat lek is oorspronkelijk niet door Project Zero gevonden; mijn bewering dat Project Zero "corrupt" is door interne teams uitstel te geven klopt dus niet. Mijn bewering dat ze hypocriet zijn blijft echter overeind: Google had veel meer dan 90 + 30 = 120 dagen nodig om de fix bij (het overgrote deel van) hun klanten te krijgen. Als Google andere bedrijven ongevraagd een bepaalde deadline op wil leggen, dan zouden ze toch op zijn minst hun eigen bugs binnen diezelfde deadline op moeten lossen.

[theduke1989]

Aan de ene kant iets wat goed is. Aan de andere kant 30 dagen kan veel schaden. Dus het is echt hoe je het maar bekijkt natuurlijk. Bij grote bedrijven is het lastig om een patch uit te brengen binnen 30 dagen goed te testen. Maar kleinere bedrijfjes zou dat iets minder een groot probleem moeten zijn.

[CH4OS]

Euh, je krijgt 90 dagen, tenzij het gevonden lek actief misbruikt wordt. Voor adaptatie is er nog eens dertig dagen extra wanneer er een fix is gereleased. In feite 120 dagen maximaal tot publicatie. Negentig dagen zijn om en nabij de drie maanden, hoe is dat weinig tijd?

[Reactie gewijzigd door CH4OS op 25 juli 2024 20:51]

[Erasmo]

Is het niet beter om een lek nog niet wereldkundig te maken maar een welwillend bedrijf nog 30 dagen extra te geven om het te patchen? Je wilt dan geen slapende honden wakker maken.
Er wordt zelfs specifiek geschreven dat de termijn korter is als het lek actief misbruikt wordt.

[Keypunchie]

die 30 dagen is vooral voor ‘klanten’ om een patch door te voeren.

Als Apple bijvoorbeeld een OS update doet en ik ben op reis (vroeger deed men dat wel eens, reizen), dan wacht ik ff met updaten omdat ik niet in de buurt van mijn backups ben.

Binnen bedrijven moet er vaak zelfs een heel traject van test-, acceptatie naar productie gaan en daar zit doorgaans wel een week of wat in.

Dus het is niet meer tijd voor de ontwikkelaars van een product, maar voor eindgebruikers.

[NTS]

Apple is een mooi voorbeeld, de iPad wordt veel gebruikt als Electronic Flight Bag (EFB) omdat het een heel gecontroleerd platform is. Als er een nieuwe iOS versie uit komt duurt het altijd een paar weken tot de EFB software leveranciers hun OK geven voor die versie. Ze moeten namelijk een flinke set tests uitvoeren om zeker te weten dat in alle omstandigheden, ook rare combinaties, hun software werkt zoals het hoort.

[i-chat]

30dagen is voor consumenten gewoon veel te lang ook als je gaat reizen, doe je dat doorgaans een week of 2 a 3 - ga je langer weg dan neem je meestal ook wel iets van een laptop oid mee, en dus een externe schijf (voor de vakantiefoto's/filmpjes).

Voor bedrijven heb ik nóg minder sympathie, en wel om het volgende, bedrijven verwerken namelijk óók gegevens van klanten, cliënten of burgers dan moet je dus je infra gewoon op orde hebben (inclusief een spoed- implementatieplan voor nood-patches). dat gezegd hebbende, Als er dus een bepaald beveiligingslek zit in software van een webwinkel, dan wordt dat door google gemeld, het bedrijf achter de sofware patched netjes binnen 7 dagen dus habben hackers na ontdekking nog 37dagen om het lek actief te misbruiken omdat tokkietoko.nl zijn shit niet op orde heeft / houdt.

dus afhankelijk van de aard van de sofware zou ook die post-patch periode gewoon maximaal 7 dagen moeten zijn bij actief misbruikte lekken.

[Keypunchie]

Dit is wat ze bij Google ook dachten: als we maar genoeg druk zetten dan gaan mensen en bedrijven wel sneller patchen.

Dat is zoals je wil dat de wereld werkt, ze komen erachter dat het anders is.

Als ze vast bleven houden, dan betekent dat vooral dat er meer mensen de dupe worden van meer hackers.

[Daoka]

Als een bedrijf snel patch installeren en hierdoor functioneert hun eigen software niet meer dan is het bedrijf ook niet blij en klagen wij als klanten ook. Dan kunnen ze misschien beter even iets meer tijd nemen.

[Platpoot]

Laptop mee op vakantie?? Nee mij niet gezien ik zit al 6 dagen per week 10 uur per dag achter zo'n ding. Ik zou ook niet weten waarom je hier tegen zou zijn, het enige wat nu later wordt gedaan is details bekend maken. Nergens haal ik er overigens uit dat hackers nu 37 dagen hebben. Het enige wat ik lees is dat scriptkiddies nu pas na 37 dagen los kunnen ipv 7 dagen omdat de details niet bekend zijn. Verder ben ik uiteraard voor het zo snel mogelijk patchen, maar snap ook dat niet iedereen als een havik op het updateknopje klikt, 95% van de Nederlanders is in mijn optiek niet geschikt om een computer aan te raken dat moeten we maar accepteren.

[sircampalot]

Het was zo, dat als google zero een kwetsbaarheid vindt, ze het bedrijf 90 dagen geven om het probleem te fixen. Nu geven ze de gebruikers dus nog 30 dagen daarna om de patch door te voeren.

[Keipi]

Het gaat hier om een tijd van 30 dagen nadat de patch al is uitgebracht.

Ontwikkelaars krijgen 90 dagen om een patch te ontwikkelen.

Staat allemaal netjes in de titel en de eerste paar regels van het artikel

[NielsFL]

De fix is er. Bedrijven die makkelijk updaten gaan er dus niks op achteruit. Bedrijven die wat meer tijd nodig hadden, lopen nu iets minder risico omdat de details nog niet bekend zijn gemaakt.

De enige die een beetje extra risico loopt is de persoon die pas actie onderneemt wanneer hij de details kent. Die is denk ik sowieso toe aan een herziening van het update-beleid.

[i-chat]

de gene die potentieel het minste invloed heeft en het meeste last, is de persoon die met zijn data voorkomt in de lekke software waar het in dit geval om gaat. Die isnu dus geen 90 maar 120 dagen in gevaar.

Nu is het natuurlijk niet zo dat elk lek in elke software automatisch ook privacy in gevaar brengt, maar tegelijkertijd zijn er maar heel weinig online systemen die helemaal geen userdata, betaal- of logingegevens of andere privacy-issues met zich meebrengen.

[Reactie gewijzigd door i-chat op 25 juli 2024 20:51]

[Christoxz]

Die 30 dagen is niet voor de ontwikkelaars, maar om gebruikers te tijd te geven de patches te installeren.

Het team wil mensen langer de tijd geven om patches en fixes te installeren.

Ontwikkelaars krijgen van Google Project Zero nog steeds negentig dagen de tijd om een kwetsbaarheid te verhelpen.

Kortom, op zijn langst wordt een kwetsbaarheid pas bekend na 120 dagen. 90 dagen verhelpen, 30 dagen uitrol.
Prima actie van Google, en geeft ontwikkelaars geen voordeel, en cybercrimelen juist een vertraging.

[GertMenkel]

Als je echt dertig dagen nodig hebt om een specifieke security-fix, klinkt dat echt als een probleem van het bedrijf, niet van Google.

Dat je grote fesutre-updates op de lange termijn pas toepast is logisch, daar kun je makkelijk een half jaar over doen voor je weet of je het wilt doorzetten. Security-patches zijn anders, die veranderen functionaliteit normaal niet (tenzij er in de changelog beschreven staat wat er anders is).

Als je een security-patch niet kan doorvoeren vanwege een gedragsverandering, zou dit meteen een alle-hens-aan-deksituatie moeten zijn voor je IT-teams om op zijn minst een workaround of mitigations te bedenken zodat je de tijd kunt nemen de nodige wijzigingen aan te brengen.

Als je bedrijf onderbemand is, te veel bureaucratie heeft of te slechte IT'ers heeft aangenomen, kun je moeilijk Google de schuld geven als je niet snel genoeg bent. Kijk boos naar je manager die dit zou moeten oplossen.

[TheToolGuy]

"Bij grote bedrijven is het lastig om een patch uit te brengen binnen 30 dagen goed te testen."

Klopt, er moeten ook veel meer niet technische mensen een plasje over plegen, dat is het nadeel van grote bedrijven inderdaad ...

[dasiro]

klanten zouden even veel tijd moeten krijgen als devs om een patch te installeren, want vaak wordt software niet standalone gebruikt, maar geïntegreerd met een hoop andere software. 30 dagen is welgeteld 1 patch-window.

sowieso is het publiekelijk disclosen van lekken in software van een 3e partij een laakbare praktijk, want als er geen development meer op de software staat gepland, dan kan je niet zomaar ff x aantal man van een ander project halen of inhuren omdat google het nodig vindt om het aan de grote klok te gaan hangen. Dit is inbreken op bedrijfsprocessen en klanten in gevaar brengen.

[GertMenkel]

Als je software draait waar geen development meer op staat gepland, zou je als klant op de hoogte moeten zijn van het risico. Je bent als bedrijf zelf verantwoordelijk om je software up to date te houden en beveiligingsrisico's op te lossen.

De 30 dagen gaan in nadat de maker van de software een patch heeft gemaakt. Als je eens in de 30 dagen updatet, is dat inderdaad vervelend, maar dan zul je nu al nog veel meer beveiligingslekken missen. De dagen van Patch Tuesday zijn echt al jaren voorbij, updates worden wekelijks door MS uitgegeven en je kunt ervan uitgaan dat hackers een exploit hebben de dag nadat Microsoft de update online heeft gezet. Nu geeft Google je 30 dagen om de patch van de fabrikant te installeren, dat zijn er 28 of 29 meer dan de hackers je geven.

Ik heb geen medelijden met softwarebedrijven die doen alsof hun kortetermijnsbelangen gaan boven die van de veiligheid van hun klanten. Je hebt drie maanden meer dan de Russen of Noord-Koreanen je geven, je krijgt alle details netjes aangeleverd en krijgt een proof of concept dat je zo in je debugger kunt gooien. Als je daar binnenddrie maanden niet één iemand op kan zetten, heb je wat mij betreft pech.

Als je je software niet sunset maar er ook geen aandacht meer aan wil besteden, is dat een fout van je bedrijfsvoering, niet van Google.

[Jerie]

Je hebt drie maanden meer dan de Russen of Noord-Koreanen je geven

Om nog maar te zwijgen over andere APTs, zoals die van China. Ook het Westen heeft offensieve cybersecurity commando's, zoals Israël, Verendigde Staten van Amerika, Nederland, ...

[GertMenkel]

Wat een onzin. Als een fabrikant weet dat het slot van mijn auto simpel open te maken is, gratis vervangende sloten naar iedere garage stuurt en iedereen oproept ze te vervangen, is het toch mijn eigen schuld als ik daar een half jaar mee wacht omdat het te ver omrijden is naar de garage?

Als je auto gestolen wordt met sloten waarvan je wist dat ze makkelijk open te krijgen zijn, wens ik je veel succes de verzekeraar te laten betalen.

[Reactie gewijzigd door GertMenkel op 25 juli 2024 20:51]

[The Zep Man]

Wat in de brandstoftank zit is universeler om te gebruiken. Velgen die het verkopen waard zijn hebben een slotbout, en passen maar op een select aantal voertuigen. Voor andere velgen is het te veel moeite voor te weinig winst.

[GertMenkel]

Ik kwam met een andere vergelijking, want de jouwe slaat je vergelijking als een tang op een varken. Dat je een beveiligingslek publiceert betekent niet dat je actief crimineel bezig bent.

Wat jij voorstelt, niet mogen publiceren hoe je illegale dingen zou kunnen doen, staat in je boutenvoorbeeld gelijk aan een verbod op het publiceren van reparatiehandleidingen omdat dieven er mogelijk achter komen hoe ze de bouten los moeten draaien. Op zich misschien toch een goede vergelijking, want iedere dief kan een auto kopen, zelfs een met speciale veiligheidsbouten, de bouten bekijken en analyseren, een ontwerpfout van de fabrikant vinden, gereedschap maken om ze snel los te wippen en daarmee flink cashen.

Het verschil is natuurlijk dat een auto niet gratis die ontwerpfout gerepareerd krijgt, waar dit bij software wel zo is.

Stel dat dit wel zou gebeuren, iedereen kan gratis naar de garage gaan en zijn bouten vervangen krijgen, en ik zet op internet een blog waarin ik beschrijf wat er mis is gegaan met het ontwerp en hoe je dat in de toekomst voorkomt, heb ik dan je banden gejat? Nee, BMW maakte een fout die ik blootgelegd heb, je banden zijn voor of na mijn blogpost net zo makkelijk te stelen.

Van wat ik zo hoor, zit er een beveiligingsprobleem op de bevestiging van zo'n wiel; iedereen kan hem zomaar losmaken. Jij hebt me daar zojuist uitgebreid over ingelicht. Doe je nu niet exact wat Google ook doet? Heb je de maker van je auto wel op de hoogte gebracht van deze bevindingen? Wat als ik nu besluit autobanden te stelen, is dit nu jouw schuld?

[dasiro]

is het zo dat softwarefouten gratis gerepareerd worden? Bij veelgebruikte software die nog actief onderhouden wordt meestal wel, maar bij een hele hoop andere software die daar niet onder valt mag je ervoor betalen als het al wordt gepatcht.

Moest niemand weten dat je met een standaard dopsleutel plots zomaar wielen kan gaan stelen en fabrikanten kunnen of willen er niets tegen doen en er worden plots massaal wielen gepikt omdat deze pagina door duizenden criminelen wereldwijd wordt gelezen die op zoek zijn naar een manier om snel wat bandjes te kunnen doorverkopen, dan kan je het klasseren als aanzetten tot diefstal, wat zelfs strafbaar is. Zo wordt de vrije meningsuiting ook beperkt tot op het punt waarop je niet meer zomaar een mening uit, maar mensen aanzet tot criminele activiteiten.

[rbr320]

Als je software gebruikt waar geen ontwikkeling meer op plaats vindt, maar waar nog wel kwetsbaarheden in worden gevonden, wordt het tijd om over te stappen naar iets anders. De andere optie is om deze software alleen beschikbaar te maken in een gecontroleerde, afgeschermde omgeving zodat kwaadwillenden er niet zonder meer bij kunnen komen. Daarmee beperk je de risico's hopelijk tot een aanvaardbaar niveau.

[dasiro]

ben je ooit al een MKB binnen gestapt? We spreken hier niet enkel over grote bedrijven met een volledige IT-archtictuur, maar over ALLE software waar ze iets in vinden. De exchange-perikelen van de laatste tijd zijn een mooi voorbeeld van software die ook in een bedrijfje van 20 werknemers kan draaien en ze gewoon blijven gebruiken. Dit zijn heel gevoelige situaties en kunnen de volledige workflow van een bedrijf stil leggen als het om een cruciaal stukje software gaat waar je niet zomaar ff van af stapt.

[GertMenkel]

Zodra je bericht krijgt dat over een half jaar de softwareondersteuning stopt, moet je beginnen een alternatief te zoeken. Als je minder tijd daarvoor krijgt, moet je boos zijn op het bedrijf dat zijn software niet goed sunset.

Dat het MKB hun zaken niet op orde heeft, is hun probleem, niet de mijne. Ik betwijfel of er in de MKB met 20 man personeel 24/7 uptime nodig is voor een Exchange-server, die kun je prima 's nachts een uurtje updates laten uitpruttelen. Het is niet alsof je mail verliest, je kunt je hele server een dag uitzetten als het nodig is en alles komt nog gewoon aan.

[The Zep Man]

ben je ooit al een MKB binnen gestapt? We spreken hier niet enkel over grote bedrijven met een volledige IT-archtictuur, maar over ALLE software waar ze iets in vinden. De exchange-perikelen van de laatste tijd zijn een mooi voorbeeld van software die ook in een bedrijfje van 20 werknemers kan draaien en ze gewoon blijven gebruiken.

Als bedrijf van 20 man Exchange vandaag de dag draaien? Dat is dom.

Dit zijn heel gevoelige situaties en kunnen de volledige workflow van een bedrijf stil leggen als het om een cruciaal stukje software gaat waar je niet zomaar ff van af stapt.

In veel bedrijven zijn er zat redenen om de workflow stil te leggen. Cruciaal IT onderhoud is ook een goede reden, als je afhankelijk bent van IT. Het gaat om dezelfde IT die je primaire processen laten draaien, direct en indirect. Als je dat slecht onderhoud en je hebt een keer een ransomware aanval of een datalek, dan is de schade veel groter.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 20:51]

[dasiro]

Als bedrijf van 20 man Exchange vandaag de dag draaien? Dat is dom.

Tja, wie zegt dat die situaties de dag van vandaag zijn opgezet? Dit soort dingen draait vaak al jaren van voor er sprake was van clouds.

Als je dat slecht onderhoud en je hebt een keer een ransomware aanval of een datalek, dan is de schade veel groter.

dit soort disclosures werkt als een rode lap op een stier voor kwaadwilligen. Zelf niet slim/hebben geen tijd genoeg om er achter te zoeken, maar eens je weet waar de klepel hangt, kan je de klok wel laten luiden. Dat is waar ik op doel. Het melden aan de makers is de enige propere oplossing zonder drukkingsmiddelen.

[The Zep Man]

Tja, wie zegt dat die situaties de dag van vandaag zijn opgezet? Dit soort dingen draait vaak al jaren van voor er sprake was van clouds.

Waarom draait het zo lang zonder onderhoud?

dit soort disclosures werkt als een rode lap op een stier voor kwaadwilligen. Zelf niet slim/hebben geen tijd genoeg om er achter te zoeken, maar eens je weet waar de klepel hangt, kan je de klok wel laten luiden. Dat is waar ik op doel. Het melden aan de makers is de enige propere oplossing zonder drukkingsmiddelen.

Dit is de reden.

Iets enkel lief melden is geen motivatie om het op te lossen. Zie Steam, die een RCE pas na twee jaar (!) oplost, nadat het werd gemeld. Enkel omdat ze publiekelijk in opspraak kwamen, werden er plots middelen vrijgemaakt om het op te lossen.

Degene die zonder disclosure agreement een kwetsbaarheid vindt heeft de macht. Als leverancier en gebruiker van de software moet je je zaken op orde hebben. Google is immers niet de enige die zoekt naar kwetsbaarheden, en niet iedereen zal zo 'lief en meedenkend' zoals zij zijn. Anderen zullen de kwetsbaarheid verkopen voor het hoogste bod, of het simpelweg meteen vrijgeven.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 20:51]

[rob12424]

Ik vraag mij nu eigenlijk 1 ding af. Hoe zit dat met opensource: een lek wordt gemeld aan de communicaty maar dan is hij toch eigenlijk gelijk gepubliceerd? Hoe zit dat?

[GertMenkel]

Dat ligt aan de onderzoeker of het project. Sommige projecten hebben daar speciale regelingen voor (manieren om hoofdontwikkelaars te contacten, bijvoorbeeld). Soms worden er issues op Github gemaakt die vragen hoe je dat slim moet melden. Soms trekken mensen het mailadres van de hoofdontwikkelaars uit de git commits. Zo'n lek gooi je doorgaans niet zomaar open op een github issue, tenzij je merkt dat er al mensen bots hebben gemaakt die automatisch producten aanvallen en de hack geen geheim meer is.

Ook al is de patch openbaar beschikbaar, Google zal hun data waarschijnlijk gewoon gesloten houden voor de 30 dagen erna. Je kunt ook niet veel anders doen natuurlijk.

Je zag een grote versie hiervan bij SPECTRE en Meltdown, waar Intel ontwikkelaars van diverse Linux-distributies (geïsoleerd, wat heel jammer was) op de hoogte bracht van de problemen. Intel heeft de uitrol van de fix daarmee flink vertraagd (een security engineer van Ubuntu mocht niet overleggen met die van Redhat!) maar het principe is er wel: zoveel mogelijk informatie aan een paar vertrouwde mensen doorspelen, coördineren wanneer de fix uit is, en pas achteraf de details publiek publiceren.

Het voordeel en nadeel van zo'n situatie is natuurlijk dat zodra de patch uit is, je heen 30 dagen hebt om die te installeren. Het is echter een illusie om te denken dat dit zo anders is bij proprietary software. Hackers kunnen de exploit ook gewoon vinden door te vergelijken wat er veranderd is tussen versie X en versie X+1 als je aangeeft dat er een securitylek is opgelost in je change logs. Zo zijn er diverse proof of concepts gemaakt van RDP-lekken in Windows door simpelweg te kijken welke checks MS had toegevoegd in de updates. Als hobbyisten dat kunnen, wees je er dan maar van verzekerd dat ransomwaregroepen daar ook toe in staat zijn.

[init6]

Meestal maken ze een CVE aan, ontwikkelaars zijn daar vaak bij aangesloten of worden benaderd. Na het aanmaken van de CVE krijgt het een ID, ik zoek soms op de laatste 20 CVE IDs en soms is er 1 die dan nog ontsloten is.

[ITsEZ]

Dit is toch eigenlijk een vreemde manier van handelen? Google bepaald zelf even wat ze wanneer publiceren en zetten op die manier bedrijven onder druk. Dat zal uiteindelijk vast een veiliger internet opleveren en dat is top. Maar als een “amateur” hacker dit zou doen “patch het nu anders publiceer ik over 7 dagen de details” zou het gezien worden als chantage. Zoekt Google met toestemming van andere bedrijven naar lekken en zijn de bedrijven hier al mee akkoord gegaan? Anders kom je zelfs nog op het punt dat hacken zonder toestemming helemaal niet mag. (Volgens NL wetgeving)

[GertMenkel]

Nee hoor, een bedrijf 90 dagen geven en dan de details publiceren wordt best vaak gedaan. Het is alleen chantage als je er zelf wat voor terugwilt, zoals bijvoorbeeld als je een bug bounty vraagt voor het melden van het lek.

Als ik vanmiddag een lek in Windows vind en vanavond een proof of concept online zet, is daar niks illegaals aan. Onzorgvuldig wellicht, maar het is zeker geen chantage.

Dit programma is juist in het leven geroepen omdat bedrijvenals Microsoft soms maanden wachtte met een patch, of een aantal weken een bekend beveiligingslek niet patchten omdat het nog geen patch Tuesday was. Sommige fabrikanten publiceren zelfs nooit patches als de details niet uitkomen, want waarom zou je geld stoppen in problemen waar je klanten toch niet vanaf weten?

De deadline, 90 dagen, is voor de meeste bedrijven meer dan genoeg. Google levert bedrijven de plek van het lek, een proof of concept om het te reproduceren, en eventueel verder ondersteunend onderzoeksmateriaal dat je nodig hebt om het probleem te vinden. Dan is als software-ontwikkelaar 95% van je werk al voor je gedaan. Het enige dat je dan nog hoeft te doen is de nodige checks en fixes toevoegen, wat automatische tests schrijven en draaien en je fix kan mee in de volgende update.

Google breidt die deadline op verzoek soms ook uit als je een hele goede reden hebt. Denk aan een beveiligingslek dat in het basisontwerp van een protocol zit, waardoor je echt wel weken tot maanden bezig bent daar omheen te werken.

Andere mensen zonder toestemming mag inderdaad niet. Sterker nog, iemands server hacken met toestemming is ook niet altijd legaal (managed VPS bijvoorbeeld, waar de klant niet de eigenaar is). Je mag dus niet inbreken op andermans mailserver om een lek aan te tonen. Wat wel mag, is de software lokaal draaien en jezelf hacken. Als jij een Exchange server opzet en die zelf hackt, is daar helemaal niks illegaals aan, zolang je maar betaalt voor de licentie en je de server niet gestolen hebt van iemand.

Het verschil is dat software die door andere mensen gemaakt is prima onderzocht mag worden, maar van software die andere mensen draaien, blijf je af. Daarom zul je weinig exploits vinden op Project Zero die een Saas-dienst aanvallen (alhoewel de onderliggende, publiek beschikbare tech stack soms wel weer vrij spel is).

[EraYaN]

Het hacken mag altijd op eigen apparatuur. En als jij als amateur ook dezelfde termijn aanhoudt dan is er niets aan de hand, maar als je geld wil zien voor een bug bounty zul je je aan de regels van dat bounty programma moeten houden.

[Erwin1967]

Ik heb hier een raar gevoel bij. Die periode van 90 dagen houden ze niet altijd aan als het om een component betreft binnen Android. Dan blijft het angstvallig stil en hoor je slecht nadat de fix is geïnstalleerd dat er een zero day exploit is opgelost. Dit na 5 maanden na ontdekking.

[CAPSLOCK2000]

Dit is toch eigenlijk een vreemde manier van handelen? Google bepaald zelf even wat ze wanneer publiceren en zetten op die manier bedrijven onder druk. Dat zal uiteindelijk vast een veiliger internet opleveren en dat is top. Maar als een “amateur” hacker dit zou doen “patch het nu anders publiceer ik over 7 dagen de details” zou het gezien worden als chantage. Zoekt Google met toestemming van andere bedrijven naar lekken en zijn de bedrijven hier al mee akkoord gegaan?

Het is een beetje vreemd maar in mijn ogen is het vooral vreemd dat het uberhaupt nodig is. In welke andere sector worden er nu zoveel fouten gemaakt en gevonden? Daar zijn allerlei redenen voor maar het is uiteindelijk wel een beetje gek.

Je hebt ook gelijk dat "amateurs" die iets melden vaak worden beschuldigd van kwade bedoelingen zoals chantage, maar ook hier is het vooral de IT-wereld die gek is. Als ik zie dat er brand is dan is het toch juist mijn burgerplicht om de brandweer te bellen? Je gaat toch niet 7 dagen geheim houden dat er een fabriek in brand staat en er giftige stoffen lekken waar de omgeving last van heeft?

Als er een lek gevonden wordt en je geen reden hebt om aan te nemen dat er misbruik van gemaakt wordt is het inderdaad redelijk dat je het bedrijf netjes informeert en tijd geeft om het probleem op te lossen. Maar als er actief misbruik wordt gemaakt dan zijn de belangen van de slachtoffers groter.

Het hele proces is niet ideaal maar ik ben Google dankbaar dat ze hier het voortouw nemen en de juridische klappen opvangen die kleinere partijen niet kunnen dragen.

Anders kom je zelfs nog op het punt dat hacken zonder toestemming helemaal niet mag. (Volgens NL wetgeving)

Dat is alleen van toepassing als je actief de systemen van een ander openbreekt. Op je eigen systemen mag je doen en laten wat je wil (op dit gebied). De meeste fouten en lekken worden overigens gevonden zonder dat er iemand iets probeert te kraken. Mensen proberen iets te gebruiken en zien dat het niet werkt. Programmeurs zijn getrained om na te denken over oorzaken en gevolgen en beseffen dan al snel dat een bepaalde fout ook gevolgen kan hebben voor de veiligheid. Dat wordt dan gemeld en snel opgelost zonder enige ophef. Als een tuinman ziet dat er een ruit stuk is en dat doorgeeft dan is dat gewoon deel van z'n werk, geen poging tot inbraak.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 20:51]

[StackMySwitchUp]

Heb ik onder een steen geleefd, en is het algemeen bekend dat Project Zero een door Google opgezet team is van security analisten die zero days zoekt in software die veel gebruikt wordt? (ook van niet-Google producten)
Of had dat erbij vermeld mogen worden?

[JayStout]

@StackMySwitchUp Aangepast!

[supersnathan94]

Ja

Project zero is hier al best wel vaak de revue gepasseerd de afgelopen jaren.

[StackMySwitchUp]

Echt nooit van gehoord in deze context. Ik schaam me diep

[supersnathan94]

Nee kan gebeuren, niet iedereen zit de hele dag hier rond te struinen

[OhMyGod]

Zouden ze ook zo consequent zijn voor zichzelf?

[Maurits van Baerle]

Op zich is dit welkom. Het grote probleem met het bekendmaken van kwetsbaarheden én met het publiceren van het patches is dat ze vaak de risico’s vergroten, niet verkleinen.

Zodra je bekend maakt dat er een Remote Code Execution zit in functie zus-en-zo van software X gaat de klok lopen. Potentiële aanvallers zullen meteen aan de slag gaan om het te vinden. Als je dan bekend maakt dat, in afwachting van een patch, je bijvoorbeeld UDP verkeer op poort XYZ kunt blokkeren om de aanval af te slaan weten potentiële aanvallers al meer over wat de aanvalsvector is. Zodra je dan een patch uitbrengt weten de aanvallers dan vaak nog eens preciezer in welk bestand de kwetsbaarheid zit.

Iedere stap in dit proces zorgt ervoor dat, in plaats van een of twee groepen die toevallig de kwetsbaarheid hebben ontdekt (of in veel gevallen zal zelfs niemand weten van de kwetsbaarheid), je ineens tientallen groepen op weg helpt met kennis over het lek.

Vandaar dat je vaak snel na het uitbrengen van een patch moet patchen omdat dat het risico pas echt begint. Het is ook de reden voor zaken als Patch Tuesday. De gevaarlijkste periode is meestal ná publicatie van de patch dus kun je dat beter inplannen.

Vandaar dat teveel transparantie ook zo gevaarlijk is en we procedures als Responsible Disclosure hebben of dat Open Source projecten die alles openbaar hebben uitgerekend voor veiligheidsissues vaak besloten mailinglists, groepen of tickets hebben.

[Reactie gewijzigd door Maurits van Baerle op 25 juli 2024 20:51]

[kodak]

Het vreemde is dat Google zich al die jaren dus niets heeft aangetrokken van patchmanagement bij gebruikers, alsof dat niet relevant was bij publiek maken. Dat geeft niet erg veel blijk van inzicht in patchmanagement. Het klinkt eerder zwaar onprofessioneel en arrogant.

Het is begrijpelijk dat ze bij Google graag kwetbaarheden sneller opgelost zien, maar door vanaf het begin net te doen alsof er keuzes van gebruikers er niet toe doen en de gevolgen van meteen publiceren maar moeten accepteren is meer een vorm van dicteren dan rekening houden met wat er allemaal bij komt kijken om verandering te krijgen. Iets wat Google zou moeten snappen, aangezien hun klanten ook niet massaal iets anders gaan doen als Google zelf iets ongewenst doet met andermans gegevens.

[GertMenkel]

Hoe hun policy is met hun eigen software weet ik niet, maar dat is niet hoe het werkt. Wellicht is er een dubbele standaard die Google langer geeft dan 90 dagen om hun spul te fixen, maar ik heb daar eigenlijk nog nooit bewijs van gezien. De deadline voor software was hiervoor altijd 90 dagen of de dag dat de patch uit is, welke ook eerder komt, tenzij het lek actief wordt misbruikt. Als je nu na een week een patch uitbrengt, wordt de deadline dus 37 ipv 7 dagen. Als je er drie maanden over doet, maar wel patcht, wordt de deadline 120 dagen. Als je na drie maanden je spul nog niet op orde hebt, zit je wel aan de 90 dagen vast.

De vorige keer dat Google in het nieuws kwam, ontdekten ze de exploit doordat de aanvalscode in de dumps zat van een Chrome-lek dat ze tegenkwamen. Hun policy voor lekken die actief misbruikt worden door hackers is "meteen publiceren". Het lek is al gevonden, er zijn al hacks geweest, dus zoveel effect heeft het toch allemaal niet.

Het idee hierachter is dat zodra de details over de exploit uit zijn, het triviaal is voor makers van antivirussoftware om hier beveiliging voor in te bouwen. Het is een kwestie van de call chain toevoegen aan de malware-engine en je bent er. Er zijn ook geheime groepen waar antivirusbedrijven samen in het geniep dit soort dingen beschrijven, maar hij de vorige Exchange-exploit was het juist de proof of concept die Microsoft daar verspreidde die men in het wild tegenkwam; zo'n geheime groep werkt dus ook niet. Daarnaast voert het de druk op, zo kan een softwarefabrikant niet doen alsof ze IoT makende prioriteit leggen op het verkopen van nieuwe software terwijl er oude software is die actief gehackt wordt.

Ik vind het allemaal prima, andere mensen vinden het niet netjes. Maar, Google heeft zich altijd aan hun policies gehouden. Het zijn de mensen die de policies niet kennen die het hardste schreeuwen dat Google hun eigen regels overtreedt.