Bedrohungsmodell und Besonderheiten der Schwachstellenbewertung im Linux-Kernel

Linus Torvalds hat ein Dokument in den Kernel aufgenommen, das den Prozess zur Behandlung von sicherheitsrelevanten Fehlern regelt, ein Bedrohungsmodell definiert und erläutert, welche Fehler im Kernel als Schwachstellen betrachtet werden, sowie die Maßnahmen zu den Fehlern, die mithilfe von KI gefunden wurden. Das Dokument wurde von Willy Tarreau, dem Autor von HAProxy und einem langjährigen Entwickler des Linux-Kernels, der für die Pflege mehrerer stabiler Kernelzweige verantwortlich war, erstellt. Basis sind die Vereinbarungen, die während der Diskussion kürzlich entdeckter kritischer Schwachstellen im Kernel (1, 2, 3, 4) erzielt wurden, die vor der Veröffentlichung von Korrekturen offengelegt wurden und für die mithilfe von KI sofort funktionsfähige Exploits erstellt werden konnten.

Die meisten sicherheitsrelevanten Fehler sollen öffentlich behandelt werden, um ein möglichst breites Publikum anzuziehen und die optimale Lösung zu finden. Nur Notfallmeldungen über Schwachstellen, die leicht ausgenutzt werden können, eine Bedrohung für viele Benutzer darstellen und erweiterte Privilegien oder Möglichkeiten bieten, werden in eine separate private Mailingliste vorgeschlagen.

Sicherheitsanfälligkeiten, die mit Hilfe von KI-Assistenten identifiziert werden, sollten immer öffentlich diskutiert werden, da solche Probleme häufig gleichzeitig von mehreren Forschern entdeckt werden. Dabei sollte der Exploit im Bericht nicht offenbart werden - es genügt zu erwähnen, dass er verfügbar ist, und ihn privat auf Anfrage des Melders weiterzugeben.

Die Regeln für die Übergabe von Berichten, die mit Hilfe von KI-Assistenten erstellt wurden, werden separat beschrieben. Es werden sehr viele solcher Berichte gesendet, und gelegentlich gelingt es, Fehler in schlecht überprüften Codeabschnitten zu erkennen. Die Meldenden ignorieren sie jedoch oft aufgrund der geringen Qualität und Ungenauigkeiten. Die Hauptanforderungen an Berichte, die mit KI-Unterstützung erstellt wurden, sind:

• Kürze, ohne Fülltexte, und die wesentlichen Punkte sowie wichtige Details gleich zu Beginn anzugeben.
• Nur reiner Text ohne Markdown-Tags und Dekoration.
• Verständnis des Bedrohungsmodells und Angabe überprüfbarer Fakten (z. B. "Der Fehler erlaubt jedem Benutzer, CAP_NET_ADMIN zu erhalten"), und nicht theoretische Spekulationen und Vermutungen über die Folgen der Sicherheitsanfälligkeit.
• Vor dem Versenden des Berichts ist es unbedingt erforderlich, die Funktionsfähigkeit des durch KI erstellten Exploits gründlich zu testen und sicherzustellen, dass das Problem reproduziert werden kann.
• Einsatz von KI zur Entwicklung und Testung einer Lösung für das identifizierte Problem.

Laut Begleitstatistiken sind die meisten Fehlerberichte, die als Beseitigung von Schwachstellen eingereicht werden, keine solchen und sollten wie gewöhnliche Fehler behandelt werden. Zur Unterscheidung zwischen Schwachstellen und gewöhnlichen Fehlern wurde ein Bedrohungsmodell des Linux-Kernels beschrieben. Zu den Möglichkeiten und Garantien, deren Verletzung als Schwachstelle betrachtet werden kann, gehören:

