{"id":170830,"date":"2026-05-16T18:24:39","date_gmt":"2026-05-16T16:24:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux"},"modified":"2026-05-16T18:24:39","modified_gmt":"2026-05-16T16:24:39","slug":"model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Modell der Bedrohungen und Besonderheiten der Vulnerabilit\u00e4tsbewertung im Linux-Kernel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds hat ein Dokument in den Kernel aufgenommen, das den Prozess zur Behandlung von sicherheitsrelevanten Fehlern regelt, ein Bedrohungsmodell definiert, erkl\u00e4rt, welche Fehler im Kernel als Schwachstellen angesehen werden, und Ma\u00dfnahmen f\u00fcr mit Hilfe von KI identifizierten Fehlern behandelt. Das Dokument wurde von Willy Tarreau, dem Autor von HAProxy und langj\u00e4hrigen Entwickler des Linux-Kernels, erstellt, der f\u00fcr die Wartung mehrerer stabiler Kernel-Zweige verantwortlich war. Grundlage sind die Vereinbarungen, die w\u00e4hrend der Diskussion \u00fcber k\u00fcrzlich entdeckte kritische Schwachstellen im Kernel (1, 2, 3, 4) getroffen wurden, die vor der Ver\u00f6ffentlichung der Patches aufgedeckt wurden und f\u00fcr die es dank KI gelungen ist, sofort funktionierende Exploits zu erzeugen. <\/p>\n
Der Gro\u00dfteil der mit Sicherheit verbundenen Fehler soll \u00f6ffentlich behandelt werden, um ein m\u00f6glichst breites Publikum zu erreichen und die optimale L\u00f6sung zu finden. Nur dringende Meldungen \u00fcber leicht ausnutzbare Schwachstellen, die eine Bedrohung f\u00fcr viele Benutzer darstellen und erweiterte Berechtigungen oder M\u00f6glichkeiten bieten, sollen in eine separate private Mailingliste gesendet werden. <\/p>\n
Die durch AI-Assistenten identifizierten Schwachstellen sollten immer \u00f6ffentlich diskutiert werden, da solche Probleme h\u00e4ufig gleichzeitig von mehreren Forschern entdeckt werden. Dabei ist es nicht erforderlich, den Exploit im Bericht offenzulegen \u2013 es gen\u00fcgt zu erw\u00e4hnen, dass er verf\u00fcgbar ist, und ihn auf Anfrage des Befassenden privat zu \u00fcbermitteln. <\/p>\n
Separat werden die Regeln f\u00fcr die \u00dcbermittlung 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 \u00fcberpr\u00fcften Codeabschnitten zu identifizieren, doch die Betreuer ignorieren sie h\u00e4ufig aufgrund ihrer niedrigen Qualit\u00e4t und Ungenauigkeiten. Die wichtigsten Anforderungen an Berichte, die unter Beteiligung von KI erstellt wurden, sind: <\/p>\n
\n
K\u00fcrze, ohne unwesentliche Informationen, mit Angabe der Essenz und wichtiger Details gleich zu Beginn.\n
Nur reiner Text ohne Markdown-Tags und Dekorierungen.\n
Das Verst\u00e4ndnis des Bedrohungsmodells und die Angabe \u00fcberpr\u00fcfbarer Fakten (zum Beispiel \u201eder Fehler erm\u00f6glicht es jedem Benutzer, CAP_NET_ADMIN zu erhalten\u201c), und nicht theoretische Spekulationen oder Mutma\u00dfungen \u00fcber die Folgen der Schwachstelle.\n
Vor dem Versand des Berichts muss die Funktionalit\u00e4t des \u00fcber AI erzeugten Exploits gr\u00fcndlich getestet und sichergestellt werden, dass das Problem reproduzierbar ist.\n
Einbeziehung von AI in die Entwicklung und Tests zur Behebung des identifizierten Problems. <\/ul>\n
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\u00fcr den Linux-Kernel. Zu den M\u00f6glichkeiten und Garantien, deren Verletzung als Schwachstelle angesehen werden kann, geh\u00f6ren: <\/p>\n
\n
Isolierung auf Benutzerebene: Zugriff auf Dateien nur f\u00fcr den Besitzer, der Speicher eines Prozesses ist f\u00fcr andere Benutzer unzug\u00e4nglich, ptrace ist f\u00fcr fremde Prozesse verboten, Isolierung von IPC und Netzwerkkommunikation.\n
Schutz auf Basis von Berechtigungen: Ohne CAP_SYS_ADMIN kann die Kernelkonfiguration, der Speicher oder der Systemzustand nicht ge\u00e4ndert werden; ohne CAP_NET_ADMIN k\u00f6nnen keine Netzwerkeinstellungen ge\u00e4ndert oder der Datenverkehr abgefangen werden; ohne CAP_SYS_PTRACE ist es nicht m\u00f6glich, Prozesse anderer Benutzer zu verfolgen.\n
Der Namensraum der Benutzeridentifikatoren (CONFIG_USER_NS) erm\u00f6glicht es unprivilegierten Benutzern, ihre eigenen isolierten Umgebungen zu schaffen, aus denen sie keinen Einfluss auf den globalen Namensraum nehmen k\u00f6nnen, z. B. die Zeit \u00e4ndern, Module laden und Blockger\u00e4te einbinden.\n
Debug-Schnittstellen (\/proc\/kmsg, perf, debugfs), \u00fcber die vertrauliche Informationen zug\u00e4nglich sind, sind nur nach ausdr\u00fccklicher Genehmigung durch den Administrator zug\u00e4nglich. <\/ul>\n
Funktionen, die nicht als Schwachstellen betrachtet werden: <\/p>\n
\n
Verwendung veralteter Kernelzweige.\n
Kompilierung unter Einbeziehung von Entwickleroptionen oder sicherheitsreduzierenden Optionen (z. B. CONFIG_NOMMU).\n
Festlegung unsicherer sysctl-Einstellungen, Befehlszeilenoptionen, Zugriffsrechte im Dateisystem, Berechtigungen oder die Gew\u00e4hrung von Zugriff unprivilegierten Benutzern auf privilegierte Schnittstellen (z. B. Schreibzugriff auf procfs und debugfs).\n
Probleme in Funktionen, die nur f\u00fcr die Entwicklung und das Debuggen des Kernels bestimmt sind, wie LOCKDEP, KASAN und FAULT_INJECTION, die nicht f\u00fcr die Aktivierung in produktiven Konfigurationen gedacht sind.\n
Probleme mit Treibern, Modulen und Teilsystemen, die sich im STAGING-Bereich befinden oder als experimentell, unsicher oder nicht funktionsf\u00e4hig gekennzeichnet sind.\n
Verwendung von Drittanbieter-Kernelmodulen oder inoffiziellen Forks des Kernels.\n
Anforderung \u00fcberm\u00e4\u00dfiger Berechtigungen, wie die Notwendigkeit, Aktionen mit Root-Rechten oder von einem Benutzer auszuf\u00fchren, der \u00fcber die Berechtigungen CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO und CAP_SYS_MODULE verf\u00fcgt.\n
Theoretische Angriffe, die Laborbedingungen, Milliarden von Versuchen, Emulation oder Modifikation der Hardware, unverh\u00e4ltnism\u00e4\u00dfige Kosten und unrealistische Konfigurationen erfordern (zum Beispiel Systeme mit Zehntausenden von CPU-Kernen).\n
Umgehung von Schutzmechanismen (zum Beispiel ASLR) ohne Nachweis eines Exploits. Fehlende \u00dcberpr\u00fcfungen von Argumenten und R\u00fcckgabewerten von Fehlercodes, die keine offensichtlichen Folgen haben.\n
Zuf\u00e4llige Informationslecks, die f\u00fcr Angreifer nicht kontrollierbar sind, wie R\u00fcckstandsdatens\u00e4tze in Fehlermeldungen und Lecks von Adressen\/Pointern auf Kernel-Speicher ohne direkte M\u00f6glichkeit zur Ausnutzung.\n
Fehler beim Einh\u00e4ngen besch\u00e4digter Disk-Images, wenn der Treiber nicht als geeignet f\u00fcr die Verwendung mit nicht vertrauensw\u00fcrdigen Medien erkl\u00e4rt ist. Probleme mit Disk-Images, die durch die Ausf\u00fchrung des fsck-Tools identifiziert und behoben werden.\n
Angriffe, die physischen Zugriff auf die Hardware, Modifikationen der Hardware oder den Anschluss von Hardwareger\u00e4ten erfordern, wie Karten f\u00fcr DMA-Angriffe und Logikanalysatoren, es sei denn, das System ist speziell daf\u00fcr konfiguriert, um solchen Angriffen entgegenzuwirken (IOMMU).\n
Regressionen bei Funktionalit\u00e4t und Leistung, die durch Anpassungen von Rechten und Limits behoben werden. <\/ul>\n