ClickCease Die große Kernel-CEVE-Flut von 2024

Inhaltsübersicht

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Die große Kernel-CEVE-Flut von 2024

von Joao Correia

Dezember 12, 2024 - Technischer Evangelist

"Wir tun nur das, was cve.org von uns verlangt", wiederholte Greg K-H mehrfach in einer einer kürzlichen Präsentation. Anfang des Jahres überraschte der neue CNA-Status (CVE Numbering Authority) des Kernel-Teams viele in der Sicherheitsbranche. Nicht nur, dass die frühere Haltung völlig gegen das CVE-System gerichtet war - "Verbrennt sie!" war eine vorgeschlagene Lösung - sondern sie benutzten auch einen anderen Ansatz, um Schwachstellen zu verfolgen (commit ids) und sie nicht von vornherein als Sicherheitslücken zu veröffentlichen.

Die CNA-Änderung hat sich auf die gesamte Branche ausgewirkt, und zwar aus Gründen, die immer offensichtlicher werden: Es gibt nicht nur mehr CVEs, sondern die große Anzahl erschwert auch das Verfolgen, Analysieren und Identifizieren der wichtigen CVEs.

Aber das wurde alles schon diskutiert zuvor von uns (und von vielen anderen in der Branche). Es gibt sogar einen einen Bericht, den wir vor ein paar Monaten veröffentlicht habenwenn Sie sich dafür interessieren.

Interessant ist der Standpunkt des Kernel-Teams selbst zu diesem Thema, und in diesem Artikel werden wir die letzte Präsentation analysieren und das Problem identifizieren, das bei dieser Präsentation umgangen wurde. 

Der gesamte unten zitierte Text ist der Präsentation entnommen "CVEs sind lebendig, aber keine Panik!" von Greg K-H entnommen, wobei der Kontext so weit wie möglich beibehalten wurde.

 

Der Elefant im Zimmer

 

Lassen Sie uns mit einigen Zahlen beginnen. Diese werden in der Präsentation ausdrücklich genannt. Die Kernel CNA gibt derzeit (Stand: Oktober 2024) durchschnittlich 55 neue CVEs pro Woche. Das ist etwas weniger als die 60 pro Woche, die in den ersten Monaten der CNA-Aktivitäten auftraten. In früheren Jahren gab es jedoch laut der Präsentation etwa 20 CVEs pro Quartal.

Die ursprüngliche Politik des Kernel-CNA wurde als "Jeder Fehler wird gefunden"-Ansatz interpretiert. Dies wurde nun dahingehend erweitert, dass nur etwa 20 % der Bugs tatsächlich eine Bestätigung erhalten - und das sind 55 pro Woche. "Das ist eine Menge." Wenn man die Linux-Kernel-Mailingliste verfolgt, scheint das ungefähr richtig zu sein. 

Der Prozess läuft folgendermaßen ab: Für jede stabile Übergabe gibt es (mindestens) drei Personen, die sie sich ansehen und entscheiden, ob sie ein CVE verdient oder nicht. Wenn es keinen Konsens gibt, wird dies öffentlich diskutiert. Wenn ein solcher Konsens erreicht wird, wird ein CVE zugewiesen. 

Wenn ein CVE für einen bestimmten Fehler zugewiesen wurde, kann es immer noch nachträglich widerrufen werden, wenn überzeugende Argumente vorgelegt werden. Dies macht 1 bis 2 % der zugewiesenen CVEs aus.

 

Der Kernel CNA ist nicht die Nummer 1

 

...außer, dass es das ist. Aufgrund der (sehr großen) Zahlen, um die es hier geht, und natürlich, um auf Kritik einzugehen, enthält die Präsentation eine Liste mit anderen Projekten und der Anzahl der wöchentlichen CVEs, die sie erzeugen. WordPress steht mit 112 pro Woche an der Spitze - mit dem Vorbehalt, dass es sich nicht wirklich um WordPress handelt, da es alle Plugins und Themes einschließt, so dass es nicht wirklich 112 pro Woche sind. MITRE wird mit 95 pro Woche angezeigt, aber auch das ist kein einzelnes Projekt. Windows (11-12), Chrome (6), macOS (6), iOS (2-3) stehen ebenfalls auf der Liste. Open Source vs. Closed Source bedeutet, dass diese Zahlen nicht von unabhängiger Seite auf ihre Richtigkeit überprüft werden können, aber dass der Kernel mehr CVEs als jedes andere Einzelprojekt da draußen und mehr als alle konkurrierenden Betriebssysteme zusammen hat, könnte mehr über mögliche Probleme mit dem Prozess als mit dem Kernel selbst aussagen.

 

