Veröffentlichen, aber verantwortungsvoll: Responsible Disclosure

Von Dr. Jörg SchneiderSchwachstelle

Findet man eine Sicherheitslücke, dann sollte man sie verantwortungsvoll veröffentlichen (Responsible Disclosure). Aber was ist verantwortungsvoll – und wem gegenüber? In der Regel kommen ja verschiedene Interessenlagen zusammen: Die Nutzer der betroffenen Anwendung wollen so schnell wie möglich davon erfahren und hätten gern auch Details, um das Risiko und mögliche Gegenmaßnahmen bewerten zu können. Der Hersteller dagegen hätte gern einen zeitlichen Vorsprung, um vor dem öffentlichen Bekanntwerden bereits eine Lösung vorzubereiten. Das sind aber noch nicht alle Beteiligten im Spiel: Der Entdecker will eigentlich nicht viel zusätzliche Arbeit haben und unbezahlt die Qualitätssicherung für den Hersteller übernehmen. Da sich aber gefundene Sicherheitslücken auch gut im Lebenslauf machen, will er die Lücke möglichst schnell und öffentlichkeitswirksam publik machen. Die Angreifer freuen sich am meisten, wenn außer ihnen niemand oder nur wenige von der Lücke wissen, das Thema also möglichst spät und mit möglichst wenig Tamtam öffentlich wird.

Daher hat sich inzwischen ein Ablauf mit einer Vorwarnzeit für den Hersteller etabliert. Die Zeiträume variieren dabei – wir bei HiSolutions etwa planen in unserem Responsible-Disclosure-Prozess 90 Tage für die Reaktion des Herstellers ein. Falls mehrere Hersteller gleichzeitig betroffen sind, gibt es inzwischen auch etablierte Wege für eine koordinierte Veröffentlichung.

Diese Koordination ist bei der jüngst entdeckten SMTP-Smuggling-Lücke schiefgegangen. Die technischen Details zur Lücke und wer jetzt was patchen muss, hat mein Kollege Folker Schmidt in unserem Research Blog zusammengestellt.

Die Lücke wurde von Timo Longin von SEC Consult auf dem 37. Chaos Communication Congress vorgestellt. Die Hersteller der Mailserver, die in seinen Experimenten auffällig waren, wurden auch im Vorfeld informiert und reagierten teilweise direkt mit einer Lösung. Betroffen waren aber auch weitere Mailserverlösungen wie Postfix, deren Entwickler von der Veröffentlichung überrascht wurden und sehr schnell aktiv werden mussten. Eine Rekonstruktion, wie es dazu kommen konnte, wurde inzwischen im Blogpost von SEC Consult ergänzt.

Wenig später machte ein anderer Maintainer einer Open-Source-Software seinen Unmut öffentlich, diesmal jedoch nicht wegen ausbleibender Benachrichtigungen, sondern über viele unsinnige: Daniel Stenberg ist der ursprüngliche Entwickler und inzwischen Maintainer des Open-Source-Projects cURL, das von modernen Linux-Konsolen nicht mehr wegzudenken ist. In letzter Zeit häufen sich dort KI-generierte Meldungen von angeblichen Sicherheitslücken. Das Perfide daran ist, dass sie alle sehr schlüssig klingen und teilweise vorgebliche Exploits mitliefern. Erst beim Nachvollziehen im Sourcecode fällt dann auf dass der beschriebene Angriff gar nicht möglich ist. Halluzinationen sind ein bekanntes Problem von großen Sprachmodellen (LLM) und werden mit solchen halluzinierten Reports nun auch zu einem Problem für die Softwareentwickler.