![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Die optimale L\u00f6sung w\u00e4re, nur die dringendsten Fehlerbehebungen und Sicherheitsanf\u00e4lligkeiten zu \u00fcbertragen, aber die Herausforderung besteht darin, solche Fehler aus dem gesamten Strom herauszufiltern. Die meisten auftretenden Probleme sind auf die Verwendung der Programmiersprache C zur\u00fcckzuf\u00fchren, die gro\u00dfe Sorgfalt im Umgang mit Speicher und Zeigern erfordert. Die Situation wird zus\u00e4tzlich dadurch erschwert, dass viele potenzielle Sicherheitsbehebungen nicht mit CVE-IDs versehen sind oder diese erst nach einiger Zeit nach der Ver\u00f6ffentlichung des Fixes erhalten. Unter diesen Bedingungen f\u00e4llt es den Herstellern sehr schwer, sekund\u00e4re Fixes von wichtigen Sicherheitsproblemen zu unterscheiden. Statistiken zeigen, dass \u00fcber 40 % der Sicherheitsanf\u00e4lligkeiten behoben werden, bevor eine CVE zugewiesen wird, und die durchschnittliche Verz\u00f6gerung zwischen der Ver\u00f6ffentlichung eines Fixes und der Zuweisung einer CVE betr\u00e4gt drei Monate (d.h. zun\u00e4chst wird der Fix als gew\u00f6hnlicher Fehler betrachtet, erst nach einigen Monaten wird klar, dass es sich um eine Sicherheitsanf\u00e4lligkeit handelt).<\/p>\nIn der Folge bleibt den Herstellern von Produkten auf Basis des Linux-Kernels nichts anderes \u00fcbrig, als kontinuierlich alle Fixes aus den aktuellen stabilen Branches zu \u00fcbernehmen, da sie keine separate Branch f\u00fcr Sicherheitsfixes haben und keine Informationen \u00fcber die sicherheitsrelevante Verbindung bestimmter Probleme erhalten. Diese Aufgabe erfordert jedoch erheblichen Arbeitsaufwand und st\u00f6\u00dft in den Unternehmen auf Widerstand, da man bef\u00fcrchtet, regressiven Ver\u00e4nderungen entgegenzuwirken, die das ordnungsgem\u00e4\u00dfe Funktionieren des Produkts gef\u00e4hrden k\u00f6nnten.<\/p>\n
Es sei daran erinnert, dass Linus Torvalds der Meinung ist, dass alle Fehler wichtig sind und Sicherheitsanf\u00e4lligkeiten nicht von anderen Arten von Fehlern getrennt und in eine separat priorisierte Kategorie eingeordnet werden sollten. Diese Ansicht wird damit begr\u00fcndet, dass f\u00fcr einen durchschnittlichen Entwickler, der sich nicht auf Sicherheitsfragen spezialisiert hat, die Verbindung zwischen einem Fix und einer potenziellen Sicherheitsanf\u00e4lligkeit nicht offensichtlich ist (f\u00fcr viele Fixes l\u00e4sst sich nur durch eine separate Pr\u00fcfung erkennen, dass sie sich auf Sicherheitsfragen beziehen). Linus ist der Meinung, dass die Identifizierung potenzieller Sicherheitsanf\u00e4lligkeiten im allgemeinen Strom der Fehlerbehebungen von Sicherheitsspezialisten in den Teams, die f\u00fcr die Unterst\u00fctzung der Paketverwaltung des Kernels in Linux-Distributionen verantwortlich sind, durchgef\u00fchrt werden sollte.<\/p>\n
Kees Cook ist der Ansicht, dass die einzige L\u00f6sung zur Erhaltung der Sicherheit des Kerns bei angemessenen langfristigen Kosten darin besteht, Ingenieure, die sich mit der Portierung von Fehlerbehebungen in lokale Kernel-Versionen besch\u00e4ftigen, auf eine koordinierte Zusammenarbeit zur Wartung von Fehlerbehebungen und Schwachstellen im Hauptkernel (upstream) umzuleiten. Derzeit verwenden viele Hersteller in ihren Produkten nicht die neuesten Kernel-Versionen und backportieren Fehlerbehebungen selbst, was bedeutet, dass Ingenieure in verschiedenen Unternehmen redundante Arbeit leisten, indem sie dasselbe Problem l\u00f6sen.<\/p>\n
Wenn beispielsweise 10 Unternehmen, in denen jeweils ein Ingenieur mit dem Backportieren derselben Fehlerbehebungen besch\u00e4ftigt ist, diese Ingenieure auf die Behebung von Fehlern im upstream umorientieren, k\u00f6nnten sie anstelle des Portierens einer einzigen Fehlerbehebung 10 verschiedene Fehler zum Wohle aller beheben oder sich an der \u00dcberpr\u00fcfung der vorgeschlagenen \u00c4nderungen beteiligen und so verhindern, dass fehlerhafter Code in den Kernel aufgenommen wird. Die Ressourcen k\u00f6nnten auch f\u00fcr die Entwicklung neuer Werkzeuge zur Testung und Codeanalyse eingesetzt werden, die es erm\u00f6glichen w\u00fcrden, g\u00e4ngige Fehlerklassen schon fr\u00fchzeitig automatisch zu identifizieren, die immer wieder auftauchen.<\/p>\n
Kees Cook schl\u00e4gt zudem vor, automatisiertes und Fuzzing-Testing aktiver im Entwicklungsprozess des Kernels zu nutzen, kontinuierliche Integrationssysteme anzuwenden und auf das veraltete Management der Entwicklung \u00fcber E-Mail zu verzichten. Derzeit wird effektives Testen durch die Trennung der Haupt-Testprozesse von der Entwicklung behindert, die erst nach der Erstellung von Releases stattfinden. Kees empfahl auch, zur Verringerung der Fehlerzahl Programmiersprachen zu verwenden, die eine bessere ein hohes Ma\u00df an Sicherheit<\/a>, wie Rust.<\/p>\n