Leiten einer Sicherheitsüberprüfung

Diese Seite enthält eine grobe Übersicht von Schritten, die notwendig sind, um ein Paket einer Sicherheitsüberprüfung zu unterziehen.

Die erste Handlung sollte sein, ein Paket auszuwählen. Hierbei sollte man sich auf möglichst sicherheitskritische Pakete konzentrieren.

Um diese Entscheidung zu vereinfachen führen wir eine Liste von Paketen, bei denen wir eine Prüfung für wichtig halten.

Bitte beachten Sie: Wir versuchen nicht sicherzustellen, dass ein Paket nur einmal geprüft wird. Wenn mehrere Personen ein Paket auf seine Sicherheit prüfen, ist dies eine gute Sache und ein Indiz dafür, dass das Paket sicherheitskritisch ist.

Indem wir eine wahllose Auswahl der Pakete erlauben, eliminieren wir das Problem, uns die Frage stellen zu müssen, inwiefern man einer Person vertrauen kann, dass sie eine gute Überprüfung durchführt (früher oder später wird eine andere Person das selbe Paket einer Überprüfung unterziehen).

Starten der Sicherheitsüberprüfung

Nachdem das Paket ausgewählt wurde, ist es an der Zeit die Überprüfung durchführen.

Falls man sich der Probleme, nach denen man sucht, nicht bewusst ist, so empfiehlt es sich, zuerst ein Buch über die sichere Entwicklung von Software zu lesen.

Das Sichere Programmierung für Linux und Unix HOWTO enthält viele Informationen, die hilfreich sein können. Secure Coding: Principles & Practices von Mark G. Graff und Kenneth R. van Wyk ist ebenfalls ein exzellentes Buch.

Auch wenn Hilfsprogramme nicht perfekt sind, können sie extrem hilfreich sein womögliche Verwundbarkeiten aufzuspüren. Hierzu haben wir eine Liste von Hilfsprogrammen zusammengestellt und wir erklären, wie sie verwendet werden.

Ebenso wie das Lesen des Quellcodes ist es auch eine gute Idee die Dokumentation des Paketes anzusehen sowie es zu installieren und zu benutzen.

Dies erlaubt es, sich eine Vorstellung davon zu machen, wie man das Programm in seinem typischen Einsatzumfeld missbrauchen könnte.

Probleme berichten

Findet man einen Fehler, so ist es wichtig auf diesen aufmerksam zu machen. Wenn Sie ein Sicherheitsproblem melden, versuchen Sie auch einen Patch dafür bereitzustellen, so dass die Entwickler das Problem zeitnah beheben können. Es ist nicht notwendig, ein Angriffsbeispiel beizusteuern (oft exploit oder proof of concept genannt); da der Patch für sich selbst sprechen sollte, ist es für gewöhnlich besser die Zeit aufzuwenden einen angemessenen Patch bereitzustellen, als einen erfolgreichen Angriff zur Ausnutzung des Fehlers beizusteuern.

