{"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\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Bedrohungsmodell und Besonderheiten der Schwachstellenbewertung 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 und erl\u00e4utert, welche Fehler im Kernel als Schwachstellen betrachtet werden, sowie die Ma\u00dfnahmen zu den Fehlern, die mithilfe von KI gefunden wurden. Das Dokument wurde von Willy Tarreau, dem Autor von HAProxy und einem langj\u00e4hrigen Entwickler des Linux-Kernels, der f\u00fcr die Pflege mehrerer stabiler Kernelzweige verantwortlich war, erstellt. Basis sind die Vereinbarungen, die w\u00e4hrend der Diskussion k\u00fcrzlich entdeckter kritischer Schwachstellen im Kernel (1, 2, 3, 4) erzielt wurden, die vor der Ver\u00f6ffentlichung von Korrekturen offengelegt wurden und f\u00fcr die mithilfe von KI sofort funktionsf\u00e4hige Exploits erstellt werden konnten. <\/p>\n
Die meisten sicherheitsrelevanten Fehler sollen \u00f6ffentlich behandelt werden, um ein m\u00f6glichst breites Publikum anzuziehen und die optimale L\u00f6sung zu finden. Nur Notfallmeldungen \u00fcber Schwachstellen, die leicht ausgenutzt werden k\u00f6nnen, eine Bedrohung f\u00fcr viele Benutzer darstellen und erweiterte Privilegien oder M\u00f6glichkeiten bieten, werden in eine separate private Mailingliste vorgeschlagen. <\/p>\n
Schwachstellen, die mit Hilfe von KI-Assistenten identifiziert wurden, sollten immer \u00f6ffentlich diskutiert werden, da solche Probleme oft gleichzeitig von mehreren Forschern entdeckt werden. Dabei sollte im Bericht kein Exploit offengelegt werden — es gen\u00fcgt, zu erw\u00e4hnen, dass er verf\u00fcgbar ist, und ihn auf Anfrage der verantwortlichen Person vertraulich zu \u00fcbermitteln. <\/p>\n
Die Regeln f\u00fcr die \u00dcbergabe 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 \u00fcberpr\u00fcften Codeabschnitten zu erkennen. Die Meldenden ignorieren sie jedoch oft aufgrund der geringen Qualit\u00e4t und Ungenauigkeiten. Die Hauptanforderungen an Berichte, die mit KI-Unterst\u00fctzung erstellt wurden, sind: <\/p>\n
\n
K\u00fcrze, ohne F\u00fclltexte, und die wesentlichen Punkte sowie wichtige Details gleich zu Beginn anzugeben.\n
Nur reiner Text ohne Markdown-Tags und Dekoration.\n
Das Verst\u00e4ndnis des Bedrohungsmodells und die Angabe \u00fcberpr\u00fcfbarer Fakten (zum Beispiel «der Fehler erm\u00f6glicht es jedem Benutzer, CAP_NET_ADMIN zu erlangen»), anstatt theoretische Spekulationen und Mutma\u00dfungen \u00fcber die Folgen der Schwachstelle.\n
Vor dem Versenden des Berichts ist es unbedingt erforderlich, die Funktionsf\u00e4higkeit des durch KI erstellten Exploits gr\u00fcndlich zu testen und sicherzustellen, dass das Problem reproduziert werden kann.\n
Einsatz von KI zur Entwicklung und Testung einer L\u00f6sung f\u00fcr das identifizierte Problem. <\/ul>\n
Laut Begleitstatistiken sind die meisten Fehlerberichte, die als Beseitigung von Schwachstellen eingereicht werden, keine solchen und sollten wie gew\u00f6hnliche Fehler behandelt werden. Zur Unterscheidung zwischen Schwachstellen und gew\u00f6hnlichen Fehlern wurde ein Bedrohungsmodell des Linux-Kernels beschrieben. Zu den M\u00f6glichkeiten und Garantien, deren Verletzung als Schwachstelle betrachtet werden kann, geh\u00f6ren: <\/p>\n
\n
Benutzerebene Isolation: Der Zugriff auf Dateien ist nur f\u00fcr den Eigent\u00fcmer m\u00f6glich, der Speicher eines Prozesses ist f\u00fcr andere Benutzer unzug\u00e4nglich, ptrace ist f\u00fcr fremde Prozesse verboten, IPC- und Netzwerkkommunikationen sind isoliert.\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 Verkehr abgefangen werden, ohne CAP_SYS_PTRACE k\u00f6nnen die Prozesse anderer Benutzer nicht \u00fcberwacht werden.\n
Der Namensraum f\u00fcr Benutzeridentifikatoren (CONFIG_USER_NS) erm\u00f6glicht es nicht privilegierten Benutzern, ihre eigenen isolierten Umgebungen zu schaffen, die keinen Einfluss auf den globalen Namensraum haben, beispielsweise die Zeit zu \u00e4ndern, Module zu laden und Blockger\u00e4te zu mounten.\n
Debug-Schnittstellen (\/proc\/kmsg, perf, debugfs), \u00fcber die auf vertrauliche Informationen zugegriffen werden kann, sind nur nach ausdr\u00fccklicher Bereitstellung des Zugriffs durch einen Administrator verf\u00fcgbar. <\/ul>\n
Funktionen, die nicht als Sicherheitsanf\u00e4lligkeiten betrachtet werden: <\/p>\n
\n
Verwendung veralteter Kernel-Versionen.\n
Kompilierung mit aktivierten Entwickleroptionen oder sicherheitsreduzierenden Optionen (z. B. CONFIG_NOMMU).\n
Festlegen unsicherer sysctl-Einstellungen, Befehlszeilenoptionen, Zugriffsrechte im Dateisystem, Berechtigungen oder das \u00d6ffnen des Zugriffs auf privilegierte Schnittstellen f\u00fcr nicht privilegierte Benutzer (z. B. Schreibzugriff auf procfs und debugfs).\n
Probleme in Funktionen, die nur f\u00fcr die Entwicklung und das Debuggen des Kernels vorgesehen sind, wie LOCKDEP, KASAN und FAULT_INJECTION, die nicht f\u00fcr produktive Konfigurationen vorgesehen sind.\n
Probleme mit Treibern, Modulen und Subsystemen, die sich im STAGING-Bereich befinden oder als experimentell, unsicher oder nicht funktionsf\u00e4hig markiert sind.\n
Verwendung von Drittanbietermodulen des Kernels oder inoffiziellen Kernel-Forks.\n
Anforderung \u00fcberm\u00e4\u00dfiger 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\u00fchren.\n
Theoretische Angriffe, die Laborkonditionen, Milliarden von Versuchen, Emulation oder Hardwaremodifikation, unverh\u00e4ltnism\u00e4\u00dfige Kosten und unrealistische Konfigurationen (z. B. Systeme mit zehntausenden CPU-Kernen) erfordern.\n
Umgehung von Schutzmechanismen (z. B. ASLR) ohne Nachweis eines Exploits. Fehlende \u00dcberpr\u00fcfungen von Argumenten und R\u00fcckgabecodes, die keine offensichtlichen Folgen haben.\n
Zuf\u00e4llige Informationslecks, die nicht unter Kontrolle der Angreifenden stehen, wie Restdaten in Fehlermeldungen und Adressen\/Zeiger auf Kernel-Speicher ohne die direkte M\u00f6glichkeit der Ausnutzung.\n
Fehler beim Einbinden besch\u00e4digter Disk-Images, wenn der Treiber nicht als geeignet f\u00fcr die Verwendung mit unzuverl\u00e4ssigen Datentr\u00e4gern deklariert ist. Probleme mit Disk-Images, die durch die Ausf\u00fchrung des Dienstprogramms fsck erkannt und behoben werden.\n
Angriffe, die physischen Zugang zu Hardware, Modifikationen an der Hardware oder den Anschluss von Hardware-Ger\u00e4ten wie DMA-Angriffskarten und Logikanalysatoren erfordern, es sei denn, das System ist speziell daf\u00fcr konfiguriert, solche Angriffe zu verhindern (IOMMU).\n
Regressionen in Funktionalit\u00e4t und Leistung k\u00f6nnen durch Anpassung von Rechten und Limits behoben werden. <\/ul>\n