• Benutzerebene Isolation: Der Zugriff auf Dateien ist nur für den Eigentümer möglich, der Speicher eines Prozesses ist für andere Benutzer unzugänglich, ptrace ist für fremde Prozesse verboten, IPC- und Netzwerkkommunikationen sind isoliert.
• Schutz auf Basis von Berechtigungen: Ohne CAP_SYS_ADMIN kann die Kernelkonfiguration, der Speicher oder der Systemzustand nicht geändert werden, ohne CAP_NET_ADMIN können keine Netzwerkeinstellungen geändert oder der Verkehr abgefangen werden, ohne CAP_SYS_PTRACE können die Prozesse anderer Benutzer nicht überwacht werden.
• Der Namensraum für Benutzeridentifikatoren (CONFIG_USER_NS) ermöglicht es nicht privilegierten Benutzern, ihre eigenen isolierten Umgebungen zu schaffen, die keinen Einfluss auf den globalen Namensraum haben, beispielsweise die Zeit zu ändern, Module zu laden und Blockgeräte zu mounten.
• Debug-Schnittstellen (/proc/kmsg, perf, debugfs), über die auf vertrauliche Informationen zugegriffen werden kann, sind nur nach ausdrücklicher Bereitstellung des Zugriffs durch einen Administrator verfügbar.

Funktionen, die nicht als Sicherheitsanfälligkeiten betrachtet werden:

• Verwendung veralteter Kernel-Versionen.
• Kompilierung mit aktivierten Entwickleroptionen oder sicherheitsreduzierenden Optionen (z. B. CONFIG_NOMMU).
• Festlegen unsicherer sysctl-Einstellungen, Befehlszeilenoptionen, Zugriffsrechte im Dateisystem, Berechtigungen oder das Öffnen des Zugriffs auf privilegierte Schnittstellen für nicht privilegierte Benutzer (z. B. Schreibzugriff auf procfs und debugfs).
• Probleme in Funktionen, die nur für die Entwicklung und das Debuggen des Kernels vorgesehen sind, wie LOCKDEP, KASAN und FAULT_INJECTION, die nicht für produktive Konfigurationen vorgesehen sind.
• Probleme mit Treibern, Modulen und Subsystemen, die sich im STAGING-Bereich befinden oder als experimentell, unsicher oder nicht funktionsfähig markiert sind.
• Verwendung von Drittanbietermodulen des Kernels oder inoffiziellen Kernel-Forks.
• Anforderung übermäßiger Berechtigungen, wie die Notwendigkeit, Aktionen mit Root-Rechten oder durch einen Benutzer mit den Rechten CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO und CAP_SYS_MODULE auszuführen.
• Theoretische Angriffe, die Laborkonditionen, Milliarden von Versuchen, Emulation oder Hardwaremodifikation, unverhältnismäßige Kosten und unrealistische Konfigurationen (z. B. Systeme mit zehntausenden CPU-Kernen) erfordern.
• Umgehung von Schutzmechanismen (z. B. ASLR) ohne Nachweis eines Exploits. Fehlende Überprüfungen von Argumenten und Rückgabecodes, die keine offensichtlichen Folgen haben.
• Zufällige Informationslecks, die nicht unter Kontrolle der Angreifenden stehen, wie Restdaten in Fehlermeldungen und Adressen/Zeiger auf Kernel-Speicher ohne die direkte Möglichkeit der Ausnutzung.
• Fehler beim Einbinden beschädigter Disk-Images, wenn der Treiber nicht als geeignet für die Verwendung mit unzuverlässigen Datenträgern deklariert ist. Probleme mit Disk-Images, die durch die Ausführung des Dienstprogramms fsck erkannt und behoben werden.
• Angriffe, die physischen Zugang zu Hardware, Modifikationen an der Hardware oder den Anschluss von Hardware-Geräten wie DMA-Angriffskarten und Logikanalysatoren erfordern, es sei denn, das System ist speziell dafür konfiguriert, solche Angriffe zu verhindern (IOMMU).
• Regressionen in Funktionalität und Leistung können durch Anpassung von Rechten und Limits behoben werden.

Quelle: opennet.ru