Kis Cook von Google hat dazu aufgerufen, den Fehlerbearbeitungsprozess im Linux-Kernel zu modernisieren.

Kees Cook, ehemaliger Hauptsystemadministrator von kernel.org und Leiter des Ubuntu-Sicherheitsteams, der derzeit bei Google an der Sicherheit von Android und ChromeOS arbeitet, äußerte Bedenken über den aktuellen Prozess zur Behebung von Fehlern in den stabilen Kernel-Versionen. Wöchentlich werden rund einhundert Korrekturen in die stabilen Versionen integriert, während nach dem Schließen des Änderungsfensters für die nächste Version die Zahl gegen tausend steigt (da die Entwickler Korrekturen bis zum Schließen des Fensters zurückhalten und nach der Erstellung von "-rc1" die gesammelten Änderungen auf einmal veröffentlichen). Dies ist zu viel und erfordert enormen Aufwand für die Pflege von Produkten, die auf dem Linux-Kernel basieren.

Laut Kisa wird der Umgang mit Fehlern im Kernel nicht ausreichend beachtet, und es mangelt dem Kernel an mindestens 100 zusätzlichen Entwicklern, um in diesem Bereich koordiniert arbeiten zu können. Die Hauptentwickler des Kernels beheben regelmäßig Fehler, aber es gibt keine Garantie, dass diese Fixes in die Kernel-Versionen übernommen werden, die von Drittanbietern verwendet werden. Benutzer verschiedener Produkte auf Basis des Linux-Kernels haben auch keine Möglichkeit, zu kontrollieren, welche Fehler behoben wurden und welche Kernel-Version in ihren Geräten eingesetzt wird. Letztendlich sind die Hersteller für die Sicherheit ihrer Produkte verantwortlich, aber angesichts der hohen Frequenz an veröffentlichten Korrekturen in den stabilen Kernels stehen sie vor der Wahl – ob sie alle Korrekturen übernehmen, selektiv die wichtigsten portieren oder alle Korrekturen ignorieren.

Die optimale Lösung wäre, nur die wichtigsten Fehlerbehebungen und Sicherheitslücken zu übertragen. Das Hauptproblem liegt jedoch darin, solche Fehler aus dem allgemeinen Kontext herauszufiltern. Die häufigsten 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ächst keine CVE-IDs zur Verfügung haben oder diese erst nach einer gewissen Zeit nach der Veröffentlichung des Patches erhalten. Unter diesen Bedingungen fällt es den Herstellern schwer, nebensächliche Behebungen von kritischen Sicherheitsproblemen zu unterscheiden. Statistiken zeigen, dass über 40 % der Sicherheitsanfälligkeiten behoben werden, bevor eine CVE-ID zugewiesen wird, und die durchschnittliche Verzögerung zwischen der Veröffentlichung des Patches und der Zuweisung einer CVE-ID beträgt drei Monate. Das bedeutet, dass anfänglich die Behebung als ein gewöhnlicher Fehler betrachtet wird, erst einige Monate später wird klar, dass es sich um eine Sicherheitsanfälligkeit handelt.

In der Konsequenz bleibt den Herstellern von Produkten, die auf dem Linux-Kernel basieren, nichts anderes übrig, als ständig alle Korrekturen aus den neuesten stabilen Zweigen zu übernehmen, da es keinen separaten Zweig für die Behebung von Sicherheitsanfälligkeiten gibt und Informationen über die Sicherheitsrelevanz eines bestimmten Problems fehlen. Diese Arbeit ist jedoch sehr zeitaufwendig und stößt in Unternehmen auf Widerstand, da befürchtet wird, dass regressiven Änderungen, die die ordnungsgemäße Funktion des Produkts beeinträchtigen könnten, auftreten könnten.

Laut Linus Torvalds sind alle Fehler wichtig und Sicherheitsanfälligkeiten sollten nicht von anderen Arten von Fehlern getrennt und in eine gesonderte, prioritärere Kategorie eingeordnet werden. Diese Auffassung wird damit erklärt, dass für einen typischen Entwickler, der sich nicht auf Sicherheitsfragen spezialisiert hat, die Verbindung zwischen einem Fix und einer potenziellen Sicherheitsanfälligkeit nicht offensichtlich ist (bei vielen Fixes ermöglicht nur eine separate Prüfung zu erkennen, dass sie die Sicherheit betreffen). Nach Linus' Ansicht sollten die Fachleute für Sicherheit aus den Teams, die für die Unterstützung der Kernpakete in den Linux-Distributionen zuständig sind, die Identifizierung potenzieller Sicherheitsanfälligkeiten aus dem allgemeinen Strom der Fixes übernehmen.

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älligkeiten 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ührt, dass Ingenieure in verschiedenen Unternehmen die Arbeit anderer duplizieren, um dasselbe Problem zu lösen.

Wenn beispielsweise 10 Unternehmen, in denen jeweils ein Ingenieur mit dem Backporting derselben Fehlerbehebungen beschäftigt ist, diese Ingenieure stattdessen auf die Behebung von Fehlern im Upstream umschichten, könnten sie anstelle des Portierens einer einzigen Korrektur 10 verschiedene Fehler zugunsten aller beheben oder sich an der Überprüfung vorgeschlagener Änderungen beteiligen, um zu verhindern, dass fehlerhafte Codes in den Kernel aufgenommen werden. Die Ressourcen könnten auch zur Entwicklung neuer Werkzeuge für die Testung und Analyse von Codes verwendet werden, die es ermöglichen würden, typische Klassen von Fehlern frühzeitig automatisch zu erkennen, die immer wieder auftreten.

Kees Cook fordert auch eine aktivere Nutzung automatisierter Tests und Fuzzing-Tests direkt während der Kernel-Entwicklung, die Anwendung von Continuous Integration-Systemen und die Abkehr von der veralteten Verwaltung der Entwicklung über E-Mail. Derzeit wird eine effektive Testdurchführung dadurch behindert, dass die Haupttestprozesse von der Entwicklung getrennt sind und erst nach der Erstellung von Releases stattfinden. Kees empfahl außerdem, bei der Entwicklung Sprachen zu verwenden, die mehr Sicherheit bieten, ein hohes Maß an Sicherheit., wie Rust.

Quelle: opennet.ru