OpenBSD ist als sicheres Betriebssystem positioniert. In den letzten Monaten wurden jedoch eine Reihe von Sicherheitslücken im System gefunden. Daran ist natürlich nichts Außergewöhnliches. Obwohl einige Schwachstellen ziemlich ungewöhnlich sind. Man könnte sogar kritisch sagen. OpenBSD-Entwickler haben verschiedene Richtlinien zur Gewährleistung der Sicherheit. Hier sind zwei davon:

Fehler vermeiden;
Minimieren Sie das Fehlerrisiko.

Nicht alle sind sich einig, dass diese Prinzipien ausreichen, um sichere Systeme aufzubauen. Es scheint mir sinnvoll zu sein, zu untersuchen, ob der OpenBSD-Ansatz funktioniert oder ob er zunächst zum Scheitern verurteilt ist.

Zur Veranschaulichung habe ich nicht alle ausgewählt, sondern nur einige interessante Fehler, die versehentlich mit dem Thema unseres Gesprächs übereinstimmen.

libc auth

Die Auth- Funktionen führen Helfer ohne Argv-Prüfung aus. Bericht . Patch .

Dies ist ein auffallend einfacher Fehler, der jedoch während der Codeüberprüfung wahrscheinlich nicht allzu offensichtlich war. Es scheint mir teilweise der Grund für einige Verwirrung zu sein, wer für die Überprüfung der Eingabedaten verantwortlich ist. Sie können jede der drei beteiligten Komponenten aufrufen: ein Programm, eine Bibliothek oder login_passwd - und es ist vernünftig anzunehmen, dass jemand anderes dies überprüft. Am Ende denke ich, dass die Bibliothek für schuldig befunden wurde, weil für sie ein Patch erschien, aber für mich persönlich scheint der Code auf den ersten Blick nicht eindeutig falsch zu sein.

Ein interessanterer Teil der Geschichte ist, dass trotz des erwähnten libc-Fehlers die Funktion login_passwdIch wäre auf diese Weise nicht verwundbar, wenn es keinen anderen Fehler gäbe. Im Jahr 2001 wurde login_passwd neu geschrieben, um Kerberos zu unterstützen. Vielleicht haben sie dann die eigentliche Ursache des Fehlers vorgestellt. Ein Authentifizierungsangebot vom Typ Request-Response (wie im S / Key-System) gibt einen authentifizierten Status zurück, keine Stille. Viele Jahre später wurde der Kerberos-Code gelöscht, aber ein Teil des Codes zur Unterstützung blieb erhalten, ebenso wie der eingeführte Fehler.

Wenn der Kerberos-Code gründlich bereinigt würde, würde der Authentifizierungsfehler weiterhin bestehen bleiben (es gab einige andere verwandte Probleme beim Parsen von Argv), aber seine Wirkung würde sicherlich stark abnehmen.

Es ist nicht einfach, argv in einem Sicherheitskontext korrekt zu analysieren. Viele logische Tipps und Ansätze funktionieren hier nicht. Ich werde nur bemerken, dass diese Sicherheitsanfälligkeit danach aufgetaucht istEine weitere Diskussion des Problems mit Dateinamen unter Unix / Linux / POSIX , obwohl sich das führende Minus (Bindestrich) nicht wirklich auf den Dateinamen bezieht.

ld.so.

Ungültige Umgebungsvariablen wurden nicht aus dem ld.so- Code entfernt . Bericht . Patch .

So etwas wie ein Speicherfehler. Aber nein. Der Fehler besteht darin, den Erfolg einer Operation - das Aufteilen der Umgebungsvariablen - mit dem Löschen dieser Variablen zu verknüpfen. Sehr selbstsicher.

Natürlich werden Befürworter verschiedener Typisierungssysteme sicherstellen, dass sie diese Operationen in der richtigen Reihenfolge verarbeiten, aber nicht die Tatsache, dass dies hilfreich ist. C-Code stürzte nicht ab, weil keine Fehler behandelt wurden oder weil der Speicherzuordnungsfehler unsichtbar blieb.

ftp

ftp folgt Weiterleitungen zu lokalen Dateien. Bericht . Patch .

