OpenBSD: Seit 20 Jahren kontinuierlich besser

OpenBSD: Seit 20 Jahren kontinuierlich besser

Mit dem Release 5.8 veröffentlicht das OpenBSD-Projekt ein weiteres Mal eine Version seines Betriebssystems und damit auch die Grundlage für die nächsten Releases unserer Produkte. Wie in früheren Beiträgen beschrieben, setzen wir vor allem aus Sicherheitsgründen auf OpenBSD. Aber was hat das Projekt die letzten 20 Jahre gemacht, damit es als eines der sichersten Unix-artigen Betriebssysteme angesehen wird?

OpenBSD hat über die Jahre viele Mechanismen in seine Infrastruktur eingebaut, die dabei geholfen haben, Fehler in den eigenen und in fremden Programmen zu finden und zu beheben. Zudem setzt das Projekt auf möglichst einfache Programme, welche nur wenige Berechtigungen haben, um mögliche Programmierfehler und deren Ausnutzung als Sicherheitslücke zu vermeiden. Bei dieser Vorgehensweise besonders stringent zu sein, ist die Kerneigenschaft des OpenBSD-Projekts.

Warum gilt OpenBSD als sicheres Betriebssystem?

Über die Jahre sind immer wieder Funktionen ins System gekommen, die in erster Linie keinen direkten Mehrwert für den Benutzer gebracht haben, aber langfristig zur Stabilität und Sicherheit beitrugen.

Aufdecken von Programmfehlern

Um zu verstehen, was ein System sicher macht, muss man verstehen was Sicherheitslücken sind: Im Wesentlichen sind Sicherheitslücken nur Programmierfehler. Als klassisches Beispiel wird an dieser Stelle meist der Pufferüberlauf genannt. Bei einem Pufferüberlauf überschreibt eine laufende Anwendung die Grenzen eines reservierten Speicherbereichs. Dabei besteht immer die Gefahr, dass der Inhalt von angrenzenden Speicherbereichen überschrieben wird.

Dieses kann nun drei Auswirkungen für die laufende Anwendung haben:

  1. Im einfachsten Fall wird der angrenzende Speicherbereich im weiteren Programmverlauf nicht mehr verwendet und das Programm läuft normal weiter.
  2. Sollte der überschriebene Speicherbereich Text- oder Bildinformationen enthalten, wird diese verfälscht und der Benutzer bekommt eventuell eine ungewöhnliche Ausgabe seines Programms zu sehen oder es verhält sich nicht wie gewohnt. Für gewöhnlich lässt sich dieses merkwürdige Verhalten durch ein Neustarten des Programms beheben.
  3. Im schlimmsten Fall werden bei einem Pufferüberlauf Kontrollstrukuren oder Sprungadressen des Programms überschrieben. In den meisten Fällen, in denen das passiert, wird das Programm einfach abstürzen.

Die Sicherheit einer Anwendung ist im letzten Fall am meisten gefährdet. Denn nur wenn die Kontrollstrukturen mit zufälligen Werten überschrieben werden, stürzt ein Programm ab. Wenn allerdings ein Angreifer solche Bereiche gezielt mit eigenen Werten überschreibt, kann er bestimmen, was das Programm als nächstes macht und damit dessen Kontrolle übernehmen.

Dieses Beispiel zeigt, dass Programmfehler im Normalfall nicht einmal auffallen müssen, da sie fast keine Auswirkung auf das Programmverhalten haben. Aus diesem Grund unterlaufen auch erfahrenen Programmierern solche Fehler schon mal unbemerkt.

An dieser Stelle setzt das OpenBSD-Projekt an und versucht das Fehlverhalten eines Programm sichtbar zu machen. Denn nur wenn Programmfehler auffallen, werden sie auch behoben. Dafür wurden zum Beispiel die folgenden Mechanismen eingesetzt, welche im Fehlerfall einen Programmabsturz provozieren:

  •  malloc.conf
  •  Stack-Protection
  •  ASLR
  •  PIE

Andere Betriebssysteme verfolgen oft einen komplett anderen Ansatz und möchten Programmfehler weitgehend vor dem Benutzer verbergen. Dieser Ansatz soll dem Benutzer ein komfortables Gefühl bei der Verwendung seines Systems vermitteln. Bei der Verwendung von OpenBSD soll der Anwender hingegen unmittelbar mitbekommen, wenn etwas schiefgeht.

Keep it simple

Das OpenBSD-Projekt versucht aber nicht nur, bestehende Programmfehler aufzudecken, sondern auch Programmfehler zu vermeiden. Zum einen bei der Programmierung, zum anderen in der Anwendung durch den Benutzer. Eine große Fehlerquelle resultiert dabei aus der Komplexität. Ist der Quelltext eines Programms zu umfangreich oder zu sehr verschachtelt und verstrickt, wird er für einen einzelnen Programmierer schnell zu komplex. Und diese Komplexität führt dann schnell zu Fehlern, welche wiederum zu Sicherheitslücken führen.

