image

Google maakt details gevonden kwetsbaarheden voortaan later bekend

vrijdag 16 april 2021, 10:14 door Redactie, 8 reacties

Google maakt technische details van gevonden kwetsbaarheden vanaf nu later bekend wanneer leveranciers binnen de gestelde deadline met een patch komen. Onderzoekers van Google zoeken actief naar kwetsbaarheden in de producten en programma's van andere bedrijven. Wanneer er een beveiligingslek wordt gevonden krijgt de leverancier in kwestie van Google negentig dagen de tijd om de gevonden kwetsbaarheid te verhelpen.

Ongeacht of de leverancier een beveiligingsupdate voor de kwetsbaarheid heeft uitgerold maakte Google de technische details van de kwetsbaarheid altijd op de negentigste dag na de initiële bugmelding bekend. Leveranciers konden een verlenging van veertien dagen aanvragen, maar het was aan Google om dit toe te staan.

Het techbedrijf heeft nu besloten om dit beleid iets aan te passen. Wanneer de gerapporteerde kwetsbaarheid binnen negentig dagen door de leverancier wordt gepatcht zal Google de technische details pas dertig dagen na het beschikbaar komen van de beveiligingsupdate openbaar maken. Dit moet voorkomen dat gebruikers al worden aangevallen voordat ze de beschikbare patch hebben kunnen installeren. De details van Google kunnen aanvallers namelijk helpen bij het ontwikkelen van een exploit.

Mocht de leverancier in kwestie na negentig dagen het probleem nog niet hebben verholpen, dan zullen de details nog steeds op de negentigste openbaar worden gemaakt, zoals altijd het geval was.

In het geval van actief aangevallen zerodaylekken maakte Google de details al na zeven dagen na de initiële melding aan de leverancier bekend. Komt de leverancier binnen zeven dagen met een beveiligingsupdate dan zal Google vanaf nu wederom de details pas na dertig dagen openbaar maken. Is er na zeven dagen geen patch gepubliceerd, dan maakt Google de details wederom zoals voorheen meteen bekend.

Volgens Google zorgt het nieuwe beleid ervoor dat leveranciers negentig dagen de tijd hebben om een update te ontwikkelen en er vervolgens dertig dagen voor de uitrol van de update beschikbaar is. Het techbedrijf verwacht, gebaseerd op de huidige patchtijden dat deze verhouding waarschijnlijk volgend jaar zal worden aangepast naar 84 dagen voor het ontwikkelen van de patch en 28 dagen voor het uitrollen.

Image

Reacties (8)
16-04-2021, 10:46 door Anoniem
Dus Google wil nog steeds bepalen hoe snel iets gepatched is? Even afgezien van het feit, dat melden aan de maker essentieel is, is het ook belangrijk om naar andere dingen te kijken. Bij een aangevallen zero-day is het snel melden goed en moet er bij voorkeur een voorstel voor mitigatie zijn. Bij een niet aangevallen probleem, lijkt het me zinnig om op aanvallen te monitoren en anders in goed overleg met de maker te publiceren. Afhankelijk van de plek waar het lek zit, kan fixen binnen een krap tijdsbestek tot andere problemen leiden. Programmeurs zijn mensen kunnen fouten maken, zeker onder tijdsdruk. Dus als een maker van software besluit om eerst een patch uit te brengen, die het exploiteren van het lek bemoeilijkt en pas later de definitieve patch, zou Google moeten wachten tot dat laatste is gebeurd, ongeacht of dit binnen 10 dagen is of binnen 120 dagen.
16-04-2021, 10:55 door Anoniem
Mocht de leverancier in kwestie na negentig dagen het probleem nog niet hebben verholpen, dan zullen de details nog steeds op de negentigste openbaar worden gemaakt, zoals altijd het geval was.

Hoop dat ze ook uitzonderingen kunnen maken op deze regel.

