Update für CSS-Zero-Day-Sicherheitslücke in Chrome für Windows und Mac veröffentlicht
(chromereleases.googleblog.com)- Google hat ein Stable-Channel-Update für die Desktop-Version von Chrome veröffentlicht, das eine CSS-bezogene Zero-Day-Sicherheitslücke enthält, die als CVE-2026-2441 identifiziert wird
- Google hat bestätigt, dass diese Schwachstelle bereits aktiv ausgenutzt wird (in the wild); Nutzer sollten sofort auf die neueste Version aktualisieren, um das Sicherheitsrisiko zu minimieren
- Das Update wird schrittweise für Chrome unter Windows, macOS und Linux ausgerollt
Überblick über das Chrome-Update für den Stable Channel
- Google hat ein Update für den Stable Channel von Chrome für den Desktop angekündigt
- Windows/macOS: 145.0.7632.75/76, Linux: 144.0.7559.75
- Das Update wird für die Plattformen Windows, macOS und Linux verteilt
- Die Auslieferung erfolgt schrittweise über automatische Updates
Sicherheitslücke CVE-2026-2441
- Diese Version enthält die als CVE-2026-2441 bezeichnete Sicherheitslücke
- Es handelt sich um eine Zero-Day-Schwachstelle bei der CSS-Verarbeitung
- Google weist ausdrücklich darauf hin, dass diese Schwachstelle bereits aktiv angegriffen wird
Empfohlene Maßnahmen für Nutzer
- Google empfiehlt allen Nutzern, Chrome sofort auf die neueste Version zu aktualisieren
- Falls das automatische Update noch nicht abgeschlossen ist, kann auch manuell aktualisiert werden
- Mit der neuesten Version lässt sich Schutz vor dieser Schwachstelle herstellen
Verteilung und Support
- Das Update wird schrittweise über den Stable Channel ausgerollt
- Bei manchen Nutzern kann es etwas dauern, bis das Update verfügbar ist
- Das Chrome-Team arbeitet weiterhin an zusätzlichen Sicherheitsverbesserungen und höherer Stabilität
2 Kommentare
Ich habe aktualisiert, aber auf dem Mac ist die Version offenbar schon auf 145.0.7632.110 gestiegen.
Es handelt sich um eine Schwachstelle, bei der während der Schriftverarbeitung innerhalb von CSS ein Use-After-Free auftritt, weil eine ungültig gewordene Adresse weiterverwendet wird, wodurch sogar eine vollständige Systemübernahme möglich wird. Daher reicht es schon aus, einfach nur eine Website zu öffnen. Es soll sogar bereits Stellen gegeben haben, die diese Schwachstelle ausgenutzt haben.
Hacker-News-Kommentare
In Google Chromium wurde eine Use-after-free-Schwachstelle in CSS entdeckt.
Dabei handelt es sich um ein Problem, bei dem ein entfernter Angreifer über eine bösartige HTML-Seite Heap-Korruption auslösen kann; betroffen sein könnten nicht nur Chrome, sondern generell Chromium-basierte Browser wie Edge oder Opera.
Das wirkt ziemlich gravierend, und ich frage mich, wie hoch die Bug-Bounty-Prämie für den Forscher war.
Wenn man den Aufwand bedenkt, eine schwerwiegende Schwachstelle zu finden und einen reproduzierbaren Exploit zu bauen, wirkt die Belohnung übertrieben niedrig.
Die meisten pinnen nämlich ihre Chrome-Version.
Dass sie „in the wild gefunden“ wurde, könnte aber bedeuten, dass bereits eine Angriffskette einschließlich Sandbox Escape existiert.
Dass man solche Bugs in Systemsprachen des 21. Jahrhunderts nicht eliminieren kann, ist beschämend.
In den dunklen Ecken der Chromium/Blink-Codebasis dürften sich wahrscheinlich noch mehr solcher Bugs verstecken.
Bei einem so zentralen Projekt sollte es ein dediziertes Team geben, das den gesamten Code fortlaufend überprüft.
Das wäre aus meiner Sicht eine deutlich wertvollere Investition als Features wie die Anbindung an smarte Kühlschränke.
Mit einem ausreichend starken Fuzzer gibt es aus meiner Sicht kaum Bereiche, die unerreichbar bleiben.
Die Formulierung „Use after free in CSS“ ist irgendwie lustig.
Ich bin mir nicht ganz sicher, welche konkreten Auswirkungen diese Schwachstelle in der Praxis hat.
Ohne Sandbox Escape oder XSS wirkt sie fast harmlos, aber laut dem PoC-Code
sind Arbitrary Code Execution im Renderer-Prozess, Informationsabfluss, Diebstahl von Cookies und Sessions, DOM-Manipulation, Keylogging und weitere Angriffe möglich.
Zuerst verschafft man sich mit einem Renderer-Bug Arbitrary Code Execution innerhalb der Sandbox, danach erlangt man mit einem Sandbox Escape vollständige Systemrechte.
Diese Schwachstelle gehört zum ersten Schritt, und wenn sie bereits in realen Angriffen eingesetzt wurde, ist es sehr wahrscheinlich, dass auch der zweite Schritt existiert.
Es überrascht mich, dass immer noch solche Speicherfehler auftauchen.
Ich hätte gedacht, es gäbe Tools, die wie speichersichere Sprachen verifizierte Binärdateien erzeugen.
Auch CSS ist inzwischen durch Variablen, Scopes und Präprozessor-Funktionen komplexer geworden, und vielleicht bräuchte man neben „no-script“ auch so etwas wie eine „no-style“-Erweiterung.
Ich frage mich, ob dieser Bericht auf einen simplen Fehler oder auf eine mehrstufige Angriffskette hindeutet.
Das Problem ist die Testabdeckung. Die Codebasis ist so riesig, dass vollständige Coverage schwer zu erreichen ist, und genau in diesen Lücken entstehen solche Schwachstellen.
CSS ist ein Kernbestandteil des Webs; würde man es entfernen, würden die meisten Websites kaputtgehen.
Stattdessen könnte Isolation ein Ansatz sein.
Wenn man Browser-Sitzungen von einem Remote-Server streamt, trifft ein Zero-Day im Fall der Fälle nur die Remote-Instanz statt des lokalen Systems.
Das ist nicht perfekt, aber eine Defense-in-Depth-Strategie zur Verringerung der Angriffsfläche.
In der Liste der vom Chromium-Team verwendeten Sicherheitstools wurden AddressSanitizer, MemorySanitizer und libFuzzer erwähnt; interessant ist, dass OSS-Fuzz fehlt.
Ich würde den PoC-Code gern sehen, nachdem der Patch ausgerollt wurde.
Es kam der Witz auf, man müsse Chromium in Rust neu schreiben.
Beim Nachschlagen der CVE sieht man, dass es eine Issue-Seite gibt,
die jedoch mit „Access is denied“ angezeigt wird.
Sie scheint privat zu sein und nur nach Anmeldung zugänglich.