432 Linux-Kernel-CVEs in den letzten 24 Stunden veröffentlicht

 (lore.kernel.org)
1 Punkte von GN⁺ 6 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Laut dem Titel auf Hacker News wurden in den letzten 24 Stunden 432 Linux-Kernel-CVEs veröffentlicht, auf der aktuellen Ankündigungsseite lassen sich jedoch keine einzelnen Inhalte einsehen.
  • Die Ankündigungsseite verwendet das Bot-Schutzverfahren Anubis, um Serverausfälle und eingeschränkten Ressourcenzugriff durch großflächiges Web-Scraping zu verhindern.
  • Mit einem Hashcash-artigen Proof-of-Work bleibt die Belastung für normale Zugriffe gering, während die kumulierten Kosten für Massensammlung steigen.
  • Dieses Verfahren ist eine Übergangslösung, bis Techniken zur Erkennung von Headless-Browsern verfügbar sind.
  • Es werden aktuelle JavaScript-Funktionen benötigt; Plugins wie JShelter, die diese blockieren, müssen für die betreffende Domain deaktiviert werden, um zugreifen zu können.

Aktueller Zustand der CVE-Ankündigungsseite

  • Der Titel auf Hacker News erklärt, dass in den letzten 24 Stunden 432 Linux-Kernel-CVEs veröffentlicht wurden, aber auf der bereitgestellten Seite gibt es weder eine CVE-Liste noch Detailinformationen.
  • Stattdessen wird nur ein Proof-of-Work-Berechnungsbildschirm mit Schwierigkeitsgrad 4 angezeigt.

Funktionsweise und Einschränkungen von Anubis

  • Der Hashcash-artige Proof-of-Work erzeugt pro Zugriff nur eine vernachlässigbare Rechenlast, verursacht bei großflächiger Sammlung jedoch kumulierte Kosten.
  • Künftig soll durch Fingerprinting von Headless-Browsern etwa über die Art des Font-Renderings normalen Nutzern die Proof-of-Work-Seite nicht mehr angezeigt werden.
  • Da aktuelle JavaScript-Funktionen, die Anubis voraussetzt, von JShelter und ähnlichen Tools blockiert werden können, muss das entsprechende Plugin deaktiviert werden, um zugreifen zu können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 시간 전
Meinungen auf Lobste.rs

  • Eine CVE ist nicht die Schwachstelle selbst, sondern ein Identifikator und kann vergeben werden, wenn tatsächlich eine Schwachstelle entdeckt wurde

    • Ich habe die Absicht erst später verstanden; vermutlich war gemeint, dass der Titel 432 Schwachstellen im Linux-Kernel hätte lauten sollen

  • Das Linux-Kernel-Projekt hat mehrfach erklärt, dass es die meisten Bugs als CVE-Kandidaten betrachtet, ausgenommen Performance-Fixes, Hardware-Bugfixes, Dateisystem-Korruption usw.

    http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

    http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

    • Das Kernel-Sicherheitsteam kann nicht wissen, wo und wie der Kernel überall eingesetzt wird; das ist auch eine ungewöhnliche Folge davon, dass der Linux-Kernel zu einer eigenen CVE Numbering Authority (CNA) geworden ist
      Das CVE-System wurde ursprünglich für Produkte geschaffen und passt nicht gut zu einem Betriebssystemkernel, der als Komponente in vielen Produkten verwendet wird. Idealerweise müssten CachyOS, der Hersteller einer Kamera mit eingebettetem Kernel und Red Hat denselben Bug jeweils unabhängig in ihrer eigenen Umgebung daraufhin bewerten, ob er ein CVE-Kandidat ist
      Dann könnten aber jeweils CVEs für 300 Kameramodelle, 300 Fileserver-Router, die sich beim Einstecken von USB ungewöhnlich verhalten, und Dutzende Retro-Game-Emulationskonsolen mit SD-Karten entstehen. Daher ist es trotz der strukturellen Unbeholfenheit für das gesamte Ökosystem besser, das auf Komponentenebene zu verwalten
    • Auch Bugs, die Dateisystem-Korruption verursachen, können als CVE-Kandidaten gelten

  • Ich frage mich, ob unter diesen besonders interessante Schwachstellen sind

  • Viele Einträge beginnen mit der Formulierung „Die folgende Schwachstelle wurde im Linux-Kernel behoben“

  • Ich konnte nicht widerstehen und habe ein LLM gebeten, für jede CVE einen auffälligen Namen zu erfinden
    https://git.infradead.org/~rw/cvenames-2026-07-19.html

  • Beim ersten XFS-bezogenen Eintrag heißt es, das Problem trete nur bei manipulierten Logs auf
    Für eine tatsächliche Ausnutzung müsste man das Dateisystem offenbar offline nehmen und direkt auf das Blockgerät schreiben, auf dem das Log gespeichert ist. Dann bräuchte man wohl Root-Rechte oder physischen Zugriff sowie die Möglichkeit, das System herunterzufahren. Ich frage mich, ob ich XFS-Logs falsch verstehe

    • Für Server, die USB-Laufwerke oder SD-Karten nicht automatisch mounten und sogar physisch überwacht werden, ist das möglicherweise keine Bedrohung, kann aber andere Linux-Umgebungen betreffen
      Zum Beispiel könnte eine SD-Karte, die jemand als mit „Fotos“ befüllt überreicht, ein bösartiges XFS-Dateisystem enthalten, und beim Anschließen zu Hause könnte eine Exploit-Kette ausgelöst werden. Das Mounten eines Dateisystems sollte ebenso eine sichere Aktion sein wie das Öffnen einer Bilddatei
    • Nur weil die Wahrscheinlichkeit gering ist, heißt das nicht, dass es keine potenzielle Schwachstelle ist; auch die Einsatzumgebung ist wichtig
      Es kann kioskartige Geräte geben, die angeschlossene Speichermedien automatisch mounten, und Probleme, die normalerweise unrealistisch wirken, werden durch die Kombination mehrerer Fehler oder einer bestimmten Umgebung zu realistischen Angriffen
    • Ein Angriff durch Anschließen eines USB-Geräts oder einer HDD an einen Server in einer Colocation-Hosting-Einrichtung hätte meiner Einschätzung nach etwa 95 % Erfolgschance
      Selbst wenn man von Kameras erfasst wird, dürfte kaum klar zu erkennen sein, dass man es nicht an einen anderen Server im selben Rack anschließt