Ter illustratie, een bug in SMB2 kan dan wel gepatched zijn, maar een wereldwijde uitrol van de updates is wel erg moeilijk om dit binnen de gestelde termijn ook nog te doen.
16-04-2021, 11:48 door Anoniem
Door Anoniem: Dus Google wil nog steeds bepalen hoe snel iets gepatched is? Even afgezien van het feit, dat melden aan de maker essentieel is, is het ook belangrijk om naar andere dingen te kijken. Bij een aangevallen zero-day is het snel melden goed en moet er bij voorkeur een voorstel voor mitigatie zijn. Bij een niet aangevallen probleem, lijkt het me zinnig om op aanvallen te monitoren en anders in goed overleg met de maker te publiceren. Afhankelijk van de plek waar het lek zit, kan fixen binnen een krap tijdsbestek tot andere problemen leiden. Programmeurs zijn mensen kunnen fouten maken, zeker onder tijdsdruk. Dus als een maker van software besluit om eerst een patch uit te brengen, die het exploiteren van het lek bemoeilijkt en pas later de definitieve patch, zou Google moeten wachten tot dat laatste is gebeurd, ongeacht of dit binnen 10 dagen is of binnen 120 dagen.
Google is wat clemente naar Microsoft geworden, ondanks dat die zo traag patcht. Het belang zou ik niet weten want Google doet niks met Microsoft software. Je zou zeggen waar maken ze zich druk om.
16-04-2021, 13:38 door Anoniem
Het is van de zotte dat ze niet secure coden daar. Het lijkt wel of er een stel beginners zitten. En als je kijkt in welke versies de exact zelfde fouten zitten is dat reused code.
ja, dan heb je wel even nodig om de fout te verhelpen.
Het is een schandalig bedrijf als je kijkt naar het aantal cvss3>9 van de afgelopen tijd.
16-04-2021, 14:18 door Anoniem
Waarom zo laat?,het komt toch juist ten goede als kwetsbaarheden gelijk worden gemeld?. Dan kan er tot er een patch is toch meteen aan een workout worden gewerkt?. Op deze manier kan je een hoop ellende voor zijn.
16-04-2021, 15:04 door Anoniem
Door Anoniem: Dus Google wil nog steeds bepalen hoe snel iets gepatched is? Even afgezien van het feit, dat melden aan de maker essentieel is, is het ook belangrijk om naar andere dingen te kijken. Bij een aangevallen zero-day is het snel melden goed en moet er bij voorkeur een voorstel voor mitigatie zijn. Bij een niet aangevallen probleem, lijkt het me zinnig om op aanvallen te monitoren en anders in goed overleg met de maker te publiceren. Afhankelijk van de plek waar het lek zit, kan fixen binnen een krap tijdsbestek tot andere problemen leiden. Programmeurs zijn mensen kunnen fouten maken, zeker onder tijdsdruk. Dus als een maker van software besluit om eerst een patch uit te brengen, die het exploiteren van het lek bemoeilijkt en pas later de definitieve patch, zou Google moeten wachten tot dat laatste is gebeurd, ongeacht of dit binnen 10 dagen is of binnen 120 dagen.
90 dagen is zowat 3 maanden. Als een softwaremaker in die tijd niet in staat is om een lek te dichten dan is er iets goed mis met die softwaremaker.

Ooit was het gangbaar om te doen wat jij voorstelt: een lek melden bij de maker en het pas openbaar maken nadat het gedicht was. Het bleek dat meerdere softwarebedrijven, waaronder heel grote, er bij die benadering domweg geen prioriteit aan gaven om lekken te dichten en dat die er wel heel lang in konden blijven zitten. Dat is problematisch omdat als iemand die het lek netjes meldt het weet te vinden je er niet vanuit kan gaan dat niemand die het lek zou misbruiken het weet te vinden.

Daarom nam een aantal mensen een andere houding aan: meteen het lek openbaren, zodat softwaremakers wel gedwongen waren er de hoogst mogelijke prioriteit aan te geven. De redenatie was dat het bestaan van het lek op zich de software onveilig maakte, een ander kan het immers ook vinden, en dat dit de snelste weg naar veiligheid was.

Maar natuurlijk is dat wat te kort door de bocht, een lek dat open en bloot op straat ligt heeft een aanzienlijk grotere kans misbruikt te worden dan een lek dat niet algemeen bekend is. Sofwarebedrijven kwamen daarom als compromis met het idee van "responsible disclosure": meld het, houdt het nog een zekere periode onder de pet, maar niet onbeperkt, zodat er wél een deadline is die druk op de ketel zet om het op te lossen, maar niet meteen alle misbruiksluizen open gezet worden door directe publicatie.

Als je de deadline weer loslaat dan kan je erop wachten dat er bedrijven zijn die als ze de druk niet meer voelen om de lekken die gemeld worden te dichten het laten versloffen, en als dat gebeurt kan je erop wachten dat een deel van de mensen die lekken vinden ze weer meteen openbaar gaan maken.

Dat 90 dagen best lang is wordt duidelijk als je het vergelijkt met hoe het Linux kernel team met security bugs omgaat: men wil ze zo snel mogelijk in de openbaarheid hebben, en houdt een termijn aan van onmiddelijk tot enkele weken na de melding, maar liever dagen dan weken, met een dag of 7 als typische termijn. Als die dat kunnen, waarom zou het een ander 13 keer zoveel tijd moeten kosten? Dan lijkt men er nog steeds geen hoge prioriteit aan te geven. Google faciliteert die lage prioriteit wel met 90 dagen.

The goal of the Linux kernel security team is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. However, the kernel security team holds the final say when setting a disclosure date. The timeframe for disclosure is from immediate (esp. if it’s already publicly known) to a few weeks. As a basic default policy, we expect report date to disclosure date to be on the order of 7 days.
https://www.kernel.org/doc/html/v4.15/admin-guide/security-bugs.html
17-04-2021, 09:53 door karma4
Door Anoniem: Google is wat clemente naar Microsoft geworden, ondanks dat die zo traag patcht. Het belang zou ik niet weten want Google doet niks met Microsoft software. Je zou zeggen waar maken ze zich druk om.
Ordianire machtstrijd. Google doet niets met de problemen en kwetsbaarheden rond Android Chrome die ze zelf hebben.
17-04-2021, 23:02 door [Account Verwijderd]
Door karma4:
Door Anoniem: Google is wat clemente naar Microsoft geworden, ondanks dat die zo traag patcht. Het belang zou ik niet weten want Google doet niks met Microsoft software. Je zou zeggen waar maken ze zich druk om.
Ordianire machtstrijd. Google doet niets met de problemen en kwetsbaarheden rond Android Chrome die ze zelf hebben.

https://www.security.nl/posting/696617#posting697326 #nofurthercomment
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.