Der Debian-Hack und Informationspolitik

Security by Obscurity -- also Sicherheit durch Verschleierung -- funktioniert nicht. Den jüngsten Beleg für diesen Leitsatz vieler Sicherheitsexperten lieferte ausgerechnet das Open-Source-Betriebssystem Linux

In Pocket speichern vorlesen Druckansicht
Lesezeit: 3 Min.

Security by Obscurity - also Sicherheit durch Verschleierung - funktioniert nicht. Den jüngsten Beleg für diesen Leitsatz vieler Sicherheitsexperten lieferte ausgerechnet das Open-Source-Betriebssystem Linux - eigentlich ein Inbegriff der Offenheit: Offener Code, offene Weiterentwicklung, offene Informationspolitik. Eigentlich! Aber gerade bei der Weiterleitung von sicherheitsrelevanten Informationen hakt es mittlerweile gewaltig.

Bereits im September wurde ein Bug im Linux-Kernel entdeckt, der Zugriff auf den Adressraum des Betriebssystemkerns und damit volle Kontrolle des Systems erlaubt. Der Patch war vermutlich wenige Tage - vielleicht sogar Stunden - später fertig, spätestens in 2.6test6, das am 28. September erschien, war das Problem behoben. Für den Main-Stream-Kernel 2.4 gibt es seit einigen Tagen die bereinigte Version 23. Doch wo waren die fälligen Security-Advisories?

Die Kernel-Entwickler reden sich darauf hinaus, Advisories seien Sache der Distributoren. Die Distributoren hingegen haben das Problem, dass die Kernel-Entwickler ihre Fehler mehr oder weniger stillschweigend beseitigen und potenziell sicherheitskritische Probleme nicht oder nur unzureichend dokumentieren. Weder in den Patches zu test6 noch zu 2.4.23 finden sich aussagekräftige Beschreibungen zu diesem Fehler. Die Kernel-Entwickler haben natürlich anderes um die Ohren, als sich bei jedem Fehler im Code, den sie beseitigen, Gedanken darüber zu machen, ob und wie man ihn ausnutzen könnte. So war den Debian- und vermutlich auch den Red-Hat-Entwicklern das Potenzial des Sicherheitsproblems in der do_brk-Funktion nicht bekannt.

Es ist jedoch wenig sinnvoll, jetzt schwarze Peter hin- und herzuschieben; gefordert sind jetzt alle. Denn es ist klar, dass sich an der Art und Weise, wie die Linux-Gemeinde mit (potenziellen) Sicherheitsproblemen im Kernel umgeht, etwas ändern muss. Wir brauchen nicht nur zeitnahe Patches sondern auch (wieder) eine offenere Informationspolitik. Der Debian-Hack hat gezeigt: Im Moment kann sich jeder, der die Zeit und Mühe investiert, die Kernel-Entwicklung zu verfolgen, seinen privaten Zero-Day-Exploit zusammenbasteln, den kein Sys-Admin kennt.

Da das System, die Information der Öffentlichkeit allein den Distributoren zu überlassen, so nicht funktioniert, sollten sich Linus Torvalds und Andrew Morton überlegen, ob sie nicht einen Sicherheitsbeauftragten brauchen. Seine Aufgabe wäre es, unter Mithilfe der jeweiligen Maintainer alle Änderungen im Linux-Kernel auf Security-Relevanz zu überprüfen. Außerdem hätte er sicherzustellen, dass frühzeitig aussagekräftige Informationen über potenzielle Sicherheitsprobleme an die Distributoren und dann auch an die Öffentlichkeit gehen. Und egal ob mit oder ohne Linux Security Officer: Wir müssen wieder gezielter und offener über (potenzielle) Sicherheitsprobleme im Linux-Kernel diskutieren -- auch wenn das manchmal Negativ-Schlagzeilen bringt. (Jürgen Schmidt)

PS: Bereits im April wurde die Herausgabe eines wichtigen Security-Advisories für den Linux-Kernel "vergessen", das dann erst Monate später erschien. Auch hier hätte die koordinierende Hand eines Sicherheitsbeauftragten für rechtzeitige Information der Betroffenen sorgen können. Siehe auch: Wann veröffentlichen? (ju)