![\"Kis](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Die optimale L\u00f6sung w\u00e4re, nur die wichtigsten Fehlerbehebungen und Sicherheitsl\u00fccken zu \u00fcbertragen. Das Hauptproblem liegt jedoch darin, solche Fehler aus dem allgemeinen Kontext herauszufiltern. Die h\u00e4ufigsten Probleme resultieren aus der Nutzung der Programmiersprache C, die eine besondere Genauigkeit beim Umgang mit Speicher und Zeigern erfordert. Hinzu kommt, dass viele potenzielle Sicherheitsbehebungen in der Regel zun\u00e4chst keine CVE-IDs zur Verf\u00fcgung haben oder diese erst nach einer gewissen Zeit nach der Ver\u00f6ffentlichung des Patches erhalten. Unter diesen Bedingungen f\u00e4llt es den Herstellern schwer, nebens\u00e4chliche Behebungen von kritischen Sicherheitsproblemen zu unterscheiden. Statistiken zeigen, dass \u00fcber 40 % der Sicherheitsanf\u00e4lligkeiten behoben werden, bevor eine CVE-ID zugewiesen wird, und die durchschnittliche Verz\u00f6gerung zwischen der Ver\u00f6ffentlichung des Patches und der Zuweisung einer CVE-ID betr\u00e4gt drei Monate. Das bedeutet, dass anf\u00e4nglich die Behebung als ein gew\u00f6hnlicher Fehler betrachtet wird, erst einige Monate sp\u00e4ter wird klar, dass es sich um eine Sicherheitsanf\u00e4lligkeit handelt.<\/p>\nIn der Konsequenz bleibt den Herstellern von Produkten, die auf dem Linux-Kernel basieren, nichts anderes \u00fcbrig, als st\u00e4ndig alle Korrekturen aus den neuesten stabilen Zweigen zu \u00fcbernehmen, da es keinen separaten Zweig f\u00fcr die Behebung von Sicherheitsanf\u00e4lligkeiten gibt und Informationen \u00fcber die Sicherheitsrelevanz eines bestimmten Problems fehlen. Diese Arbeit ist jedoch sehr zeitaufwendig und st\u00f6\u00dft in Unternehmen auf Widerstand, da bef\u00fcrchtet wird, dass regressiven \u00c4nderungen, die die ordnungsgem\u00e4\u00dfe Funktion des Produkts beeintr\u00e4chtigen k\u00f6nnten, auftreten k\u00f6nnten.<\/p>\n
Laut Linus Torvalds sind alle Fehler wichtig und Sicherheitsanf\u00e4lligkeiten sollten nicht von anderen Arten von Fehlern getrennt und in eine gesonderte, priorit\u00e4rere Kategorie eingeordnet werden. Diese Auffassung wird damit erkl\u00e4rt, dass f\u00fcr einen typischen Entwickler, der sich nicht auf Sicherheitsfragen spezialisiert hat, die Verbindung zwischen einem Fix und einer potenziellen Sicherheitsanf\u00e4lligkeit nicht offensichtlich ist (bei vielen Fixes erm\u00f6glicht nur eine separate Pr\u00fcfung zu erkennen, dass sie die Sicherheit betreffen). Nach Linus' Ansicht sollten die Fachleute f\u00fcr Sicherheit aus den Teams, die f\u00fcr die Unterst\u00fctzung der Kernpakete in den Linux-Distributionen zust\u00e4ndig sind, die Identifizierung potenzieller Sicherheitsanf\u00e4lligkeiten aus dem allgemeinen Strom der Fixes \u00fcbernehmen.<\/p>\n
Kis Kuk ist der Meinung, dass der einzige Weg, um die Sicherheit des Kernels bei angemessenen langfristigen Kosten aufrechtzuerhalten, darin besteht, dass Unternehmen Ingenieure, die sich mit dem Portieren von Patches in lokale Kernel-Builds befassen, zu einer gemeinsamen und koordinierten Zusammenarbeit an der Pflege von Patches und Sicherheitsanf\u00e4lligkeiten im Hauptkernel (upstream) bewegen. Derzeit verwenden viele Hersteller in ihren Produkten nicht die neuesten Versionen des Kernels und backportieren Patches auf eigene Faust, was dazu f\u00fchrt, dass Ingenieure in verschiedenen Unternehmen die Arbeit anderer duplizieren, um dasselbe Problem zu l\u00f6sen.<\/p>\n
Wenn beispielsweise 10 Unternehmen, in denen jeweils ein Ingenieur mit dem Backporting derselben Fehlerbehebungen besch\u00e4ftigt ist, diese Ingenieure stattdessen auf die Behebung von Fehlern im Upstream umschichten, k\u00f6nnten sie anstelle des Portierens einer einzigen Korrektur 10 verschiedene Fehler zugunsten aller beheben oder sich an der \u00dcberpr\u00fcfung vorgeschlagener \u00c4nderungen beteiligen, um zu verhindern, dass fehlerhafte Codes in den Kernel aufgenommen werden. Die Ressourcen k\u00f6nnten auch zur Entwicklung neuer Werkzeuge f\u00fcr die Testung und Analyse von Codes verwendet werden, die es erm\u00f6glichen w\u00fcrden, typische Klassen von Fehlern fr\u00fchzeitig automatisch zu erkennen, die immer wieder auftreten.<\/p>\n
Kees Cook fordert auch eine aktivere Nutzung automatisierter Tests und Fuzzing-Tests direkt w\u00e4hrend der Kernel-Entwicklung, die Anwendung von Continuous Integration-Systemen und die Abkehr von der veralteten Verwaltung der Entwicklung \u00fcber E-Mail. Derzeit wird eine effektive Testdurchf\u00fchrung dadurch behindert, dass die Haupttestprozesse von der Entwicklung getrennt sind und erst nach der Erstellung von Releases stattfinden. Kees empfahl au\u00dferdem, bei der Entwicklung Sprachen zu verwenden, die mehr Sicherheit bieten, ein hohes Ma\u00df an Sicherheit.<\/a>, wie Rust.<\/p>\n