Entwickler von genua sind seit langem in der Community von OpenBSD aktiv, so z. B. auch 2012 beim Hackathon am Starnberger See

Aus diesem Grund kommt es von Zeit zu Zeit vor, dass Programme noch einmal überarbeitet oder auch komplett neu geschrieben werden. An dieser Stelle wird dem OpenBSD-Projekt schnell das Not-Invented-Here-Syndrom unterstellt. Im Einzelnen kann diese Unterstellung schon mal zutreffen, aber in der Regel steht mehr dahinter. So wurde zum Beispiel das bekannte Programm sudo durch doas ersetzt. Grund dafür war, dass sudo eine sehr komplexe Konfiguration hat und eine sehr großen Umfang an Quelltext, welcher mit sehr hohen Rechten läuft.

Aus ähnlichen Gründen wurden über die Jahre einige Programme durch einfachere ersetzt. Die neu entstanden Programme haben dann nicht immer denselben Funktionsumfang wie die alten. Es wird meist gezielt auf eine 90-Prozent-Lösung gesetzt, um das Programm so einfach und damit auch so sicher wie möglich zu halten. Hier sind einige Programme ausgelistet, welche mit diesem Ansatz überarbeitet oder neu geschrieben wurden:

  • OpenNTPd
  • OpenBGPd
  • OpenHTTPd
  • OpenSMTPd
  • tftpd
  • identd
  • file
  • dhclient
  • pkg-config
  • LibreSSL

Benutzer, welche die letzten zehn Prozent der Features dennoch brauchen, können aber weiterhin ihre Programme über die Paketverwaltung installieren.

Schadensbegrenzung

Für den Fall, dass eine Sicherheitslücke doch mal von einem Angreifer ausgenutzt wird, wurden in die Infrastruktur von OpenBSD mehre Mechanismen eingebaut, die die Möglichkeiten des Angreifers stark einschränken.

So wird darauf geachtet, dass Programmcode mit den niedrigsten Rechten läuft, welche notwendig sind, um die aktuelle Aufgabe zu erfüllen. Oft brauchen Systemprogramme nur zur Initialisierung Systemrechte und können die eigentliche Abarbeitung von Anfragen auch mit Nutzerrechten erledigen. Gibt eine Anwendung nach der Initialisierung seine System-Rechte ab, kann ein potenzieller Angreifer nach der Übernahmen nur noch eingeschränkt auf dem System agieren.

Andere Systemprogramme brauchen z. B. nur für bestimmte Aktionen Systemrechte, aber für den Großteil ihrer Arbeit nicht. Diese Programme werden dann oft in zwei oder mehre Anwendungen aufgeteilt, welche mit unterschiedlichen Rechten laufen. Dabei wird darauf geachtet, dass der Teil, der mit Systemrechten läuft, möglichst klein und einfach im Verhältnis zu den anderen Teilen bleibt.

Diese und folgende anderen Techniken werden benutzt, um den potentiellen Schaden, den ein Angriff verursachen kann, so gering wie möglich zu halten. OpenBSD ist nicht das einzige Betriebssystem, welches die Techniken einsetzt, aber es setzt sie oft als erstes oder ziemlich strikt ein. So werden einige der Techniken in anderen Systemen optional gehandhabt oder nur zum Debugging verwendet, da man befürchtet, das bestehende Programme nicht mehr funktionieren würden. Das OpenBSD-Projekt fährt hier einen sehr strikten Kurs, indem es diese Techniken nicht optional, sondern produktiv einsetzt. Dadurch zwingt das System seine Programmierer und Benutzer, fehlerhafte Programme zu reparieren oder auszutauschen, wie beispielsweise bei der Portierung von OpenOffice. Derartige Techniken unter OpenBSD sind etwa:

  • strikteres chroot
  • pledge
  • Address Space Layout Randomization
  • Datenausführungsverhinderung

Fazit

Mit dieser Vorgehensweise versucht das Projekt seit 20 Jahren, schrittweise ein immer sichereres Betriebssystem zu schaffen. Die Kehrseite all dieser Anstrengungen ist der Verlust von Entwicklungszeit für neue Features. So wird beispielsweise der Multiprozessor-Nutzung des Kernels sowie ein schlechter Durchsatz bemängelt. In diesem Spannungsfeld zwischen neuen Features und Sicherheit steht das OpenBSD-Projekt mehr auf Seiten der Sicherheit. Denn im Gegensatz zu Systemen wie Linux, ist Sicherheit bei OpenBSD ein fundamentales Projektziel, während es bei Linux nur ein Ziel unter vielen ist.


Weitere Informationen zu diesem Thema:

 

Bildquelle: © OpenBSD


Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.