Kees Cook, ehemaliger Chefsystemadministrator von kernel.org und Leiter des Ubuntu-Sicherheitsteams, der jetzt bei Google arbeitet, um Android und ChromeOS zu sichern, äußerte sich besorgt über den aktuellen Prozess der Fehlerbehebung in den stabilen Zweigen des Kernels. Jede Woche werden etwa hundert Fixes in die stabilen Zweige aufgenommen, und nachdem das Fenster zum Akzeptieren von Änderungen in der nächsten Version geschlossen wird, sind es fast tausend (die Betreuer behalten die Fixes, bis das Fenster geschlossen wird, und nach der Bildung von „ -rc1“ veröffentlichen sie die gesammelten auf einmal), was zu viele ist und viel Arbeit für Wartungsprodukte erfordert, die auf dem Linux-Kernel basieren.
Laut Keys wird dem Prozess der Arbeit mit Fehlern im Kernel nicht die gebührende Aufmerksamkeit geschenkt und dem Kernel fehlen mindestens 100 zusätzliche Entwickler für koordinierte Arbeiten in diesem Bereich. Die wichtigsten Kernel-Entwickler beheben regelmäßig Fehler, es gibt jedoch keine Garantie dafür, dass diese Korrekturen auf Kernel-Varianten übertragen werden, die von Dritten verwendet werden. Nutzer verschiedener Produkte, die auf dem Linux-Kernel basieren, haben zudem keine Möglichkeit zu kontrollieren, welche Fehler behoben werden und welcher Kernel in ihren Geräten verwendet wird. Letztlich sind die Hersteller für die Sicherheit ihrer Produkte verantwortlich, aber angesichts der sehr hohen Intensität der Veröffentlichung von Fixes in stabilen Kernel-Zweigen standen sie vor der Wahl: alle Fixes portieren, selektiv die wichtigsten portieren oder alle Fixes ignorieren .
Die optimale Lösung bestünde darin, nur die wichtigsten Korrekturen und Schwachstellen zu migrieren. Das Hauptproblem besteht jedoch darin, solche Fehler aus dem allgemeinen Ablauf zu isolieren. Die meisten Probleme, die auftauchen, sind auf die Verwendung der Sprache C zurückzuführen, die große Sorgfalt bei der Arbeit mit Speicher und Zeigern erfordert. Erschwerend kommt hinzu, dass viele potenzielle Schwachstellen-Patches nicht mit einer CVE-Kennung versehen sind oder erst einige Zeit nach der Veröffentlichung des Patches eine CVE-Kennung erhalten. In einer solchen Umgebung ist es für Hersteller sehr schwierig, kleinere Korrekturen von wichtigen Sicherheitsproblemen zu trennen. Laut Statistik werden mehr als 40 % der Schwachstellen behoben, bevor ein CVE zugewiesen wird, und im Durchschnitt beträgt die Verzögerung zwischen der Veröffentlichung eines Fixes und der Zuweisung eines CVE drei Monate (d. h. zunächst wird der Fix als wahrgenommen). ein normaler Fehler, aber erst nach einigen Monaten wird klar, dass die Schwachstelle behoben wurde).
Ohne einen separaten Zweig mit Korrekturen für Schwachstellen und ohne Informationen über den Sicherheitszusammenhang eines bestimmten Problems müssen Hersteller von Produkten, die auf dem Linux-Kernel basieren, daher kontinuierlich alle Korrekturen aus den neuesten stabilen Zweigen übertragen. Diese Arbeit erfordert jedoch viel Arbeit und stößt in den Unternehmen auf Widerstand, da sie befürchten, dass es zu regressiven Veränderungen kommt, die den normalen Betrieb des Produkts stören könnten.
Erinnern wir uns daran, dass laut Linus Torvalds alle Fehler wichtig sind und Schwachstellen nicht von anderen Fehlertypen getrennt und einer separaten Kategorie mit höherer Priorität zugeordnet werden sollten. Diese Meinung wird durch die Tatsache erklärt, dass für einen gewöhnlichen Entwickler, der nicht auf Sicherheitsprobleme spezialisiert ist, der Zusammenhang zwischen einem Fix und einer potenziellen Schwachstelle nicht offensichtlich ist (bei vielen Fixes lässt sich nur durch eine separate Prüfung nachvollziehen, dass es sich um Sicherheitsprobleme handelt). ). Laut Linus sollten Sicherheitsspezialisten aus den Teams, die für die Wartung der Kernel-Pakete in Linux-Distributionen verantwortlich sind, in die Identifizierung potenzieller Schwachstellen aus dem allgemeinen Patch-Strom einbezogen werden.
Kees Cook glaubt, dass die einzige Lösung zur Aufrechterhaltung der Kernel-Sicherheit zu angemessenen langfristigen Kosten darin besteht, dass Unternehmen die an der Portierung von Fixes auf lokale Kernel-Builds beteiligten Ingenieure in eine gemeinsame, koordinierte Anstrengung einbeziehen, um Fixes und Schwachstellen im Hauptkernel (Upstream) zu pflegen ). In der aktuellen Form verwenden viele Hersteller nicht die neuesten Kernel-Versionen in ihren Produkten und portieren die Fixes intern, d. h. Es stellt sich heraus, dass Ingenieure in verschiedenen Unternehmen ihre Arbeit gegenseitig duplizieren und so das gleiche Problem lösen.
Wenn beispielsweise 10 Unternehmen, von denen jedes über einen Techniker verfügt, der dieselben Korrekturen zurückportiert, diese Ingenieure mit der Behebung von Fehlern im Upstream beauftragen würden, könnten sie anstelle der Rückportierung eines Fixes 10 verschiedene Fehler zum gemeinsamen Nutzen beheben oder sich an der Überprüfung der Vorschläge beteiligen Änderungen und verhindern, dass fehlerhafter Code in den Kernel aufgenommen wird. Es könnten auch Ressourcen für die Entwicklung neuer Tools zum Testen und Analysieren von Code bereitgestellt werden, die eine frühzeitige Erkennung häufiger Fehlerklassen ermöglichen würden, die immer wieder auftauchen.
Kees Cook schlägt außerdem vor, automatisierte und Fuzzing-Tests aktiver direkt im Kernel-Entwicklungsprozess einzusetzen, kontinuierliche Integrationssysteme zu verwenden und auf das veraltete Entwicklungsmanagement per E-Mail zu verzichten. Derzeit wird effektives Testen durch die Tatsache behindert, dass die Haupttestprozesse von der Entwicklung getrennt sind und nach der Erstellung der Releases stattfinden. Keys empfiehlt außerdem, bei der Entwicklung Sprachen zu verwenden, die ein höheres Maß an Sicherheit bieten, wie etwa Rust, um die Fehleranzahl zu reduzieren.
Source: opennet.ru