Der NetBSD-FTP-Umleitungsfehler ist seit langem ein typisches Beispiel für unkontrollierte Funktionen . Und hier nochmal der gleiche Fehler (zum Glück mit kleinen Konsequenzen)! Leute, na ja, sitzt zu Hause. Fügen Sie Ihren Programmen keine zusätzlichen Funktionen hinzu.

smtpd von

smtpd kann einige Absenderadressen nicht überprüfen. Bericht . Patch . Kommentar .

Ich denke, dass im Kommentar von Gilles alles gesagt ist, aber ich erinnere mich an den Hintergrund. Es war einmal, dass alle E-Mails für jeden Benutzer lokal in / var / mail gespeichert wurdenin mbox-Dateien. Dies ist nicht sehr cool, da die Gefahr eines Schadens besteht, wenn mua die E-Mail löscht, während mda eine neue liefert (ganz zu schweigen von anderen Problemen wie der Verzerrung des From-Felds). Daher muss die mbox-Datei gesperrt werden. Das Sperren eines Netzwerkdateisystems funktioniert jedoch nicht zuverlässig. Anstatt zu sperren, verwenden wir Sperrdateien. Sie müssen sich jedoch auf ein bestimmtes Blockierungsprotokoll einigen, da der Benutzer die mbox-Dateien besitzt und der Stamm selbst das Verzeichnis besitzt. Um die mbox-Datei tatsächlich zu ändern, müssen Sie daher jedes Mal die Hilfsfunktion setuid ausführen. Nun, das ist das erste Problem. Ein weiteres Relikt der alten Zeit sind die mda-Einstellungen, die nicht nur als Programm, sondern auch als Shell-Pipeline verwendet werden können. Die Leute verschreiben so etwasspam-assassin | mail.mdaund Sie können es nicht einfach weitergeben execve().

Es gibt viele Schwierigkeiten, die in der Vergangenheit verwurzelt sind. Und leider kann dieser problematische Code nicht einfach ersetzt werden. E-Mail wird vor langer Zeit verwendet, und sehr komplexe Systeme und Workflows werden auf dieser Grundlage erstellt. Daher ist es sehr schwierig, einfach einen Code auszuschneiden und einen neuen einzufügen. Trotz der unterschiedlichen Ebenen der Berechtigungstrennung ist ein übergeordneter Prozess auf Stammebene immer noch stark von seinen weniger privilegierten untergeordneten Prozessen abhängig. Er wird die Befehle und Argumente ausführen, die er erhalten wird.

Dies zu vermeiden scheint so einfach zu sein wie das Wechseln zum Maildir-Speicherformat, erfordert jedoch an vielen Stellen verschiedene Änderungen. Standard Mua Mailversteht dieses Format nicht. Was mich betrifft, hat mbox sein Leben lange überlebt, aber es passt immer noch zu vielen Menschen, und der Aktualisierungsvorgang ist möglicherweise nicht vollständig transparent und funktioniert nicht automatisch.

smtpd lesen

Das Lesen außerhalb des Bereichs in smtpd kann zum Ausführen von Befehlen verwendet werden. Bericht . Patch .

Dies ist wirklich ein Problem mit der Speichersicherheit. Durch das Senden einiger lustiger Statusleisten kann der Remote-SMTP-Server Befehle zur Ausführung in die SMTP-Warteschlange einfügen. Wenn eine E-Mail zur erneuten Zustellung in die Warteschlange gestellt wird, fügt smtpd dem Header einige Zielinformationen hinzu, um zu wissen, welcher Befehl ausgeführt werden soll (siehe oben). Dieser Angriff ähnelt dem "Schmuggel" von http-Anfragen . Wenn Sie eine "Scheiße" mit unerwarteten Befehlen im Header generieren können, führt smtpd diese aus, wenn Sie versuchen, erneut zu liefern.