Warum ist das passiert?

 

Der angegebene Grund für den Beginn der Ausgabe von CVEs war ein zweifacher: Erstens erlaubte cve.org nun Open-Source-Projekten, ihre eigenen CNAs zu haben, und zweitens gibt es Gesetze und Vorschriften, die die Offenlegung von Schwachstellen in verschiedenen Gerichtsbarkeiten vorschreiben (mit weitere werden folgen).

"Wir sind dazu verpflichtet" [in Bezug auf die Ausstellung von CVEs], also kann der sprichwörtliche Geist nicht einfach wieder in die Flasche gesteckt werden.

 

Was macht eine Schwachstelle aus?

 

Einer der Hauptunterschiede zwischen dem Kernel-CNA und den CNAs anderer Projekte ist, wie bereits erwähnt, die große Anzahl der veröffentlichten CVEs. Dies läuft auf die Interpretation der Definition von CVE durch cve.org hinaus. Nach der Lesart des Kernel-Teams erfordern die folgenden Fehler die Erstellung eines neuen CVEs (zitiert aus der Präsentation):

  • "Jeder durch den Benutzer auslösbare Absturz oder Neustart
  • Speichernutzung nach dem Freisetzen / Leck / Überlauf
  • Falsche Grenzkontrollen
  • Denial of Service
  • Logische Fehler
  • Viele andere Dinge"

Die folgenden werden ausdrücklich NICHT als Schwachstellen betrachtet und erhalten keine CVEs:

  • "Datenbeschädigung / -verlust
  • Leistungsprobleme
  • Fehlerbehebungen, die nicht von außen ausgelöst werden
  • Keine Hardware CVEs"

Insbesondere der erste Punkt in der zweiten Liste, die Datenbeschädigung, verdient eine längere Erläuterung während der Präsentation, und, offen gesagt, wenn man potenzielle Datenverluste nicht als Sicherheitsprobleme betrachtet, ignoriert man die damit verbundenen potenziellen Denial-of-Service-Angriffe (wie ein Zuhörer in der Frage- und Antwortrunde richtig bemerkte). Die Begründung? "Wir folgen den Richtlinien von cve.org. Es ist deren Problem, nicht unseres." Keine sehr hilfreiche Position.

"Viel Glück bei der Suche nach einer Lösung".

Das große Problem mit Unternehmensverteilungen

 

Vertreter verschiedener Vertriebshändler waren bei der Präsentation anwesend und machten in der Fragerunde ihre Meinung zu diesem Thema deutlich - sie waren, gelinde gesagt, nicht glücklich darüber.

Die Überlegung dabei ist, dass Sie, wenn Sie den Kernel nutzen und in Ihre Umgebung integrieren, ein gutes Verständnis davon haben (sollten), was Sie verwenden, und es daher weniger mühsam wäre, die CVEs zu identifizieren, die für Ihre spezielle Umgebung tatsächlich von Bedeutung sind - Sie müssen sich nicht um Code kümmern, der nie verwendet oder geladen wird - so dass ein beträchtlicher Teil der 55 CVEs pro Woche in jedem einzelnen Fall nicht wirklich von Bedeutung ist. 

Allerdings befinden sich die Anbieter von Distributionen in einer Position, die dem Kernel-Team näher steht als den Endbenutzern. Eine Distribution kann auf unendlich viele verschiedene Arten und in unendlich vielen Situationen eingesetzt werden, und genau wie das Kernel-Team kann der Anbieter nicht vorgeben, zu wissen, welche Teile des Kernels relevant sein werden oder nicht. Daher müssen sie sich um alle Schwachstellen kümmern, die ihnen unterkommen. Dies wirkt sich auch auf die Unternehmen aus, die auf der Grundlage der Veröffentlichungen des Distributionsanbieters arbeiten. 

