Modell der Bedrohungen und Besonderheiten der Vulnerabilitätsbewertung im Linux-Kernel

Linus Torvalds hat ein Dokument in den Kernel aufgenommen, das den Prozess zur Behandlung von sicherheitsrelevanten Fehlern regelt, ein Bedrohungsmodell definiert, erklärt, welche Fehler im Kernel als Schwachstellen angesehen werden, und Maßnahmen für mit Hilfe von KI identifizierten Fehlern behandelt. Das Dokument wurde von Willy Tarreau, dem Autor von HAProxy und langjährigen Entwickler des Linux-Kernels, erstellt, der für die Wartung mehrerer stabiler Kernel-Zweige verantwortlich war. Grundlage sind die Vereinbarungen, die während der Diskussion über kürzlich entdeckte kritische Schwachstellen im Kernel (1, 2, 3, 4) getroffen wurden, die vor der Veröffentlichung der Patches aufgedeckt wurden und für die es dank KI gelungen ist, sofort funktionierende Exploits zu erzeugen.

Der Großteil der mit Sicherheit verbundenen Fehler soll öffentlich behandelt werden, um ein möglichst breites Publikum zu erreichen und die optimale Lösung zu finden. Nur dringende Meldungen über leicht ausnutzbare Schwachstellen, die eine Bedrohung für viele Benutzer darstellen und erweiterte Berechtigungen oder Möglichkeiten bieten, sollen in eine separate private Mailingliste gesendet werden.

Schwachstellen, die mit Hilfe von KI-Assistenten identifiziert wurden, sollten stets öffentlich diskutiert werden, da solche Probleme häufig gleichzeitig von mehreren Forschern entdeckt werden. Dabei sollte im Bericht der Exploit nicht offengelegt werden – es genügt zu erwähnen, dass er verfügbar ist, und ihn auf Anfrage des Betreuers privat zu übermitteln.

Separat werden die Regeln für die Übermittlung von Berichten, die mit Hilfe von KI-Assistenten erstellt wurden, beschrieben. Solcherart Berichte werden sehr viele gesendet, und dank ihnen gelingt es von Zeit zu Zeit, Fehler in schlecht überprüften Codeabschnitten zu identifizieren, doch die Betreuer ignorieren sie häufig aufgrund ihrer niedrigen Qualität und Ungenauigkeiten. Die wichtigsten Anforderungen an Berichte, die unter Beteiligung von KI erstellt wurden, sind:

• Kürze, ohne unwesentliche Informationen, mit Angabe der Essenz und wichtiger Details gleich zu Beginn.
• Nur reiner Text ohne Markdown-Tags und Dekorierungen.
• Verständnis des Bedrohungsmodells und Angabe der überprüften Fakten (zum Beispiel: „Der Fehler ermöglicht es jedem Benutzer, CAP_NET_ADMIN zu erhalten“), und nicht theoretische Überlegungen und Mutmaßungen über die Folgen der Schwachstelle.
• Vor dem Versand des Berichts muss die Funktionalität des über AI erzeugten Exploits gründlich getestet und sichergestellt werden, dass das Problem reproduzierbar ist.
• Einbeziehung von AI in die Entwicklung und Tests zur Behebung des identifizierten Problems.

Laut den Statistikern sind die meisten Fehlerberichte, die als Behebung von Schwachstellen eingereicht werden, keine solchen, und sollten daher wie normale Fehler behandelt werden. Um Schwachstellen von normalen Fehlern zu trennen, gibt es ein Bedrohungsmodell für den Linux-Kernel. Zu den Möglichkeiten und Garantien, deren Verletzung als Schwachstelle angesehen werden kann, gehören:

• Isolierung auf Benutzerebene: Zugriff auf Dateien nur für den Besitzer, der Speicher eines Prozesses ist für andere Benutzer unzugänglich, ptrace ist für fremde Prozesse verboten, Isolierung von IPC und Netzwerkkommunikation.
• 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 Datenverkehr abgefangen werden; ohne CAP_SYS_PTRACE ist es nicht möglich, Prozesse anderer Benutzer zu verfolgen.
• Der Namensraum der Benutzeridentifikatoren (CONFIG_USER_NS) ermöglicht es unprivilegierten Benutzern, ihre eigenen isolierten Umgebungen zu schaffen, aus denen sie keinen Einfluss auf den globalen Namensraum nehmen können, z. B. die Zeit ändern, Module laden und Blockgeräte einbinden.
• Debug-Schnittstellen (/proc/kmsg, perf, debugfs), über die vertrauliche Informationen zugänglich sind, sind nur nach ausdrücklicher Genehmigung durch den Administrator zugänglich.

Funktionen, die nicht als Schwachstellen betrachtet werden:

• Verwendung veralteter Kernelzweige.
• Kompilierung unter Einbeziehung von Entwickleroptionen oder sicherheitsreduzierenden Optionen (z. B. CONFIG_NOMMU).
• Festlegung unsicherer sysctl-Einstellungen, Befehlszeilenoptionen, Zugriffsrechte im Dateisystem, Berechtigungen oder die Gewährung von Zugriff unprivilegierten Benutzern auf privilegierte Schnittstellen (z. B. Schreibzugriff auf procfs und debugfs).
• Probleme in Funktionen, die nur für die Entwicklung und das Debuggen des Kernels bestimmt sind, wie LOCKDEP, KASAN und FAULT_INJECTION, die nicht für die Aktivierung in produktiven Konfigurationen gedacht sind.
• Probleme mit Treibern, Modulen und Teilsystemen, die sich im STAGING-Bereich befinden oder als experimentell, unsicher oder nicht funktionsfähig gekennzeichnet sind.
• Verwendung von Drittanbieter-Kernelmodulen oder inoffiziellen Forks des Kernels.
• Anforderung übermäßiger Berechtigungen, wie die Notwendigkeit, Aktionen mit Root-Rechten oder von einem Benutzer auszuführen, der über die Berechtigungen CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO und CAP_SYS_MODULE verfügt.
• Theoretische Angriffe, die Laborbedingungen, Milliarden von Versuchen, Emulation oder Modifikation der Hardware, unverhältnismäßige Kosten und unrealistische Konfigurationen erfordern (zum Beispiel Systeme mit Zehntausenden von CPU-Kernen).
• Umgehung von Schutzmechanismen (zum Beispiel ASLR) ohne Nachweis eines Exploits. Fehlende Überprüfungen von Argumenten und Rückgabewerten von Fehlercodes, die keine offensichtlichen Folgen haben.
• Zufällige Informationslecks, die für Angreifer nicht kontrollierbar sind, wie Rückstandsdatensätze in Fehlermeldungen und Lecks von Adressen/Pointern auf Kernel-Speicher ohne direkte Möglichkeit zur Ausnutzung.
• Fehler beim Einhängen beschädigter Disk-Images, wenn der Treiber nicht als geeignet für die Verwendung mit nicht vertrauenswürdigen Medien erklärt ist. Probleme mit Disk-Images, die durch die Ausführung des fsck-Tools identifiziert und behoben werden.
• Angriffe, die physischen Zugriff auf die Hardware, Modifikationen der Hardware oder den Anschluss von Hardwaregeräten erfordern, wie Karten für DMA-Angriffe und Logikanalysatoren, es sei denn, das System ist speziell dafür konfiguriert, um solchen Angriffen entgegenzuwirken (IOMMU).
• Regressionen bei Funktionalität und Leistung, die durch Anpassungen von Rechten und Limits behoben werden.

Quelle: opennet.ru