{"id":1290,"date":"2010-06-07T21:57:16","date_gmt":"2010-06-07T20:57:16","guid":{"rendered":"http:\/\/www.mitternachtshacking.de\/blog\/1290-vulnerability-disclosure"},"modified":"2018-05-31T21:11:13","modified_gmt":"2018-05-31T20:11:13","slug":"vulnerability-disclosure","status":"publish","type":"post","link":"https:\/\/www.mitternachtshacking.de\/blog\/1290-vulnerability-disclosure","title":{"rendered":"Vulnerability Disclosure"},"content":{"rendered":"

Fr\u00fcher gab es ja immer die Diskussion, ob und wie Sicherheitsl\u00fccken ver\u00f6ffentlicht werden sollen. Da gab es im gro\u00dfen und ganzen drei Schulen:<\/p>\n

1. No Disclosure<\/em><\/p>\n

No Disclosure bedeutet, man h\u00e4lt die L\u00fccke einfach f\u00fcr sich selbst geheim. Kann\u00c2\u00a0 man immer mal brauchen. Mit dem Risiko, dass nat\u00fcrlich jemand anderes die L\u00fccke auch findet. No Disclosure war fr\u00fcher typisch bei Schadprogrammautoren. Wenn die mal eine L\u00fccke hatten, wurden damit Schadprogramme verbreitet und irgendwann \u00fcber Projekte wie das Honeynet wurde dadurch die L\u00fccke irgendwann bekannt und gestopft.<\/p>\n

2. Responsible Disclosure<\/em><\/p>\n

Das war der Begriff den Firmen wie Microsoft gepr\u00e4gt haben, die Sicherheitsl\u00fccken am liebsten vertuscht haben. Mit Responsible Disclosure sollte eine Sicherheitsl\u00fccke nur dem Hersteller bekanntgegeben werden damit dieser dann beliebig lange Zeit hat die L\u00fccke zu beheben. Ein paar Firmen wollten daraus sogar einen Standard<\/a> (RFC) machen, der aber gl\u00fccklicherweise dann nicht in den Standard<\/a> aufgenommen wurde. Firmen wie eEye konnten zeigen, dass sich Microsoft bei „responsible“ bekanntgegebenen L\u00fccken sehr viel l\u00e4nger Zeit l\u00e4sst, diese zu beheben. In der Praxis hat sich eine Art Responsible Disclosure durchgesetzt, weil die Sicherheitsfirmen halt auf Auftr\u00e4ge der gro\u00dfen Softwarehersteller angewiesen sind.<\/p>\n

3. Full Disclosure<\/em><\/p>\n

Sicherheitsl\u00fccken, m\u00f6glicherweise inkl. Exploit werden auf einer \u00f6ffentlichen Webseite oder Mailingliste bekanntgegeben und stehen damit Softwarefirmen genauso wie Angreifern direkt und gleichzeitig zur Verf\u00fcgung. Ein Softwarehersteller muss dann nat\u00fcrlich schnell reagieren und einen Patch bereitstellen der m\u00f6glichst keine Nebeneffekte haben darf d.h. unter Zeitdruck sorgf\u00e4ltig entwickelt und getestet werden muss.<\/p>\n

Heute muss man meiner Ansicht nach andere Kriterien anwenden:<\/p>\n

1.\u00c2\u00a0 Free Disclosure<\/em><\/p>\n

Sicherheitsl\u00fccken bzw. Exploits werden (egal wann) auf einer kostenfreien Webseite oder Mailingliste bereitgestellt. Namentlich kann man SecurityFocus oder Metasploit nennen.<\/p>\n

2. Disclosure \u00fcber einen Exploit Broker<\/em><\/p>\n

Eine Reihe von Agenturen kaufen Sicherheitsl\u00fccken von Entwicklern auf und geben diese dann an den Herstellern weiter.\u00c2\u00a0 ZDI<\/a> (TippingPoint\/3Com\/HP), iDefense<\/a> (Verisign) und Co. sind hier zu nennen. Ein Exploit Broker hat den Vorteil, dass man mit einem Exploit Geld verdienen kann, jedoch praktisch kein Risiko eingeht, wegen dieses Exploits auch verklagt zu werden. Gerade f\u00fcr einzelne Programmierer ist das eine brauchbare Alternative.<\/p>\n

3. Kommerzielle Exploit-Software<\/em><\/p>\n

Neben ZDI\/iDefense gibt es auch Firmen wie Core oder Immunity, die Sicherheitsl\u00fccken z.B. von freiberuflichen Exploitentwicklern kaufen und in ihre kommerziellen Frameworks mit aufnehmen. Dazu gibt es sogar eine „No more free bugs“ Initiative.<\/p>\n

Mein Eindruck ist, dass sich der Trend zu kommerziell vermarkteten Sicherheitsl\u00fccken in den n\u00e4chsten Jahren verst\u00e4rken wird. Das wird dazu f\u00fchren, dass nur noch gro\u00dfe finanzkr\u00e4ftige Firmen sich alle notwendigen Sicherheitsl\u00fccken z.B. f\u00fcr Penetrationstests zusammenkaufen k\u00f6nnen. Ob das eine w\u00fcnschenswerte Entwicklung ist, will ich mal offen lassen.<\/p>\n

Literatur zum Nachlesen:<\/p>\n