Sind alle Kernel von Linux-Anbietern unsicher? Eine neue Studie sagt ja, aber es gibt eine Lösung

Laut einem CIQ-Whitepaper weisen alle Kernel-Anbieter Sicherheitslücken auf. Wird die Linux-Community jemals stabile Upstream-Kernel akzeptieren?

In einem neuen Whitepaper mit dem Titel „Vendor Kernels, Bugs and Stability“ präsentiert das Infrastruktursoftware- und Rocky-Linux-Unternehmen CIQ ein überzeugendes Argument dafür, dass Kernel von Linux-Anbietern aufgrund der fehlerhaften Engineering-Prozesse, die durch den Backport behoben werden, mit Sicherheitslücken geplagt sind. 

Während dies einige schockieren mag, ist es in der Linux-Community ein offenes Geheimnis. Wie Greg Kroah-Hartman, Betreuer des stabilen Linux-Kernels und prominentes Mitglied des Kernel-Sicherheitsteams, kürzlich sagte: Um sicher zu sein, sollten Sie immer den neuesten langfristig stabilen Kernel verwenden. Das Schlüsselwort hier ist „neueste“. Es reicht nicht aus, ein LTS zu verwenden. Um größtmögliche Sicherheit zu gewährleisten, müssen Sie die aktuellste Version verwenden.   

Leider macht das fast niemand. Dennoch erklärte Kees Cook, Kernel-Ingenieur von Google Linux: „Was soll ein Anbieter also tun? Die Antwort ist einfach: Wenn es schmerzhaft ist: Aktualisieren Sie kontinuierlich auf die neueste Kernel-Version, entweder Major oder Stable.“

Warum? Kroah-Hartman erklärte: „Jeder Fehler kann ein Sicherheitsproblem auf Kernel-Ebene darstellen.“ 

Jonathan Corbet, Linux-Kernel-Entwickler und LWN-Chefredakteur, stimmte zu: „Im Kernel kann nahezu jeder Fehler, wenn man schlau genug ist, ausgenutzt werden, um das System zu gefährden. Der Kernel befindet sich an einer einzigartigen Stelle im.“ System ... es verwandelt viele gewöhnliche Fehler in Schwachstellen.

Was die CIQ-Ingenieure Ronnie Sahlberg, Jonathan Maple und Jeremy Allison taten, war, konkrete Zahlen für diese Position anzugeben. Ihr Papier zeigt, dass – mit den aktuellen technischen Praktiken – fast alle Kernel der Anbieter von Natur aus unsicher sind und dass es unmöglich ist, diese Kernel zu sichern. 

Das liegt daran, dass Kernel von Linux-Anbietern erstellt wurden, indem ein Snapshot einer bestimmten Linux-Version erstellt und dann ausgewählte Fixes zurückportiert wurden, wenn Änderungen im Upstream-Git-Baum auftreten. Diese Methode, die in einer Zeit entwickelt wurde, als Out-of-Tree-Gerätetreiber weit verbreitet waren, zielt darauf ab, die Stabilität und Sicherheit durch die Auswahl von Änderungen am Backport zu verbessern. In diesem Artikel wird untersucht, wie dies in der Praxis funktioniert, indem die Änderungsrate und Fehleranzahl in Red Hat Enterprise Linux (RHEL) 8.8, Kernel-Version 4.18.0-477.27.1 analysiert und mit Upstream-Kerneln von kernel.org verglichen wird.

Obwohl die Programmierer RHEL 8.8 speziell untersucht haben, handelt es sich hierbei um ein allgemeines Problem. Sie hätten die gleichen Ergebnisse gefunden, wenn sie SUSE, Ubuntu oder Debian Linux untersucht hätten. Rolling-Release-Linux-Distributionen wie Arch, Gentoo und OpenSUSE Tumbleweed veröffentlichen ständig die neuesten Updates, werden jedoch nicht in Unternehmen verwendet. 

Ihre Analyse des RHEL 8.8-Kernels zeigt 111.750 einzelne Commits im Änderungsprotokoll. Diese Daten machen zwar keine Angaben zum Inhalt oder zur Größe der Commits, bieten aber ein allgemeines Verständnis des Backporting-Prozesses. Anfangs gab es eine konstante Backportierungsrate, die jedoch etwa im November 2021 abnahm und im November 2022, entsprechend der Veröffentlichung von RHEL 8.5 bzw. RHEL 8.7, erneut deutlich abnahm. Nach Ansicht der Autoren spiegelt dieses Muster eine Verlagerung hin zu einem konservativeren Backporting wider, um die Stabilität im Verlauf des großen Release-Zyklus zu verbessern.

Ihre Untersuchung ergab 5.034 nicht behobene Fehler in RHEL 8.6; 4.767 nicht behobene Fehler in RHEL 8.7; und 4.594 nicht behobene Fehler in RHEL 8.8. 

