Sie sollten die Entwickler privat informieren, damit sie die Möglichkeit haben, das Problem zu beheben. Wenn Sie danach die Sicherheitsanfälligkeit öffentlich machen, sollten Sie dem Entwickler genügend Zeit einräumen, um das Problem zu beheben, und jedem, der davon betroffen ist, genügend Zeit, um seine Systeme zu aktualisieren. Persönlich würde ich dem Entwickler in den meisten Fällen erlauben, die Ankündigung in einem Sicherheitsbulletin zu machen, anstatt sie selbst anzukündigen. Zumindest würde ich auf die Bestätigung warten, dass die Sicherheitsanfälligkeit behoben wurde. Wenn Sie Zeit haben und Zugriff auf den Quellcode haben, können Sie auch einen Patch bereitstellen.

Persönlich denke ich, dass verantwortungsvolle Offenlegung aus ethischer Sicht der beste Weg ist und für Dan Kaminsky gut funktioniert hat, um die Details der Sicherheitsanfälligkeit bezüglich DNS-Cache-Vergiftung aufzudecken. Aber alles hängt stark von der Firma oder Gruppe ab, mit der Sie es zu tun haben, und auch von der Benutzerbasis, die davon betroffen ist.

@VirtuosiMedia leistet hervorragende Arbeit bei der Darstellung von "Responsible Disclosure".

Ich würde zwei Punkte hinzufügen:

• Arbeiten Sie mit dem Anbieter zusammen (wenn Sie können), um sicherzustellen, dass er es vollständig versteht und keinen halbgebackenen Patch herausgibt.
• Wenn der Anbieter Sie ignoriert oder ignoriert, versuchen Sie es weiter. Wenn sie jedoch behaupten, dass es sich nicht um eine Sicherheitsanfälligkeit handelt, veröffentlichen Sie sie. So laut wie möglich. Wenn sie versprochen haben, dies zu beheben, aber nicht, versuchen Sie, eine Antwort von ihnen zusammen mit einem endgültigen Zeitplan zu erhalten, zu dem sie sich verpflichten. Wenn sie sich irgendwann weiter verschieben, möchten Sie ihnen vielleicht irgendwann mitteilen, dass Sie trotzdem veröffentlichen werden - und ihnen dann etwas Zeit geben, um das Problem tatsächlich zu beheben (aber kurz und begrenzt).

Dies ist ein verdammt komplexes Thema. Ich war vor ein paar Jahren an der Aufdeckung des TLS-Neuverhandlungsfehlers beteiligt, und glauben Sie mir, wir haben uns sehr bemüht, "verantwortlich" zu sein, aber am Ende ist es uns hauptsächlich gelungen, alle um uns herum zu verärgern und (vielleicht) zu verzögern die tatsächliche Veröffentlichung des Fixes. Um nicht zu sagen, dass die Benachrichtigung des Anbieters notwendigerweise schlecht ist, nur dass es wirklich leicht ist, eine Peitsche zu ziehen und so viel Schaden wie gut oder noch schlimmer zu verursachen.

In unserem Fall hat die IETF ( RFC 5746), um das Problem zu lösen, und obwohl wir an dem Tag, an dem es durchgesickert war, einen Internetentwurf fertig hatten, dauerte die eigentliche Debatte und Entscheidung über die Lösung noch etwa drei Monate und tat es nicht Fangen Sie wirklich ernsthaft an, bis die Offenlegung stattgefunden hat.

Wie auch immer, dies ist keine Antwort auf Ihre Frage, aber es ist eine der interessanteren Offenlegungsgeschichten, die mir bekannt sind. Mehr zu dieser Geschichte in der 2010 ShmooCon Keynote, die ich mit Marsh Ray gemacht habe, der das Problem entdeckt hat.

