Linux-Kernel-Entwickler verteilen Sicherheitskorrekturen jetzt mit CVE-Einträgen

Inhaltsverzeichnis

Das bislang für stillschweigende Sicherheitskorrekturen bekannte Linux-Kernel-Projekt scheint eine Kehrtwende zu vollziehen, denn es will in Zukunft CVE-Nummern für Security-Fixes vergeben. Bei näherem Hinsehen zeigt sich allerdings: Nach wie vor stellt nichts sicher, dass alle Flicken eine CVE-Kennzeichnung erhalten. Außerdem wollen die Zuständigen offensichtlich eine Flut von CVE-IDs vergeben, was die Security-Prozesse von Linux-Distributoren und anderen Betroffenen gehörig aufmischen dürfte.

Sinneswandel durch Zwangslage und Druck von Außen

Ganz freiwillig erfolgt die Vergabe von CVE-Nummern nicht, wie Greg Kroah-Hartman in der Ankündigung des Ganzen betont. Ihm zufolge haben Externe immer mal wieder CVE-IDs für eher fragwürdige Sicherheitslücken beim Linux genannten Kernel bewilligt bekommen. Um die Vergabe selbst zu kontrollieren und derlei zu unterbinden, hat sich das Kernel.org-Projekt erfolgreich darum beworben, selbst eine CVE Numbering Authority (CNA) zu werden – ähnlich wie es die Entwickler hinter Curl, Python und einigen anderen Projekte jüngst aus dem gleichen Grund getan haben.

Laut Kroah-Hartman zufolge wäre das durch neue Gesetze und Regulierungsmaßnahmen in verschiedenen Teilen der Welt vermutlich ohnehin bald fällig geworden. Zudem sei der Druck immer größer geworden, Security-Flicken zu kennzeichnen. Zugleich betont er aber auch, den CVE-Prozess damit verbessern zu wollen, den er über die Jahre in mehreren Vorträgen harsch kritisiert hat.

CVE-IDs en masse

Durch den Schritt steht der Welt offenbar eine "groß wirkende Anzahl" von CVEs in Haus, wie es in einer Dokumentationsänderung heißt, die die Arbeitsweise des neuen "CVE Assignment Teams" beschreibt. Als Begründung führen die Autoren die zentrale Position des Kernels an, durch die "nahezu jeder Fehler die Sicherheit des Kernels gefährden kann, wobei die potenzielle Gefahr der Fehlerkorrektur aber oft nicht anzusehen ist". Zugleich betonen die Entwickler, dass viele der potenziellen oder tatsächlichen Lücken für die meisten Anwender oft irrelevant sind, da sie sich nur unter speziellen Umgebungsbedingungen ausnutzen lassen. Beispielsweise, wenn sich eine Lücke in einem Treiber steckt, der ohne die passende Hardware gar nicht erst lädt.

Statt zirka 100 bis 300 Linux-Kernel-CVEs pro Jahr stehen daher in Zukunft wohl deutlich mehr ins Haus. Wie viele genau dürfte sich erst in den kommenden Wochen und Monaten abschätzen lassen; aber zwischen den Zeilen klingt vieles nach einer nicht enden wollenden Flut.

Nachgelagerter Prozess

Die neue Arbeitsweise stellt indes keineswegs sicher, dass alle reellen Lücken tatsächlich eine CVE-Kennzeichnung bekommen. Das liegt an einer Eigenart des Entwicklungsmodells von Linux, durch die das CVE Assignment Team von sicherheitsrelevanten Fehlerkorrekturen womöglich gar nicht erfährt.

Denn laut der Dokumentationsänderung bereitet das Team automatisch die Veröffentlichung einer CVE-Nummer vor, wenn bei der Übernahme von Fehlerkorrekturen aus dem Hauptentwicklungszweig in neue Stable- und Longterm-Kernel-Versionen potenzielle Sicherheitsprobleme auffallen. Im Unterschied zu vielen anderen Open-Source-Projekten sind die Entwickler des Hauptentwicklungszweigs von Linux aber nicht verpflichtet, sich an der Pflege von Stable- und Longterm-Kerneln zu beteiligen.

Manche Korrekturen fließen nicht zurück

Eine ganze Reihe von Kernel-Entwicklern nutzt das: Sie rühren keinen Finger, um bei der Pflege der für Endanwender gedachten Versionen zu helfen, und scheren sich auch nicht darum, ob ihre Korrekturen dorthin zurückfließen; einzelne Subsysteme haben den Betreuern des Stable- und Longterm-Kernel sogar untersagt, irgendwelche Änderungen dorthin ohne explizite Erlaubnis zurückzuportieren.

Nichts deutet darauf hin, dass daran gerüttelt wurde; von außen betrachtet scheint auch nichts die Entwickler dazu zu verpflichten, das CVE Assignment Team auf potenziell sicherheitsrelevante Fehlerkorrekturen im Hauptentwicklungszweig hinzuweisen. Auch wenn einige das vermutlich machen dürften, bleibt im Dunkeln, wie viele das nicht tun. Wohl unter anderem deshalb betont das CVE Assignment Team daher explizit, dass es Sicherheitskorrekturen in veröffentlichten Kerneln manchmal übersieht; Anwender sollen daher davon ausgehen, dass eine Änderung womöglich auch sicherheitsrelevant ist, auch wenn ihr kein CVE zugewiesen wurde.

Keine CVEs für distributionsspezifische Kernel-Lücken

Die Dokumentationsänderung nennt noch einige andere Details, die manch einer so nicht erwarten dürfte. Das CVE Assignment Team will nur CVEs für Probleme vergeben, die sich in derzeit gepflegten Stable- und Longterm-Serien finden. Sollte etwa morgen eine Lücke bekannt werden, die in Linux 6.5 eingeführt und kurz vor der Freigabe von Linux 6.6 unbemerkt behoben wurde, würde das Team dafür keine CVE-Kennzeichnung vergeben, da die Pflege der 6.5.y-Serie schon vor längerem eingestellt wurde. Das wäre etwa für Ubuntu relevant, das derzeit in manchen Versionen einen auf Linux 6.5 basierten Kernel nutzt. Entdecker einer solchen Sicherheitslücke müssten sich für eine CVE Kennzeichnung daher an die Ubuntu-Macher wenden. Das Gleiche gilt, wenn jemand eine Lücke in einem Distributions-Kernel entdeckt, die so nie in den offiziellen Versionen von Linux existiert hat.

Das Team verkündet die CVEs auf einer kürzlich eigens eingerichteten Mailingliste linux-cve-announce, bei der bislang nur einige Test-Mails eingegangen sind.

(dmk)