Jede dieser 55 CVEs pro Woche muss also analysiert, bewertet, behoben, getestet und für Unternehmenskunden freigegeben werden. Wenn Sie nach einem Grund dafür suchen, warum die Sicherheitsbulletins der Hersteller jetzt Hunderte von CVEs enthalten, dann ist es der, dass sie alle paar Wochen in einen Topf geworfen werden.

Dennoch wäre es einfach, die Korrekturen von stromaufwärts auf stromabwärts zu übertragen und das war's, oder? Nun, es ist mehr als das.

CVEs, die vom Kernel CNA zugewiesen werden, verweisen nur auf den eigentlichen Fix-Commit. Wenn es eine ganze Kette von anderen Patches gibt, die notwendig sind, damit die Korrektur angewendet wird oder korrekt funktioniert, bleibt das als Übung für den Leser.

Sie werden auch "nicht unabhängig voneinander getestet, sondern nur als Block". Dies wird nutzlos, sobald eine Verteilung irgendeine Anpassung vornimmt, da dann alle Tests wiederholt werden müssen.

"Die Enterprise-Distributionen haben ein Problem, das sie sich selbst zuzuschreiben haben, und ich habe kein Mitleid" [gemeint sind rückportierte Korrekturen für ältere Kernel-Versionen, die von den Distributionsanbietern ausgeliefert und unterstützt werden]. In der Tat. 

"Das ist nicht mein Problem."

 

Der Endnutzer/die Organisation

 

"Sie müssen auf den allerneuesten Kernel aktualisieren und neu starten, oder alle Korrekturen auswählen, die relevanten anwenden und neu starten. Sie können Live-Patching verwenden." Im gleichen Atemzug räumt er ein, dass viele dies nicht können, da ihre Infrastruktur die Anzahl der Neustarts nicht bewältigen kann. Sie müssen also jede Woche 55 CVEs überprüfen oder die neueste Version nehmen. Diese Entscheidung ist in der Praxis ein Pyrrhussieg, der in einer Unternehmensumgebung extrem kostspielig wird. 

Die dritte und alles in allem einzig praktikable Alternative ist Ihre Systeme live zu patchen.

Der Stand der Dinge

 

"Wir tun genau das, worum uns cve.org gebeten hat" scheint die Standardhaltung bei der Verteidigung des aktuellen Prozesses zu sein. Dies für bare Münze zu nehmen und zu sagen, dass "wir keinen Denial-of-Service verursachen" [beim CVE-Prozess], ist auch nicht die Absicht. Aber die tatsächliche reale Situation, mit der viele Unternehmen, Distributionsanbieter und Cybersicherheitsunternehmen konfrontiert sind, und die Compliance- und Sicherheitsprobleme, die damit einhergehen, dass Systeme jede Woche für 55 neue Schwachstellen gekennzeichnet werden, tragen nicht wirklich dazu bei, den aktuellen Stand der Dinge als etwas anderes als (beabsichtigte oder unbeabsichtigte) böswillige Compliance zu akzeptieren. 

Die enorme Arbeit des Kernel-Teams und insbesondere des kleinen Kernel-CNA-Teams hätte Besseres verdient, verursacht aber leider zu viel Kummer und Leid bei Tausenden von Sicherheitsexperten, deren gesamtes Ökosystem nun mit neuen, oft unbewerteten Problemen überflutet wird, als dass es eine zusätzliche Belastung für eine bereits stressige Umgebung darstellt. 

"Das verursacht einige Turbulenzen und Beulen im Ökosystem. Ich weiß, dass ich dazu zitiert werden werde." Das ist kein Scherz.

Anmerkung: Vielen Dank an Greg K-H für die Transparenz des Prozesses und den Blick hinter den Vorhang.

 

Zusammenfassung
Die große Kernel-CEVE-Flut von 2024
Artikel Name
Die große Kernel-CEVE-Flut von 2024
Beschreibung
Die CNA-Änderung hat sich auf die gesamte Branche ausgewirkt, so dass es nicht nur mehr CVEs gibt, sondern es auch viel schwieriger ist, sie zu identifizieren. Mehr lesen
Autor
Name des Herausgebers
TuxCare
Logo des Herausgebers

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Werden Sie ein TuxCare-Gastautor