Im Allgemeinen hängt es von der Reaktion des Anbieters ab. Eine gute Praxis ist, wenn der Sicherheitsforscher den Anbieter über die Sicherheitsanfälligkeit informiert und Sie dann während des Gesprächs über die Bedingungen für die Veröffentlichung von poc / Exploit dieser Sicherheitsanfälligkeit sprechen. Tatsächlich entscheiden die Forscher, was mit dieser Sicherheitsanfälligkeit geschehen soll - später veröffentlichen oder nicht. Dann veröffentlicht der Anbieter einen Patch oder eine neue Produktversion. Vielleicht. Aber wie die Erfahrung zeigt - nicht alle Anbieter sind so nett. Einige von ihnen beheben Fehler stillschweigend, ohne Endbenutzer und Forscher zu informieren, andere ziehen es vor, Forscher zu ignorieren. Andere versuchen sogar zu klagen. Aus diesem Grund ist Anonymität manchmal die bevorzugte Art der anfänglichen Kommunikation mit einem unbekannten Anbieter.

Außerdem möchte ich zugeben, dass es Prämienprogramme für Bug Bounty gibt - diese werden von Google, Mozilla, angeboten. Außerdem kaufen andere Schwachstellen - ZDI, iDefense, SNOsoft, kommender "Exploit Hub" usw. Es gibt also mindestens drei Möglichkeiten Informationen zum Informieren des Anbieters - direkt durch Veröffentlichen von Schwachstelleninformationen auf einer Liste oder über Drittanbieter.

Wenn sie einen öffentlichen Issue-Tracker haben, prüfen Sie, ob Sie einen Fehler mit einem "privaten" oder "Sicherheits" -Label melden können.

Unabhängig davon, ob sie einen Issue-Tracker haben, senden Sie eine E-Mail an security @ Firmenname und lassen Sie es sie wissen.

Wenn sie nicht ziemlich schnell antworten (siehe "Fenster der Offenlegung" im Schneier-Artikel unten), müssen Sie nachdenken darüber, es weiter zu offenbaren. Suchen Sie nach Mailinglisten, auf denen Sicherheitswissenschaftler lauern, und fragen Sie sie, wie sie dem betreffenden Anbieter Probleme melden. Möglicherweise können sie sich an der richtigen Stelle in der Organisation vorstellen.

Wenn dies alles fehlschlägt, lesen Sie das Schneier-Bit und überlegen Sie, ob eine vollständige Offenlegung Teil des Problems oder Teil der Lösung wäre.

Bruce Schneier gibt unter bestimmten Umständen ein Argument für die vollständige Offenlegung an, das auf dem Standard "Teil der Lösung sein, nicht Teil des Problems" basiert. Es ist definitiv eine Lektüre wert.

Dies ist die klassische Debatte "Fehlergeheimnis vs. vollständige Offenlegung". Ich habe bereits in Crypto-Gram darüber geschrieben. andere haben auch darüber geschrieben. Es ist ein kompliziertes Problem mit subtilen Auswirkungen auf die gesamte Computersicherheit, und es lohnt sich, es noch einmal zu diskutieren.

...

Dieser freie Informationsfluss, sowohl der Beschreibung als auch des Proof-of-Concept Code ist auch für die Sicherheitsforschung von entscheidender Bedeutung. Forschung und Entwicklung im Bereich Computersicherheit haben in den letzten zehn Jahren zugenommen, und ein Großteil davon ist auf die Bewegung zur vollständigen Offenlegung zurückzuführen. Die Möglichkeit, sowohl gute als auch schlechte Forschungsergebnisse zu veröffentlichen, führt zu einer besseren Sicherheit für alle. Ohne Veröffentlichung kann die Sicherheitsgemeinschaft nicht aus den Fehlern des anderen lernen. Jeder muss mit Scheuklappen arbeiten und immer wieder die gleichen Fehler machen. Eine vollständige Offenlegung ist unerlässlich, um die Sicherheit unserer Computer und Netzwerke weiter zu verbessern.

...

Zweitens glaube ich daran, den Verkäufer im Voraus zu benachrichtigen. CERT hat dies auf ein Extrem gebracht und dem Anbieter manchmal Jahre Zeit gegeben, um das Problem zu beheben.

...

Ich mag das "Teil der Lösung sein, nicht Teil des Problems". metrisch. Sicherheitsforschung ist Teil der Lösung. Anbieter davon zu überzeugen, Probleme zu beheben, ist Teil der Lösung. Angst zu säen ist ein Teil des Problems. Die Übergabe von Angriffswerkzeugen an ahnungslose Jugendliche ist Teil des Problems.