Wie oben ist eines der Probleme, dass die empfindlichsten Teile von smtpd zu nahe an der Angriffsfläche liegen. Es scheint mir, dass das eigentliche Problem darin besteht, dass smtpd seine eigenen Metadaten in E-Mail-Daten speichert. Aus diesem Grund wird ein Parsing-Out-of-Sync-Angriff möglich. Wenn die angegebene Antwort vom Server vollständig getrennt von der Datei mit den Zustellanweisungen gespeichert würde, würde das Lesen außerhalb der Grenzen keinen großen Schaden anrichten.

Diese Sicherheitsanfälligkeit scheint mir bezeichnend zu sein, da wir hier die Gefahr sehen, Daten mit unterschiedlichen Vertrauensniveaus zu mischen. Diese Gefahr wurde nie diskutiert. Und das ist sie definitiv.

Ergebnisse

Natürlich war die Schlussfolgerung von Anfang an klar, aber wir werden trotzdem darüber sprechen.

Ich denke, einige dieser Fehler helfen zu demonstrieren, wie wichtig Prinzipien wie das Entfernen veralteter Schnittstellen und das Reduzieren der Codekomplexität für die Sicherheit sind . Der Misserfolg ist größtenteils darauf zurückzuführen, dass diese Grundsätze nicht bis zum Ende eingehalten wurden und nicht, weil die Grundsätze selbst verdorben oder unhaltbar sind. Einige Dinge geraten außer Sicht, aber ich stimme nicht zu, dass Entwickler eine Art übermenschliche Wachsamkeit brauchen. Es ist leicht, nutzlose Ratschläge zu geben, wie z. B. vorsichtig zu sein, keine Fehler zu machen und git gud [Slang-Gamer-Ausdruck bedeutet "gut werden", dh "besser werden, bald gesund werden" - ca. trans.]. Aber ich denke, OpenBSD hat ernstere Probleme.

Sogar OpenBSD kann Sicherheit für die praktische Anwendbarkeit riskieren. Aus diesem Grund wurden einige veraltete Projekte seit langem nicht mehr geändert. Vielleicht ist die Lehre also, dass effektive Prinzipien immer befolgt werden sollten, und nicht nur, wenn es zweckmäßig ist. Obwohl es oft schwierig ist, die richtige Wahl zu treffen.

Die drei schwerwiegendsten Sicherheitslücken, auth und zwei smtpd, eignen sich mehr oder weniger für die Ausnutzung, nur aufgrund von Architekturproblemen, die über den Rahmen des ursprünglichen Fehlers hinausgehen. Sie sollten nur geringfügige Mängel bleiben, die zeigen, dass es in einem gut geschützten System nicht erforderlich ist, nach dem perfekten Code zu streben, dh geringfügige Fehler sind zulässig - und sie beeinträchtigen die Sicherheit nicht. Leider kann es schwierig sein, Designfehler in abstrakter Form zu identifizieren. Alle Teile des Systems sehen einzeln geschützt aus. Wenn sie jedoch kombiniert werden, können Schwachstellen auftreten.

Die Trennung von Berechtigungen ist eine Schlüsselkomponente der OpenBSD-Sicherheit und basiert auf der Interprozesskommunikation. Es ist sinnvoll, genauer zu untersuchen, welche Probleme bei beschädigten Prozessen auftreten können. Geschützte Browser verstärken zunehmend den Schutz und verhindern Angriffe. Insbesondere muss smtpd bei Netzwerkaufgaben vor Speicherbeschädigung geschützt werden. Aber die Leichtigkeit, mit der er den elterlichen Prozess kontrollieren kann, ist alarmierend.

Mit einer sichereren Sprache konnte nur ein Fehler verhindert werden. Ja, wahrscheinlich gibt es eine Art Programmsprache, die in einigen Fällen hilfreich sein kann, wenn Sie sie mit religiöser Ausdauer verfolgen. Ich bin mir jedoch noch nicht sicher, ob standardmäßig jeder Programmierer alle entsprechenden Invarianten korrekt codiert.

Das Schreiben eines Mailservers ist eine knifflige Angelegenheit. Vor allem, wenn ältere Rahmen Sie straffen.

Es ist Zeit, die OpenBSD-Sicherheit zu überdenken

libc auth

ld.so.

ftp

smtpd von

smtpd lesen

Ergebnisse

More articles: