Linux: Kritik, Gründe und Folgen der CVE-Schwemme im Kernel

Inhaltsverzeichnis

Allerlei Administratoren und Entwickler klagen seit einigen Monaten lautstark: Mussten sie jahrelang nur auf meist vier bis sechs Sicherheitslücken pro Woche beim Linux-Kernel reagieren, sind es seit Februar mehr als zehnmal so viele. Prominente Kernel-Entwickler haben jüngst in Vorträgen und Diskussionsrunden zur Schwemme von CVE-Kennzeichnungen betont, die neue Situation sei etwas Gutes. Dabei deuteten sie an, darüber jammernde Distributoren würden mit ihren Klagen zu erkennen geben, die Sicherheitsproblematik zuvor nicht ernst genommen zu haben – und somit wichtige, aber nicht explizit als Security-Fix ausgewiesene Korrekturen ignoriert zu haben.

Einige größere Unternehmen haben das offenbar eingesehen und erwägen verschiedene Aktivitäten, um die neue Lage für sich und ihre Kunden erträglicher zu machen. Das dürfte irgendwann auch Hobby-Admins zugutekommen. Weil dazu aber enorm viel Arbeit an verschiedenen Fronten nötig ist, könnte das eine Weile dauern, wie sich bei genauerem Hinsehen zeigt.

Über 3000 CVEs seit Februar

Ursache für die veränderte Lage sind die Entwickler des Linux genannten Kernels. Jahrzehntelang hatten sie sich kein bisschen um Kennzeichnungen wie CVE (Common Vulnerabilities and Exposures) geschert; immer wieder haben sie sogar CVE-IDs verschwiegen oder gar aus Patch-Beschreibungen entfernt, um den Sicherheitsaspekt von Änderungen zu verschleiern. Aber weil Externe immer häufiger CVEs für fragwürdige Kernel-Lücken bewilligt erhielten, sahen sich die Entwickler Anfang des Jahres gezwungen, zur CNA (CVE Numbering Authority) zu werden, um die Vergabe von CVE für Linux selbst zu kontrollieren – ähnlich wie andere Open-Source-Projekte zuvor.

Die zuständigen Linux-Entwickler haben seit Februar rund 3375 CVE-Kennzeichnungen vergeben, darunter aufgrund von Vorgaben bei der Gründung auch allerlei für in den Vorjahren gestopfte Schwachstellen. Nach Einsprüchen haben die Zuständigen rund hundert dieser CVEs zurückgezogen. Viele Externe, aber auch allerlei Entwickler des offiziellen Kernels kritisieren indes, viele der anderen CVE seien auch ungerechtfertigt, weil keine echte Schwachstelle geflickt wurde.

CVEs für noch so kleine Schwachstellen sind Vorschrift

Greg Kroah-Hartman als Haupttriebkraft hinter dem Ganzen und zweitwichtigster Kernel-Entwickler reagiert auf diese Vorwürfe immer wieder gleich: Die Richtlinien für die CVE-Vergabe würden ihn und die anderen Zuständigen verpflichten, eine CVE-Kennzeichnung an jedwede potenzielle Schwachstelle vergeben zu müssen, die sie beseitigen. Ferner führt er an, die Leute würden Linux auf die unterschiedlichsten Arten einsetzen – und dadurch lässt sich nur sehr schwer abschätzen, ob eine eher harmlos wirkende Korrektur in bestimmten Einsatzgebieten dann eben doch sicherheitsrelevant ist.

An Details Interessierten sei hier die Präsentation und das Video eines kürzlich von Kroah-Hartman gegebenen Vortrags empfohlen, in dem er diese Aspekte näher erläutert und zahlreiche andere Einblicke liefert. So führt er an, der Kernel sei mit rund 55 CVEs pro Woche nicht der Spitzenreiter: Wordpress veröffentliche beispielsweise über 110 die Woche. Auch auf das Prozedere geht er ein: Die Vergabe erfolgt zudem erst einige Tage oder Wochen, nachdem die Korrekturen in neue und für Anwender gedachte Kernel-Versionen eingeflossen sind.

Drei Leute müssen übereinkommen, um einen CVE zu vergeben

Die Zuständigen vergeben CVEs zudem nur an Schwachstellen, wenn drei derzeit involvierten Entwickler im öffentlich erfolgenden Review-Prozess dafür stimmen. Die eigentlichen Programmierer der Änderungen oder die Maintainer des jeweiligen Kernel-Codes sind dabei nicht involviert – diese sind aber ohnehin oft keine Security-Experten und die Maintainer oft ohnehin schon an oder jenseits der Belastungsgrenze, wie Kroah-Hartman kürzlich anderswo betonte. Wie schon seit vielen Jahren rät er Nutzern zudem nach wie vor, einfach den jeweils neueste Version der neuesten Stable- oder Longterm-Kernel-Serie zu nutzen, um bekannte Lücken zu vermeiden.

Die Wahl zwischen zwei Übeln

In einer Vortragsfolie zitiert Kroah-Hartman zudem Kees Cook, dessen großes Engagement seit über einem Jahrzehnt den Linux-Kernel deutlich sicherer gemacht hat. Ihm zufolge haben auf den sichersten Kernel bedachte Nutzer nur die Wahl zwischen zwei Herangehensweisen: Entweder die jeweils neueste Version einer aktuellen Serie einsetzen oder halt jeden einzelnen CVE-Eintrag näher zu untersuchen – um dann die Korrekturen für jene Schwachstellen zu übernehmen, die für eingesetzten Kernel im konkreten Einsatzgebiet relevant sind. Beides bereitet viel Arbeit und Umstände, etwa wenn Reboots schwer oder unmöglich sind; jeder muss Cook zufolge selbst sehen, welcher der beiden Ansätze im jeweiligen Umfeld einfacher ist.

Cooks Ausführungen stammen aus einer offenen Diskussion zur neuen Situation bei Kernel-CVE, die kürzlich auf der Linux Plumbers Conference stattfand. Beteiligt waren Kernel-Entwickler von zahlreichen großen und kleinen Firmen, die Linux intern oder in Produkten einsetzen. Die Runde schnitt ganz unterschiedliche Bereiche an und hinterließ allerlei ungeklärte Fragen. Dennoch ist das eine oder andere absehbar.

Threat Models sollen Zusammenarbeit ermöglichen

Recht konkret klangen Erwägungen von Entwicklern verschiedener Firmen, eine Handvoll von Bedrohungsmodellen zu definieren. Interessierte Parteien können dann in Arbeitsteilung nach Open-Source-Gedanken die CVEs durchgehen und für jeden festlegen, ob der für das jeweilige Threat Model relevant ist.

Ein solches Bedrohungsmodell könnte das des "Cloud-Anbieters" sein: moderne ARM64- und x86-64-Server-Hardware mit voll vertrauenswürdigen Nutzern, aber virtuelle Maschinen mit in keiner Weise vertrauenswürdiger Software. Firmen wie Amazon/AWS, Google, IBM und Microsoft könnten dann in Kooperation festlegen, welche CVEs für dieses Threat Model relevant sind, statt das jeweils hausintern machen zu müssen. Die Resultate dieser und ähnlicher Analysen könnten dann in die JSON-Dateien zurückfließen, die schon jetzt zentral alle Details zu den CVEs bündeln.

Viel Aufwand für flexible Enterprise-Linuxe

Andere angesprochene Bedrohungsmodelle waren Automotive oder Enterprise Linux. Letzteres dürfte, sofern es denn je dazu kommt, aber wohl eher für bezüglich Hardware-Unterstützung und Einsatzgebieten klar abgegrenzte Linux-Distributionen passen. Also jenen, wie sie Amazon/AWS, Google, Meta, Microsoft, Oracle, Red Hat oder SuSE anbieten oder hausintern einsetzen. Schon für die wäre ein Einstufen der CVEs ein Heidenaufwand. Wollte man mit deutlich mehr Funktionen und Treibern kompilierte Kernel wie jenen von Debian einbeziehen, würde der Aufwand abermals stark steigen – womöglich so weit, dass sich niemand findet, die nötige Arbeit freiwillig zu machen oder jemanden dafür zu bezahlen.

Ein zugehöriger Aspekt wurde in der Diskussionsrunde nur gestreift, aber im Umfeld diskutiert: Das Fehlen von Open-Source-Werkzeugen, die überprüfen, ob der vom CVE betroffene Code überhaupt im eingesetzten Kernel enthalten ist – entweder direkt oder in einem Modul, das sich lokal leicht entfernen oder blockieren ließe. Zumindest Google, Oracle und SuSE verwenden hausintern schon länger solche Tools, wie im Umfeld bekannt wurde. Vermutlich ist es nur eine Frage der Zeit, bis jemand solch ein Werkzeug unter einer quelloffenen Lizenz veröffentlicht, um angesichts der Lage in Zukunft hier an einem Strang zu ziehen.

Das Thema Live-Patching wurde nur gestreift, denn auch dort gibt es noch offene Fragen. Mittels dieser Technik alle oder zumindest einen größeren Batzen der CVE-Fixes zur Laufzeit einzuspielen, wäre vielleicht theoretisch denkbar, in der Praxis aber schwer zu realisieren: Das Erstellen und Verifizieren solch komplexer Live-Patches ist dazu zu arbeits- und zeitintensiv. Letztlich dürfte es dadurch vermutlich gelingen, Reboots einige Wochen zu vermeiden, aber nicht viele Monate.

Ein Teilnehmer der Diskussionsrunde sprach indes an, dass die vielen CVEs ein riesiges Problem in Bereichen sind, wo Updates aufgrund von Zertifizierungs-Vorschriften schwer und teuer sind – etwa beim Linux-Einsatz in Krankenhäusern. Kroah-Hartman erklärte dazu, die Gesetzgeber von USA und EU hätten das Problem erkannt und arbeiteten an Lösungen, was aber Zeit erfordere.

Eine Aufzeichnung der Diskussionsrunde findet sich im Live-Stream der Konferenz; kurz nach dem Beginn fehlen aber einige Minuten des Tones.

(dmk)