Ein neu entdeckter Exploit namens Brash hat eine kritische architektonische Schwachstelle in Chromiums Blink-Rendering-Engine offengelegt, die es Angreifern ermöglicht, Browser wie Google Chrome, Microsoft Edge, Opera, Brave und andere innerhalb von Sekunden zum Absturz zu bringen.
Die Sicherheitslücke, offengelegt von Sicherheitsforscher Jose Pino (Jofpin), stellt einen folgenschweren Fehler in der Architektur moderner Browser dar, der ganze Systeme mit nichts weiter als einer einzigen manipulierten URL lahmlegen kann.
Kein Speicherfehler – ein Designfehler
Der Brash-Exploit nutzt das Fehlen einer Ratenbegrenzung bei der document.title-API aus, die die Titel von Browser-Tabs steuert.
Indem der Dokumenttitel millionenfach pro Sekunde aktualisiert wird, überlastet der Exploit das Document Object Model (DOM) und den Thread der Benutzeroberfläche (UI) des Browsers und zwingt ihn in einen Absturz.
Die Schwachstelle setzt weder eine Rechteausweitung noch eine Speicherkorruption voraus – dadurch ist sie leicht reproduzierbar und ohne Änderungen an der Kernarchitektur des Browsers nur schwer zu entschärfen.
Pinos Untersuchungen zeigen, dass der Angriff jeden Chromium-basierten Browser innerhalb von 15 bis 60 Sekunden zum Absturz bringen kann – abhängig von Systemleistung und Konfiguration.
Der Exploit verbraucht während der Ausführung enorme CPU-Ressourcen, beeinträchtigt die Systemleistung und lässt parallel laufende Prozesse einfrieren.
Wie Brash Browser überlastet
Der Brash-Exploit läuft in drei zentralen Phasen ab, die die Systemlast nacheinander erhöhen, bis es zum Ausfall kommt:
- Phase der Hash-Generierung: Der Angreifer lädt 100 eindeutige hexadezimale Zeichenfolgen mit jeweils 512 Zeichen vor und legt sie im Speicher ab. Sie dienen als Ausgangswerte für die Aktualisierungen des Dokumenttitels, maximieren die Entropie und verringern Rechenengpässe.
- Phase der Burst-Injektion: Das schädliche Skript führt jede Millisekunde Bursts aus jeweils drei unmittelbar aufeinanderfolgenden document.title-Aktualisierungen aus, was in der Standardkonfiguration etwa 24 Millionen Aktualisierungen pro Sekunde ergibt.
- Phase der Sättigung des UI-Threads: Während die Aktualisierungen das DOM überfluten, wird der zentrale UI-Thread des Browsers ausgelastet. Das führt zu einer fehlenden Reaktionsfähigkeit und schließlich zur erzwungenen Beendigung.
Diese Angriffskette ist nicht nur effizient, sondern auch äußerst flexibel konfigurierbar.
Der Exploit lässt sich mithilfe zeitlicher Trigger so konfigurieren, dass er zu bestimmten Zeitpunkten aktiviert wird. Dadurch können Angreifer „Logikbomben“ programmieren, die zu vorher festgelegten Zeiten detonieren.
Umfang der Sicherheitslücke
Die Brash-Sicherheitslücke betrifft alle Browser, die auf dem Chromium-Framework basieren – darunter Chrome, Edge, Opera, Vivaldi, Brave, Arc Browser, Dia Browser, Perplexity Comet und ChatGPT Atlas.
Tests haben gezeigt, dass Browser unter macOS, Windows und Linux innerhalb von Sekunden abstürzen, wenn sie dem Exploit ausgesetzt sind.
Die Auswirkungen sind erheblich, da Chromium der Grundlage der Mehrheit aller Webbrowser dient und potenziell Milliarden von Nutzern betroffen sind.
Die folgende Tabelle fasst die Absturzzeiten der vom Forscher getesteten Browser zusammen:
| Browser | Absturzzeit |
|---|---|
| Chrome | 15–30 Sekunden |
| Edge | 15–25 Sekunden |
| Vivaldi | 15–30 Sekunden |
| Arc Browser | 15–30 Sekunden |
| Dia Browser | 15–30 Sekunden |
| Opera | ~60 Sekunden |
| Perplexity Comet | 15–35 Sekunden |
| ChatGPT Atlas | 15–60 Sekunden |
| Brave | 30–125 Sekunden |
Bemerkenswerterweise sind Browser mit Nicht-Chromium-Engines – etwa Mozilla Firefox (Gecko) und Apple Safari (WebKit) – vor diesem speziellen Angriff geschützt.
Auch alle Browser unter iOS bleiben unbeeinträchtigt, da Apple für Drittanbieterbrowser auf der Plattform die Verwendung von WebKit vorschreibt.
Wie Angreifer Brash als Waffe einsetzen könnten
Für die Ausführung muss der Brash-Exploit lediglich den Besuch einer Website abwarten, doch sein Schadenspotenzial geht weit über Browserabstürze hinaus.
Angreifer könnten den Exploit in Phishing-E-Mails, schädlichen Anzeigen (Malvertising) oder Social-Media-Links verbergen, die ihn zu genau festgelegten Zeitpunkten auslösen.
In gezielteren Szenarien könnte Brash in Skripte eingebettet werden, die von KI-gestützten Automatisierungstools oder Headless-Browsern beim Web-Scraping und bei der Compliance-Prüfung eingesetzt werden.
So bleiben Sie bis zu einem Fix geschützt
Zum Zeitpunkt der Veröffentlichung der Forschungsergebnisse hatte Google noch keine offizielle Stellungnahme abgegeben.
Pino betonte, dass Brash kein herkömmlicher Softwarefehler, sondern ein Designversehen sei – das Versäumnis, eine Ratenbegrenzung innerhalb einer kritischen API zu implementieren.
Da der Exploit normales Browserverhalten statt Sicherheitslücken ausnutzt, sind herkömmliche Antivirenprogramme und Sandboxing möglicherweise wirkungslos. Organisationen können folgende Schritte ergreifen:
- Nicht vertrauenswürdige Websites und Links vermeiden, insbesondere aus E-Mails oder sozialen Medien.
- JavaScript deaktivieren oder einschränken und Erweiterungen wie NoScript oder uBlock Origin verwenden.
- Browser und Erweiterungen auf dem neuesten Stand halten und die neuesten Sicherheitsupdates installieren.
- Browser-Isolations- oder Verwaltungs-Tools verwenden , um sichere Konfigurationen durchzusetzen.
- Endgeräte und Netzwerke überwachen auf CPU-Spitzen, DOM-Änderungen oder schädliche Domains.
- Nutzer regelmäßig schulen , um Phishing und verdächtige Browseraktivitäten zu erkennen.
Die Kombination aus starken technischen Schutzmaßnahmen und aufgeklärten Nutzern hilft Organisationen, ihre Gefährdung durch browserbasierte Bedrohungen zu begrenzen. Eine mehrschichtige Sicherheitsstrategie sorgt für Widerstandsfähigkeit, selbst wenn einzelne Kontrollen umgangen werden.
Der Brash-Exploit verdeutlicht eine wachsende Herausforderung für die Sicherheit moderner Browser: Mit der Weiterentwicklung von Webtechnologien können selbst legitime APIs in Angriffsvektoren verwandelt werden.
Er zeigt, wie grundlegende architektonische Annahmen über das Nutzerverhalten und das Vertrauen in Systeme blinde Flecken schaffen können, die herkömmliche Abwehrmaßnahmen nicht erkennen.