U moet de ontwikkelaar (s) dit privé laten weten, zodat ze de kans krijgen het probleem op te lossen. Daarna, als en wanneer u de kwetsbaarheid openbaar maakt, moet u de ontwikkelaar voldoende tijd gunnen om het probleem op te lossen en degene die eraan wordt blootgesteld voldoende tijd om hun systemen te upgraden. Persoonlijk zou ik de ontwikkelaar in de meeste gevallen toestaan ​​de aankondiging in een beveiligingsbulletin te doen in plaats van het zelf aan te kondigen. Ik zou in ieder geval wachten op bevestiging dat de kwetsbaarheid is verholpen. Als u tijd heeft en toegang heeft tot de broncode, kunt u ook een patch opgeven.

Persoonlijk denk ik dat Verantwoordelijke openbaarmaking vanuit ethisch oogpunt de beste manier lijkt te zijn, en het werkte goed voor Dan Kaminsky door de details van de kwetsbaarheid voor DNS-cachevergiftiging te onthullen. Maar het hangt allemaal sterk af van het bedrijf of de groep waarmee u te maken heeft en ook van het gebruikersbestand waarop het van invloed zal zijn.

@VirtuosiMedia levert een geweldige beschrijving van "Responsible Disclosure".

Ik zou twee punten willen toevoegen:

• Werk samen met de verkoper (als je kunt), om er zeker van te zijn dat ze het volledig begrijpen en geen halfbakken patch uitbrengen.
• Als de verkoper je negeert of negeert, blijf het proberen. Als ze echter beweren dat het geen kwetsbaarheid is, ga je gang en publiceer je. Zo luid mogelijk. Als ze hebben beloofd op te lossen, maar niet, probeer dan een antwoord van hen te krijgen, samen met een definitieve tijdlijn waaraan ze zich committeren. Op een gegeven moment, als ze blijven uitstellen, wil je ze uiteindelijk misschien vertellen dat je toch gaat publiceren - en ze dan wat tijd geven om het daadwerkelijk op te lossen (maar kort en beperkt).

Dit is een heel complex onderwerp. Ik was een paar jaar geleden betrokken bij de onthulling van de heronderhandelingsbug van TLS en geloof me, we hebben heel hard geprobeerd om 'verantwoordelijk' te zijn, maar uiteindelijk slaagden we er vooral in om iedereen om ons heen kwaad te maken en (misschien) uit te stellen de daadwerkelijke release van de fix. Om niet te zeggen dat meldingen van leveranciers noodzakelijkerwijs slecht zijn, alleen dat het heel gemakkelijk is om met een zweep te worden gezaagd en uiteindelijk net zoveel schade als goed of erger te veroorzaken.

In ons geval was het een actie van de IETF ( RFC 5746) om het probleem op te lossen, en ook al hadden we op de dag dat het uitlekte een internetconcept klaar, het eigenlijke werk van debatteren en beslissen over de oplossing duurde ongeveer drie maanden, en dat gebeurde niet begin echt serieus totdat de onthulling plaatsvond.

Hoe dan ook, dit is geen antwoord op uw vraag, maar het is een van de interessantere onthullingsverhalen waarvan ik op de hoogte ben. Meer over dat verhaal in de ShmooCon-keynote van 2010 die ik deed met Marsh Ray, die het probleem ontdekte.

Over het algemeen hangt het af van de reactie van de leverancier. Een goede praktijk is wanneer een beveiligingsonderzoeker de leverancier informeert over de kwetsbaarheid, en u tijdens een gesprek praat over de publicatievoorwaarden van poc / exploit van deze kwetsbaarheid. Eigenlijk kiest de onderzoeker wat hij met deze kwetsbaarheid wil doen - later publiceren of niet. Vervolgens brengt de leverancier een patch of nieuwe productversie uit. Kan zijn. Maar wat blijkt uit ervaring - niet alle verkopers zijn zo aardig. Sommigen van hen repareren in stilte bugs, zonder eindgebruikers en onderzoekers te informeren, sommigen negeren de onderzoeker liever. Anderen proberen zelfs een aanklacht in te dienen. Daarom is anonimiteit soms de beste manier van eerste communicatie met onbekende leverancier.

Ik zou ook willen toegeven dat er beloningsprogramma's voor bugbounty zijn - die worden aangeboden door Google, Mozilla. Bovendien kopen anderen kwetsbaarheden: ZDI, iDefense, SNOsoft, komende "exploit hub", enzovoort. Er zijn dus minstens drie manieren hoe de leverancier te informeren - rechtstreeks, door informatie over de kwetsbaarheid op een lijst te publiceren of via externe bedrijven.

Als ze een openbare issue-tracker hebben, kijk dan of je een bug kunt melden met een "private" of "security" -label.

E-mail security, ongeacht of ze een issue-tracker hebben. @ bedrijfsnaam en laat ze weten.

Als ze niet redelijk snel reageren (zie "Window of Disclosure" in het Schneier-artikel hieronder), moet u nadenken over het op grotere schaal bekendmaken. Zoek naar mailinglijsten waar beveiligingsacademici / -professionals op loeren en vraag hen hoe ze problemen melden aan de betreffende leverancier. Ze kunnen wellicht kennismaken met de juiste plek in de organisatie.

Als dat allemaal mislukt, lees dan het Schneier-stuk en bedenk of volledige openbaarmaking een deel van het probleem of een deel van de oplossing zou zijn.

Bruce Schneier geeft een argument voor volledige openbaarmaking in bepaalde omstandigheden op basis van een "deel uitmaken van de oplossing, geen deel uit maken van het probleem" -standaard. Het is zeker de moeite van het lezen waard.

Dit is het klassieke debat over "bug geheimhouding vs. volledige openbaarmaking". Ik heb er eerder over geschreven in Crypto-Gram; anderen hebben er ook over geschreven. Het is een gecompliceerde kwestie met subtiele implicaties voor de hele computerbeveiliging, en het is de moeite waard om opnieuw te bespreken.

...

Deze vrije informatiestroom, zowel van beschrijving als proof-of-concept code, is ook van vitaal belang voor beveiligingsonderzoek. Onderzoek en ontwikkeling op het gebied van computerbeveiliging is in de afgelopen tien jaar tot bloei gekomen, en veel daarvan kan worden toegeschreven aan de beweging voor volledige openbaarmaking. De mogelijkheid om onderzoeksresultaten - zowel goede als slechte - te publiceren, leidt tot een betere beveiliging voor iedereen. Zonder publicatie kan de beveiligingsgemeenschap niet van elkaars fouten leren. Iedereen moet opereren met oogkleppen aan en steeds weer dezelfde fouten maken. Volledige openbaarmaking is essentieel als we de beveiliging van onze computers en netwerken willen blijven verbeteren.

...

Ten tweede geloof ik in het vooraf informeren van de verkoper. CERT heeft dit tot het uiterste doorgevoerd en de leverancier soms jaren de tijd gegeven om het probleem op te lossen.

...

Ik hou van het "deel uitmaken van de oplossing, geen deel van het probleem" metriek. Onderzoek naar beveiliging is een deel van de oplossing. Het overtuigen van leveranciers om problemen op te lossen, is een deel van de oplossing. Angst zaaien is een deel van het probleem. Het overhandigen van aanvalstools aan onwetende tieners is een deel van het probleem.