Hier ist eine Liste der empfohlenen Schritte, sobald Sie eine Sicherheitslücke in Debian gefunden haben:

  1. Versuchen Sie einen Patch zum Fehler zu erstellen oder ausreichende Informationen zu beziehen, so dass andere das Vorhandensein des Fehlers überprüfen können. Im Idealfall sollte jeder Bericht einen von Ihnen erstellten Lösungsvorschlag beinhalten, der das Problem behebt sowie ausreichend getestet wurde.

    Sollten Sie über keinen Lösungsvorschlag verfügen, ist es nützlich, möglichst viele Informationen bezüglich des Problems, seiner relativen Schwere und Vorschlägen, wie man es umgehen kann, bereitzustellen.

  2. Überprüfen Sie zuerst, ob der Sicherheitsfehler in der Stable Debian-Veröffentlichung enthalten ist oder ob er eventuell in anderen Distributionen oder in einer von den Ursprungsautoren bereitgestellten Version enthalten ist.
  3. Berichten Sie die Angelegenheit basierend auf dieser Überprüfung:
    • An den Ursprungsbetreuer der Software via deren Kontakt-E-Mail-Adresse zu Sicherheitsfragen, stellen Sie Ihre Analyse und den Patch bereit.
    • An das Debian-Sicherheitsteam, falls der Fehler in einer veröffentlichten Debian-Version enthalten ist. Das Debian-Sicherheitsteam wird der Verwundbarkeit üblicherweise einen CVE-Namen zuweisen. Das Sicherheits-Team wird die – sollte es nötig sein – Koordination mit anderen Linux-Distributionen übernehmen und die Paketverwalter in Ihrem Interesse kontaktieren. Sie können jedoch eine Kopie Ihrer Mail auch an den Paketbetreuer senden. Tun Sie dies nur, wenn Sie Verwundbarkeiten geringeren Risikos handhaben (siehe weiter unten).
    • Wenn der Fehler in keiner veröffentlichten Debian-Version enthalten ist, die Anwendung aber in anderen Distributionen oder Betriebssystemen enthalten sein mag, dann senden Sie eine E-Mail (englisch) an vendor-sec (eine private Mailingliste, die von den meisten Distributionen Freier Software zur Diskussion von Sicherheitsproblemen verwendet wird). Dies brauchen Sie nicht zu tun, wenn Sie den Fehler bereits an das Debian-Sicherheitsteam berichtet haben, da das Team den Fehler an diese Liste weiterleiten wird.
    • Wenn der Fehler in keiner veröffentlichten Debian-Version enthalten ist und Sie sich absolut sicher sind, dass die Anwendung in keine anderen Distribution oder Betriebssystem aufgenommen wurde, dann berichten Sie ihn mittels der Fehlerdatenbank (Bug Tracking system).
  4. Sobald die Verwundbarkeit öffentlich gemacht wurde (z.B. sobald das Debian-Sicherheitsteam oder jemand anders eine Ankündigung herausgegeben hat), sollte ein Fehler mit all den relevanten Informationen in der Debian-Fehlerdatenbank (Bug Tracking System) eingereicht werden, auf dass das Sicherheitsproblem in unveröffentlichten Debian-Versionen (z.B. Sid oder Testing) verfolgt werden kann. Dies wird für gewöhnlich vom Sicherheits-Team selbst erledigt, aber wenn Sie bemerken, dass dies nicht erfolgt ist, oder Sie dies nicht an das Sicherheits-Team berichtet haben, dann können Sie den Fehler selbst berichten. Stellen Sie sicher, dass Sie den Fehler mit den richtigen Markierungen versehen (verwenden Sie die Markierung security) und dass Sie eine angemessene Schwere setzen (gewöhnlich grave oder höher). Stellen Sie außerdem sicher, dass der Fehler den passenden CVE-Namen in seinem Namen trägt, wenn ein solcher zugewiesen wurde. Auf diese Weise können Sicherheitsfehler verfolgt werden, so dass sie sowohl in den veröffentlichten als auch in den unveröffentlichten Debian-Versionen behoben werden.
  5. Sobald die Angelegenheit öffentlich ist, und falls Sie es wünschen, können Sie diese Informationen an öffentliche full disclosure- (Offenlegungs)-Mailinglisten wie z.B. full-disclosure oder Bugtraq weiterleiten.

Beachten Sie, dass all diese Schritte von dem mit einer entdeckten Verwundbarkeit verbundenen Risiko beeinflusst werden. Sie müssen das Risiko basierend auf den folgenden Punkten einschätzen:

Es sollten beispielsweise unterschiedliche Maßnahmen ergriffen werden, um einen lokalen Symlink-Angriff zu berichten, der nur von authentifizierten Benutzern ausgenutzt werden kann und das System nur schädigt, im Vergleich zu einem entfernt ausnutzbaren Pufferüberlauf, der administrative Privilegien bereitstellt und in einer Software mit hohem Verbreitungsgrad enthalten ist.

Da sicherheitskritische Fehler nicht veröffentlicht werden sollten, bevor sie nicht ausgemerzt wurden, sollten Sie nicht auf dem üblichen Weg (über die Debian-Fehlerdatenbank) von diesen Fehlern berichten, sondern in den meisten Fällen wenden Sie sich zuerst direkt an das Sicherheits-Team, welches sich der Veröffentlichung eines aktualisierten Pakets annehmen wird und, sobald der Fehler behoben ist, diesen an das BTS berichten wird.