Debian/Sicherheit
Software-Sicherheit
Softwareprobleme werden öffentlich behandelt, so auch sämtliche Sicherheitsprobleme. Aspekte der Sicherheit werden öffentlich auf der debian-security-announce-Mailingliste diskutiert. Debians Sicherheitsgutachten werden über eine öffentliche Mailingliste gesendet (sowohl innerhalb als auch außerhalb) und auf einem öffentlichen Server bekanntgegeben. Von dieser Verfahrensweise verspricht man sich ein schnelleres Auffinden von Sicherheitslücken und damit die Möglichkeit, diese eher beheben zu können. Die entgegengesetzte Herangehensweise des Security through obscurity wird dagegen als unpraktikabel angesehen. Die Tatsache, dass die Weiterentwicklung der Distribution öffentlich sichtbar unter Beteiligung einer Vielzahl von Personen geschieht, erfordert besondere Sicherheitsmaßnahmen. Beispielsweise werden Änderungen an Paketen grundsätzlich mit einem verifizierbaren Schlüssel digital signiert. Beim Anwender wird dann vor der Installation die Gültigkeit der Signatur überprüft. Diese Maßnahme soll es Dritten erschweren, schädliche Software in Debian-Pakete einzuschleusen.
Die Paketbetreuer passen die Sicherheitsaspekte ihrer jeweiligen Software an die allgemeinen Grundsätze von Debian an. Daher sind Dienste nach der Installation oft „sicher“ voreingestellt, was von einem Benutzer als „Einschränkung“ empfunden werden kann. Dennoch versucht Debian, Sicherheitsaspekte und einfache Administration abzuwägen. Zum Beispiel werden Dienste wie ssh und ntp nicht inaktiv installiert, wie es bei den Distributionen der BSD-Familie üblich ist.
Wenn ein Sicherheitsproblem in einem Debian-Paket entdeckt wurde, wird es zusammen mit einer Einschätzung der dadurch entstehenden Gefahr direkt veröffentlicht. Parallel wird so schnell wie möglich ein Sicherheitsupdate dieses Pakets vorbereitet und auf speziellen Servern veröffentlicht. Kritische Sicherheitslücken werden auf diese Weise häufig innerhalb von Stunden geschlossen.
Die von Debian angepasste Implementierung des für die Schlüsselerstellung zuständigen Zufallsgenerators der OpenSSL-Bibliothek arbeitete von September 2006 bis 13. Mai 2008 mit einer erheblichen Sicherheitslücke. Die generierten geheimen Schlüssel konnten abgeschätzt und damit in kurzer Zeit (vor-)berechnet werden (1024- und 2048-Bit-Schlüssel in ungefähr zwei Stunden). Insbesondere OpenSSH und die sichere Kommunikation in Webbrowsern waren davon betroffen – GnuPG hingegen nicht.
Das Sicherheitsrisiko besteht weiterhin für alle RSA-Schlüssel, die in diesem Zeitraum auf betroffenen Systemen erstellt wurden und seit der Aktualisierung der Bibliothek nicht neu erstellt wurden. Auch alle DSA-Schlüssel, die jemals von einem Rechner (Client) mit fehlerhaftem Zufallszahlengenerator verwendet wurden, sind seitdem unsicher, selbst wenn diese ursprünglich auf einem Rechner mit korrekt arbeitendem Zufallszahlengenerator erstellt wurden.[1][2]
Im Januar 2019 wurde in dem Paketmanagertool von Debian („apt“ bzw. „apt-get“) eine Sicherheitslücke entdeckt, die es einem Man-in-the-Middle-Angreifer ermöglichte Code bei einem Update auszuführen. Der Entdecker dieser Sicherheitslücke plädierte, auch vor dem Hintergrund, dass dies nicht die einzige Sicherheitslücke mit diesen Auswirkungen in apt war,[3] und solche Lücken immer passieren können, dafür, dass Debian in Zukunft standardmäßig HTTPS für Updates mit apt statt HTTP nutzt, da HTTPS die Integrität der gesamten Kommunikation mit dem Update-Server absichert.[4] Dies wurde in der Vergangenheit mit dem Hinweis abgelehnt, dass apt selbst eine Verifizierung der Pakete vornimmt[5] was soweit auch korrekt ist, allerdings würde es bei Sicherheitslücken wie dieser dennoch zu einem Sicherheitsgewinn kommen, da die Sicherheitslücke dann nicht mehr von allen Man-in-the-Middle-Angreifern, die in die Verbindung eingreifen können, ausnutzbar ist, sondern nur noch von den jeweils gewählten Debian-Update-Mirrors des Gerätes.[6]