Diese Zahlen stellen bekannte Fehler mit Upstream-Korrekturen dar, die nicht nach RHEL zurückportiert wurden. Die frühere Einstellung des Backportings in RHEL 8.6 und 8.7 hat im Vergleich zu RHEL 8.8 zu mehr nicht behobenen Fehlern geführt. Die Praxis von Red Hat, nicht die vollständigen Quellcodeänderungen zu veröffentlichen, erhöht die Komplexität und führt zu möglichen falsch positiven und negativen Ergebnissen in den Daten, mit denen CIQ arbeiten musste. Trotz dieser Einschränkungen berichtet CIQ, dass manuelle Überprüfungen auf eine hohe Genauigkeit bei der Identifizierung fehlender Korrekturen schließen lassen.

Entgegen der Annahme, dass Fehler im Vorfeld schnell behoben werden, bleiben viele Fehler über einen längeren Zeitraum bestehen, bevor sie behoben werden. Diese Verzögerung wirkt sich auf die Kernelqualität aus, da der langsamere Backportierungsprozess zu einer zunehmenden Anzahl bekannter, nicht behobener Fehler führt, was im Laufe der Zeit die Stabilität und Sicherheit des Kernels beeinträchtigt.

Seitdem Linux-Kernel-Entwickler die Verwaltung der Common Vulnerabilities and Exposures (CVEs) von Linux übernommen haben, wurden im März 2024 270 neue CVEs und im April 2024 342 neue CVEs gemeldet. Diese wurden bereits im stabilen Git-Zweig des Linux-Kernels behoben. 

Dennoch unterstreichen die bloßen Zahlen, wie wichtig die Verwendung stabiler Upstream-Kernel für mehr Sicherheit ist. Die Menge neuer CVEs und das Fehlen einer Embargofrist für Fehlerbehebungen erfordern einen proaktiven Ansatz von Organisationen bei der Bewertung und Behebung dieser Schwachstellen. 

Obwohl RHEL 8.8 seit Ende 2022 nicht mehr aktiv weiterentwickelt wurde, ist es immer noch von etwa 10 % aller neu entdeckten Fehler betroffen. Die letzten großen Fehlerbehebungen für RHEL 8.8 erfolgten im Mai 2023. Das Gleiche gilt für andere, ältere (aber immer noch unterstützte) Enterprise-Linux-Distributionen. Noch besorgniserregender ist laut CIQ: „Einige der fehlenden Korrekturen, die wir untersucht haben, werden ausdrücklich als aus dem Benutzerbereich ausnutzbar gemeldet.“

Daher kam das CIQ-Team zu dem Schluss, dass das traditionelle Kernelmodell des Anbieters, das durch selektives Backporting gekennzeichnet ist, fehlerhaft ist. Die wachsende Zahl bekannter, nicht behobener Fehler lässt darauf schließen, dass die Kernel der Hersteller weniger sicher sind als die stabilen Kernel der Originalautoren. Das Team plädiert für eine Umstellung auf die Verwendung stabiler Kernel-Zweige von kernel.org für bessere Sicherheit und Fehlerverwaltung.

Den Autoren zufolge „schaffe dies einen starken Anreiz“ für sicherheitsbewusste Kunden, stabile Kernel gegenüber herstellerspezifischen Kerneln zu verwenden. Sie behaupten: „Wir glauben, dass der einzig realistische Weg für einen Kunden, zu wissen, dass er einen möglichst sicheren Kernel betreibt, darin besteht, zu einem stabilen Kernel-Zweig zu wechseln.“  

Dieses Papier ist keine Kritik an den engagierten Kernel-Ingenieuren der Linux-Anbieter. Stattdessen ist es eine Einladung an die Branche, sich hinter die stabilen Kernel von kernel.org als optimale langfristige Lösung zu stellen. Eine solche Verschiebung würde es den Ingenieuren ermöglichen, sich mehr auf die Behebung kundenspezifischer Fehler und die Verbesserung von Funktionen zu konzentrieren, anstatt auf den arbeitsintensiven Backporting-Prozess.

Daher kommen sie zu vier entscheidenden Schlussfolgerungen:

• Das Kernelmodell des Anbieters ist defekt und kann nicht mehr repariert werden.
• Herstellerkerne sind von Natur aus unsicher, wobei spätzyklusstabilisierte Herstellerkerne besonders anfällig sind.
  
• Die schiere Anzahl bekannter offener Fehler macht es unpraktisch, sie alle zu analysieren oder zu klassifizieren.
  
• Vorgelagerte stabile Kernel bieten einen deutlich besseren Schutz vor Sicherheitslücken und Fehlern im Kernel-Code.
  

Werden die Anbieter dies tun? Für all die guten Sicherheitsgründe, auf stabile Upstream-Kernel umzusteigen, gibt es Gegenargumente, die auf Folgendes hinauslaufen: Wenn Sie immer auf den neuesten Kernel aktualisieren, können auch Stabilitätsprobleme auftreten. Ein Programm, das mit dem Kernel 4.18.0-477.27.1 einwandfrei funktioniert, funktioniert möglicherweise nicht mit 4.18.0-477.27.1.el8_8. Natürlich hat der neuere Kernel in diesem speziellen Fall einen wichtigen Sicherheitsfehler behoben. 

Es kommt auf einen heiklen Balanceakt zwischen Sicherheit und Stabilität an. Einige führende Linux-Kernel-Entwickler und CIQ stellen sich auf die Seite der Sicherheit. Wir werden sehen, was der Rest der Linux-Anbieter-Community zu sagen hat.