// LINUXNEWS.DE — LINUX & OPEN SOURCE
1313 Kernel-CVEs: Wenn die Sicherheitslücke zum Normalfall wird
Debian hat am 29. September ein Sicherheitsupdate für den Linux-Kernel veröffentlicht. Was zunächst nach einem gewöhnlichen Debian Security Advisory klingt, fällt durch eine ungewöhnliche Zahl auf: DSA-6528-1 führt insgesamt 1313 CVE-Kennungen auf. Die Liste der damit behobenen oder für Debian relevanten Schwachstellen ist so lang, dass sie bei LWN den größten Teil der Meldung einnimmt.
1313 Sicherheitslücken in einem einzigen Update? Die Zahl wirkt alarmierend, sagt für sich genommen aber erstaunlich wenig über die Sicherheit des Linux-Kernels aus. Vielmehr zeigt sie, wie grundlegend sich der Umgang mit CVEs im Kernel in den vergangenen Jahren verändert hat. Sie wirft zudem die Frage auf, wie lange Entwickler, Distributionen und Administratoren mit immer weiter steigenden Zahlen sinnvoll umgehen können.
Seit Anfang 2024 besitzt das Linux-Kernel-Projekt den Status einer CVE Numbering Authority (CNA) und kann damit selbst CVE-Kennungen vergeben. Dahinter steht nicht zuletzt die Unzufriedenheit der Kernel-Entwickler mit der früheren Praxis, bei der externe Organisationen teilweise CVEs für Kernel-Probleme vergaben, ohne deren Bedeutung oder betroffene Versionen zuverlässig einschätzen zu können.
Das Kernel-Team verfolgt seitdem einen ausgesprochen vorsichtigen Ansatz. Im Rahmen des normalen Stable-Prozesses werden Änderungen identifiziert, die möglicherweise sicherheitsrelevant sind, und dafür automatisiert CVE-Nummern vergeben. Die Kernel-Dokumentation erklärt die daraus resultierenden hohen Zahlen bemerkenswert offen: Aufgrund der zentralen Stellung des Kernels könne prinzipiell fast jeder Fehler zur Beeinträchtigung der Systemsicherheit ausgenutzt werden. Da dies zum Zeitpunkt der Fehlerbehebung häufig noch gar nicht sicher beurteilt werden könne, vergebe das CVE-Team im Zweifelsfall lieber eine Kennung.
Eine CVE steht damit beim Linux-Kernel längst nicht mehr zwangsläufig für eine bekannte und praktisch ausnutzbare Sicherheitslücke. Häufig handelt es sich um einen normalen Bugfix, bei dem eine sicherheitsrelevante Auswirkung lediglich nicht ausgeschlossen werden kann.
Auch die Zahl 1313 bedeutet folglich nicht, dass Debian gerade mehr als tausend akut ausnutzbare Schwachstellen entdeckt und behoben hätte. Hinzu kommt, dass ein installiertes System nur einen Bruchteil des enormen Kernel-Quellcodes tatsächlich nutzt. Das Kernel-Projekt weist deshalb selbst darauf hin, dass zahlreiche veröffentlichte CVEs für ein konkretes System überhaupt keine Relevanz besitzen.
Für die Kernel-Entwickler selbst bedeutet die steigende Zahl der CVEs daher nicht automatisch einen entsprechenden zusätzlichen Arbeitsaufwand. Viele der zugrunde liegenden Fehler wären ohnehin gefunden, korrigiert, überprüft und gegebenenfalls in die unterstützten Stable-Kernel zurückportiert worden. Die CVE-Vergabe baut auf diesem Prozess auf und erfolgt erst, nachdem ein Fix verfügbar ist und in einen Stable-Kernel aufgenommen wurde.
Damit verschiebt sich das Problem allerdings. Distributionen wie Debian müssen nachvollziehen, welche dieser Änderungen ihre Kernel betreffen. Hersteller von Sicherheitswerkzeugen müssen die Informationen aufbereiten. Unternehmen wiederum müssen entscheiden, welche CVEs für ihre Systeme tatsächlich relevant sind. Compliance-Vorgaben und Vulnerability-Scanner erzeugen aus jeder einzelnen Kennung möglicherweise ein Ticket, das bewertet, dokumentiert und geschlossen werden muss.
Bei einigen Dutzend CVEs lässt sich ein solcher Prozess noch weitgehend manuell bewältigen. Bei mehr als tausend Kennungen aus einem einzigen Kernel-Update wird offensichtlich, dass dieses Modell nicht beliebig skaliert.
Die reine Anzahl einer CVE verliert dabei zunehmend ihre Signalwirkung. Ursprünglich soll eine CVE eine öffentlich bekannte Schwachstelle eindeutig identifizierbar machen. Wenn jedoch ein großer Teil der normalen Kernel-Bugfixes vorsorglich mit einer solchen Kennung versehen wird, bedeutet »hat eine CVE« kaum noch automatisch »benötigt be