Kees Cook von Google fordert eine Modernisierung des Fehlerbehebungsprozesses im Linux-Kernel

Kees Cook, ehemaliger Hauptsystemadministrator von kernel.org und Leiter des Ubuntu Security Teams, der jetzt bei Google an der Sicherheitsgewährleistung für Android und ChromeOS arbeitet, äußerte Bedenken hinsichtlich des aktuellen Prozesses zur Behebung von Fehlern in den stabilen Kernel-Zweigen. Jede Woche werden etwa einhundert Korrekturen in die stabilen Zweige aufgenommen, und nach Schließung des Fensters für Änderungen nähert sich die Anzahl der Korrekturen für die nächste Version der tausend (da die Begleitenden die Korrekturen bis zur Schließung des Fensters festhalten und nach der Erstellung von „-rc1“ alles auf einmal veröffentlichen), was einfach zu viel ist und erhebliche Arbeitsaufwände für die Wartung von Produkten auf Basis des Linux-Kernels erforderlich macht.

Laut Kees wird dem Prozess der Arbeit mit Fehlern im Kernel nicht die nötige Aufmerksamkeit geschenkt, und dem Kernel fehlen mindestens 100 zusätzliche Entwickler für eine koordinierte Arbeit in diesem Bereich. Die Hauptentwickler des Kernels beheben regelmäßig Fehler, aber es gibt keine Garantie, dass diese Korrekturen in die Kernel-Versionen integriert werden, die von Drittanbietern verwendet werden. Die Benutzer verschiedener Produkte auf Basis des Linux-Kernels haben zudem keine Möglichkeit, nachzuvollziehen, welche Fehler behoben wurden und welche Kernel-Version in ihren Geräten verwendet wird. Letztendlich sind die Hersteller für die Sicherheit ihrer Produkte verantwortlich, aber unter den Bedingungen der sehr hohen Intensität der Veröffentlichung von Korrekturen in den stabilen Kern-Zweigen stehen sie vor der Wahl – alle Korrekturen zu übertragen, selektiv die wichtigsten zu portieren oder alle Korrekturen zu ignorieren.

Die optimale Lösung wäre, nur die dringendsten Fehlerbehebungen und Sicherheitsanfälligkeiten zu übertragen, aber die Herausforderung besteht darin, solche Fehler aus dem gesamten Strom herauszufiltern. Die meisten auftretenden Probleme sind auf die Verwendung der Programmiersprache C zurückzuführen, die große Sorgfalt im Umgang mit Speicher und Zeigern erfordert. Die Situation wird zusätzlich dadurch erschwert, dass viele potenzielle Sicherheitsbehebungen nicht mit CVE-IDs versehen sind oder diese erst nach einiger Zeit nach der Veröffentlichung des Fixes erhalten. Unter diesen Bedingungen fällt es den Herstellern sehr schwer, sekundäre Fixes von wichtigen Sicherheitsproblemen zu unterscheiden. Statistiken zeigen, dass über 40 % der Sicherheitsanfälligkeiten behoben werden, bevor eine CVE zugewiesen wird, und die durchschnittliche Verzögerung zwischen der Veröffentlichung eines Fixes und der Zuweisung einer CVE beträgt drei Monate (d.h. zunächst wird der Fix als gewöhnlicher Fehler betrachtet, erst nach einigen Monaten wird klar, dass es sich um eine Sicherheitsanfälligkeit handelt).

In der Folge bleibt den Herstellern von Produkten auf Basis des Linux-Kernels nichts anderes übrig, als kontinuierlich alle Fixes aus den aktuellen stabilen Branches zu übernehmen, da sie keine separate Branch für Sicherheitsfixes haben und keine Informationen über die sicherheitsrelevante Verbindung bestimmter Probleme erhalten. Diese Aufgabe erfordert jedoch erheblichen Arbeitsaufwand und stößt in den Unternehmen auf Widerstand, da man befürchtet, regressiven Veränderungen entgegenzuwirken, die das ordnungsgemäße Funktionieren des Produkts gefährden könnten.

Es sei daran erinnert, dass Linus Torvalds der Meinung ist, dass alle Fehler wichtig sind und Sicherheitsanfälligkeiten nicht von anderen Arten von Fehlern getrennt und in eine separat priorisierte Kategorie eingeordnet werden sollten. Diese Ansicht wird damit begründet, dass für einen durchschnittlichen Entwickler, der sich nicht auf Sicherheitsfragen spezialisiert hat, die Verbindung zwischen einem Fix und einer potenziellen Sicherheitsanfälligkeit nicht offensichtlich ist (für viele Fixes lässt sich nur durch eine separate Prüfung erkennen, dass sie sich auf Sicherheitsfragen beziehen). Linus ist der Meinung, dass die Identifizierung potenzieller Sicherheitsanfälligkeiten im allgemeinen Strom der Fehlerbehebungen von Sicherheitsspezialisten in den Teams, die für die Unterstützung der Paketverwaltung des Kernels in Linux-Distributionen verantwortlich sind, durchgeführt werden sollte.

Kees Cook ist der Ansicht, dass die einzige Lösung 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äftigen, 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ösen.

Wenn beispielsweise 10 Unternehmen, in denen jeweils ein Ingenieur mit dem Backportieren derselben Fehlerbehebungen beschäftigt ist, diese Ingenieure auf die Behebung von Fehlern im upstream umorientieren, könnten sie anstelle des Portierens einer einzigen Fehlerbehebung 10 verschiedene Fehler zum Wohle aller beheben oder sich an der Überprüfung der vorgeschlagenen Änderungen beteiligen und so verhindern, dass fehlerhafter Code in den Kernel aufgenommen wird. Die Ressourcen könnten auch für die Entwicklung neuer Werkzeuge zur Testung und Codeanalyse eingesetzt werden, die es ermöglichen würden, gängige Fehlerklassen schon frühzeitig automatisch zu identifizieren, die immer wieder auftauchen.

Kees Cook schlägt zudem vor, automatisiertes und Fuzzing-Testing aktiver im Entwicklungsprozess des Kernels zu nutzen, kontinuierliche Integrationssysteme anzuwenden und auf das veraltete Management der Entwicklung über 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ß an Sicherheit, wie Rust.

Quelle: opennet.ru