![[OpenBSD]](../images/smalltitle.gif){kind=small}
| Index | |
|
Sicherheitsziele des Projektes. Komplette Enthüllungspolitik. Quelltextprüfungsprozess. »standardmäßig sicher« Benutzung von Kryptographie.
Veränderungen beobachten.
|
Für Sicherheitshinweise von bestimmten Releases klicke hier: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 4.0. |
OpenBSD glaubt an starke Sicherheit. Wir streben danach, die NUMMER EINS in der Industrie in Sachen Sicherheit zu sein (wenn wir es nicht schon sind). Unser Open-Software-Entwicklungsmodell erlaubt uns, einen kompromissloseren Blickwinkel hinsichtlich Sicherheit zu haben als es Sun, SGI, IBM, HP und anderen Herstellern möglich ist. Wir können Änderungen machen, die große Hersteller nicht machen würden. Und da OpenBSD mit Kryptographie exportiert wird sind wir in der Lage, kryptographische Ansätze zu wählen, um Sicherheitsprobleme zu lösen.
Wie auch viele Leser der BUGTRAQ-Mailingliste glauben wir an komplette Enthüllung von Sicherheitsproblemen. Im Bereich der Betriebssysteme waren wir wahrscheinlich die ersten, die dieses Konzept verwirklicht haben. Viele Hersteller - selbst von freier Software - versuchen immer noch, Probleme vor ihren Benutzern zu verstecken.
Sicherheitsinformationen bewegen sich sehr schnell in Crackergruppierungen. Auf der anderen Seite ist es unsere Erfahrung, dass es typischerweise etwa einer Stunde Arbeit bedarf, um eine saubere Lösung zu programmieren und zu veröffentlichen - somit ist eine sehr schnelle Reaktion möglich. Daher glauben wir, dass eine komplette Enthüllung Personen hilft, die sich wirklich um Sicherheit Gedanken machen.
Unser Sicherheitsprüfungsteam besteht üblicherweise aus sechs bis zwölf Mitgliedern, die fortwährend nach Sicherheitslücken suchen und diese beseitigen. Wir suchen und prüfen seit dem Sommer 1996. Der Prozess, den wir verfolgen, um die Sicherheit zu erhöhen, ist prinzipiell eine einfache Datei-für-Datei-Analyse jeder kritischen Softwarekomponente. Wir suchen nicht so sehr nach Sicherheitslücken als vielmehr nach allgemeinen Softwarefehlern; und wenn Jahre später jemand ein Problem entdeckt, das eine Sicherheitslücke war, die von uns aber schon beseitigt wurde, weil es einfach ein Fehler war, dann umso besser. Diese Fehler wurden in nahezu allen Bereichen des Systems gefunden. Ganz neue Klassen von Sicherheitsproblemen wurden während unserer Überprüfungen gefunden, und oftmals muss bereits geprüfter Quelltext noch einmal auf diese neuen Probleme hin überprüft werden. Quelltext wird oftmals viele Male geprüft und das noch von verschiedenen Leuten mit verschiedenen Prüfungsfertigkeiten.
Manche unseres Sicherheitsprüfungsteams haben für Secure Networks gearbeitet; der Firma, die das erste Netzwerksicherheitsscanningprodukt in der ganzen Industrie namens Ballista gemacht hat (Secure Networks wurde von Network Associates aufgekauft und von Ballista in Cybercop Scanner umgetauft, na ja ...). Diese Firma hat eine Menge Sicherheitsforschung betrieben und passt daher gut zum OpenBSD-Standpunkt. OpenBSD hat Ballistas Test seit dem ersten Tag mit fliegenden Fahnen bestanden.
Eine weitere Facette des Prozesses unserer Sicherheitsüberprüfungen ist seine vorausschauende Art und Weise. Wir haben herausgefunden, dass in den meisten Fällen die Möglichkeit, einen Fehler auszunutzen, nicht gegeben ist. Während unserer fortwährenden Überprüfungen finden wir viele Softwarefehler und beseitigen diese, obwohl deren Ausnutzbarkeit nicht bewiesen ist. Wir beseitigen den Fehler und suchen nach weiteren, die beseitigt werden müssen. Wir haben viele einfache und offensichtliche Programmierfehler beseitigt, um Monate später festzustellen, dass diese Fehler tatsächlich ausnutzbar gewesen wären. (Oder noch wahrscheinlicher würde jemand auf BUGTRAQ berichten, dass andere Betriebssysteme auf ein »neu entdecktes Problem« hin anfällig wären und dass das Problem in OpenBSD schon seit dem vorherigen Release nicht mehr besteht.) In anderen Fällen wurden wir vor kompletter Ausnutzbarkeit komplexer Schritt-für-Schritt-Angriffe bewahrt, weil wir einen der Zwischenschritte undurchführbar gemacht haben, als wir einen Fehler beseitigt hatten. Ein Beispiel für einen solchen Erfolg ist die Lpd-Warnung, die Secure Networks herausgebracht hat.
Wenn wir Quelltext begutachten, erfinden wir oft neue Wege, Probleme zu lösen. Manchmal wurden diese Ideen schon vorher in einer beliebigen Anwendung irgendwo benutzt, aber vielleicht nicht in dem Grad, wie wir es tun.
Unser vorausschauender Überprüfungsprozess hat sich ausgezahlt. Stellungnahmen wie »Dieses Problem wurde in OpenBSD vor 6 Monaten beseitigt« sind in Sicherheitsforen wie BUGTRAQ schon Normalität geworden.
Der intensivste Teil unserer Sicherheitsüberprüfungen fand unmittelbar vor der Veröffentlichung vom OpenBSD-2.0-Release und während der Entwicklungsphase von 2.0 nach 2.1 statt, das heißt während des letzten Drittels von 1996 und der ersten Hälfte von 1997. Tausende(!) sicherheitsrelevante Fehler wurden schnell in diesem Zeitraum beseitigt; Fehler wie der Standardpufferüberlauf, Schwächen in der Implementierung von Protokollen, unberechtigtes Sammeln von Daten und Dateisystemraces. So wurden die meisten Sicherheitsprobleme vor dem 2.1-Release beseitigt - und dann noch einmal eine geringe Anzahl bis zum 2.2-Release. Wir finden jetzt nicht mehr so viele Probleme: es ist jetzt einfach eine Sache wiederkehrender Gewohnheiten. Neuerdings sind die Probleme, die wir finden, aber immer obskurer oder komplizierter. Trotzdem machen wir aus einer Reihe von Gründen weiter:
Der Überprüfungsprozess ist noch nicht vorbei und wie man sehen kann finden und beseitigen wir weiterhin Sicherheitsprobleme.
Um sicherzustellen, dass neue Benutzer von OpenBSD nicht über Nacht Sicherheitsexperten werden müssen (ein Standpunkt, den andere Systeme anscheinend haben), liefern wir unser Betriebssystem standardmäßig sicher aus. Alle nicht essentiellen Dienste sind deaktiviert. Sobald der Benutzer/Administrator vertrauter mit dem System ist wird er entdecken, dass er Daemons und andere Teile des Systems aktivieren muss. Während des Lernprozesses, wie man einen neuen Dienst aktiviert, wird der Anfänger eher die sicherheitsrelevanten Dinge lernen.
Dies ist ein starker Kontrast zu der wachsenden Zahl von Systemen, die mit laufendem NFS, mountd, Webservern und verschiedenen anderen Diensten ausgeliefert werden, was zu sofortigen Sicherheitsproblemen für ihre Benutzer innerhalb von Minuten nach der ersten Installation führt.
Und da das OpenBSD-Projekt in Kanada beheimatet ist, ist es uns möglich, Kryptographie ins das System zu integrieren. Um mehr Informationen zu erhalten, lies die Seite, die zeigt, was wir mit Kryptographie angefangen haben.
OpenBSD 3.8 und frühere Versionen werden nicht länger unterstützt.
Die folgenden Absätze führen nur Sicherheitsupdates auf, die auftraten,
als das jeweilige Release noch unterstützt wurde. Es ist sehr
wahrscheinlich, dass diese Releases auch Sicherheitsupdates
späterer Versionen benötigen.
Da wir einen vorausschauenden Standpunkt in Bezug auf Sicherheit einnehmen, finden wir fortwährend neue Probleme und lösen sie. Nicht alle diese Probleme wurden großartig veröffentlicht, da (wie schon vorher beschrieben) viele von ihnen nicht als ausnutzbar bestätigt waren; viele einfache Fehler, die wir gelöst haben, haben Sicherheitskonsequenzen, die wir nicht vorhersagen konnten. Wir haben einfach nicht die Zeit, um diese Änderungen im oben verwandten Format zu veröffentlichen.
Deswegen gibt es sehr kleine Sicherheitskorrekturen im Current-Quelltext über das jeweils aktuelle OpenBSD-Release hinaus. Wir geben eine begrenzte Garantie, dass diese Probleme nur minimalen Einfluss haben und deren Ausnutzbarkeit nicht bewiesen ist. Sobald wir entdecken, dass ein Problem wirklich sicherheitsrelevant ist, gibt es hier SEHR schnell einen Patch.
Leute, die sich wirklich um Sicherheit kümmern, können ein paar Dinge tun:
Wenn du ein neues Sicherheitsproblem findest, maile es an
deraadt@openbsd.org.
Wenn du es mit PGP verschlüsseln möchtest (bitte nur dann, wenn
Privatsphäre dringend nötig ist), benutze diesen Schlüssel:
pgp key.
Eine Reihe von Kurzabhandlungen wurden von Mitgliedern des OpenBSD-Teams über sicherheitsbezogene Änderungen in OpenBSD geschrieben. Die Postscript-Versionen dieser Dokumente sind folgendermaßen verfügbar.
www@openbsd.org