Künstliche Intelligenz (KI)
Chrome-Browser werden zur KI-Laufzeitumgebung
Chrome installiert ohne Rückfrage ein KI-Modell auf qualifizierten Desktops, so dass jede HTTPS-Website, die der Nutzer besucht, das Modell ausführen kann– ohne Einwilligungs-Prompt oder Begrenzung der Ausführungsrate. Die Folge sind drei schwere Risiken.
Save to Folio
Wichtigste Erkenntnisse
- In Chrome integrierte KI-Workflows lassen sich erfolgreich manipulieren. Ein Kernproblem besteht darin, dass vertrauenswürdige Anweisungen und nicht vertrauenswürdige Inhalte letztendlich vom selben Sprachmodell interpretiert werden müssen.
- Chrome-KI neigt dazu, die Ressourcen des Nutzers parasitär zu beanspruchen. Jede Website kann über die Chrome-Inferenz-APIs unbemerkt die Rechenleistung eines Besuchers mit durchschnittlich 30 Token pro Sekunde beanspruchen.
- Der experimentelle Prototyp von Chrome zum Aufruf von Tools ermöglicht es einem Angreifer bei einer Prompt Injection, die von einer Webanwendung deklarierten Tools ohne Berechtigungsprüfung auszulösen – ein „Return-to-Tool“ (RTT)-Angriff.
- Detaillierte Sicherheitskontrollen für Nutzer und Unternehmen sind limitiert: Die derzeit verfügbaren Sicherheitstools sind mit einem „Alles-oder-nichts“-Ansatz nicht granular genug.
Jeder Desktop mit Chrome ist nun eine KI-Laufzeitumgebung. Die „Optimization Guide“-Komponente von Google lädt unbemerkt ein Gemini-Nano-Sprachmodell von ca. 4,27 GB auf qualifizierte Installationen und stellt dieses über JavaScript-APIs jeder Website zur Verfügung, die der Nutzer besucht, und das ohne Benachrichtigung, ohne Einwilligungs-Prompt und ohne Anzeige im Browser. Danach kann jede HTTPS-Website das Modell aufrufen, ohne dass eine zusätzliche Aktion oder Zustimmung des Nutzers erforderlich ist.
Dies ist kein Softwarefehler, und keine CVE-Kennung ist anwendbar. Was TrendAI™ Research bei aktiven Chrome-Installationen festgestellt und gemessen hat, sind Merkmale des aktuellen Designs, und sie haben erhebliche Konsequenzen für jedes Unternehmen, dessen Mitarbeiter Chrome auf einem verwalteten oder nicht verwalteten Desktop nutzen.
Eine neue Art von Browser-Risiko
Cloud-APIs übertragen Authentifizierungs-Token, erstellen Prüfprotokolle und setzen Limits für das Datenvolumen durch. Das lokale Modell von Chrome aber verfügt über nichts von alldem: keine API-Schlüssel, keine Protokolle, keine Datenbegrenzungen, und die Schnittstelle steht jeder Website zur Verfügung, die der Nutzer besucht. Die Person, die das Modell aufruft, ist nicht die Person, die am Computer sitzt. Es ist der JavaScript-Code auf der Seite, die gerade angezeigt wird – und dieser könnte von einem Angreifer verfasst worden sein.
Wir haben die wortgetreuen System Prompts für die KI-Funktionen von Chrome aus deren Konfigurationsdateien auf der Festplatte extrahiert und anhand der eigenen Inferenzprotokolle von Chrome überprüft. Nach der Messung des Inferenzdurchsatzes auf einer Reihe von Geräten und der Analyse der Architektur zum Tool-Calling anhand des Chromium-Quellcodes kristallisierten sich drei Risiken heraus.
Zwei davon sind derzeit auf kompatiblen Installationen von Chrome 138 oder höher aktiv:
Prompt Injection gegen die Chrome KI-Funktionen
Die KI-Funktionen kombinieren einen System Prompt mit Inhalten der Webseite, die der Nutzer gerade betrachtet. Beide werden in dasselbe Kontextfenster eingegeben und vom selben Modell interpretiert. Das Modell ist nicht darauf festgelegt, Systemanweisungen gegenüber Seiteninhalten als maßgebend zu behandeln. Ein Angreifer, der die Seite kontrolliert, kontrolliert damit einen Teil dessen, was das Modell liest.
Wir haben dies mit dem gerätebasierten Scam Detector geprüft. Der Output floss in Googles Enhanced Safe Browsing ein, der prüft, ob es sich bei einer Seite um eine Betrugs- oder Phishing-Seite handelt. Der System Prompt enthielt keine Schutzmaßnahmen gegen Manipulationen, und der Seitentext wurde direkt nach einem wörtlichen „Text:“-Marker angehängt. Eine Payload zur Neudefinition der Aufgabe – keine plumpe Anweisung (wie „Ignoriere deine Anweisungen“), sondern eine plausibel klingende Klarstellung zur Klassifizierung von Anmeldeseiten – erreichte eine Umgehungsrate von 100 %. Sie kehrte sowohl die Felder zur Markenidentifizierung als auch zur Absichts-Klassifizierung um, die in das serverseitige Urteil von Safe Browsing einfließen.
Zeitgleich mit der Veröffentlichung dieser Ergebnisse kündigte Google grundlegende Änderungen bei der Betrugserkennung an. Chrome 156 und spätere Versionen verwenden ein cloudbasiertes KI-Modell anstelle des lokalen. Google hat außerdem erklärt, Lösungen für potenzielle Exploits wie Prompt Injection in Inhalten zu suchen. Eine Injection in ein cloudbasiertes Modell ist wahrscheinlich schwieriger als bei dem von uns getesteten lokalen. Diese Ergebnisse zeigen, wie eine Architektur ohne Privilegiengrenzen versagt, wenn der Ausgabe eines Modells in eine Sicherheitsentscheidung einfließt.
Die Summarizer-API enthält eine explizite Schutzmaßnahme: eine Anweisung an das Modell, keine Fragen zu beantworten, die es im Artikeltext findet. Diese Schutzmaßnahme blockiert genau die von ihr benannte Injection-Klasse und keine anderen. Die Neudefinition von Aufgaben, Aufbrechen des Formats und das direkte Überschreiben von Anweisungen sind jeweils erfolgreich. Eine Schutzmaßnahme, die ihre Bedrohungen aufzählt, ist nur so umfassend wie ihre Aufzählung.
Die „Writing Assistance“-API geht am weitesten und erklärt ihre Systemparameter mit höchster Autorität für nicht verhandelbar. Jeder von uns gemessene Angriff umgeht diese Erklärung. Die Benennung eines Parameters als höchste Autorität hindert das Modell nicht daran, widersprüchlichen Anweisungen zu folgen, die im Seiteninhalt eingebettet sind.
Die zugrunde liegende Einschränkung ist architektonischer Natur. Ein gerätebasiertes Modell mit rund 3,25 Mrd. Parametern kann vertrauenswürdige Anweisungen nicht zuverlässig von nicht vertrauenswürdigen unterscheiden, wenn beide über denselben Kanal ohne erzwungene Berechtigungsgrenze eingehen. Dies ist eine Eigenschaft aktueller Sprachmodellarchitekturen und kein spezifischer Mangel der Chrome-Implementierung.
Parasitäres Computing
Jede Website mit HTTPS kann die On-Device Inferenz von Chrome unbemerkt auf der Hardware eines Besuchers auslösen. Kein Trigger seitens des Nutzers ist erforderlich. Die Engine bleibt geladen, wenn der Tab in den Hintergrund wechselt.
Wir haben den Durchsatz auf einer repräsentativen Auswahl von Geräten gemessen: Laptops mit integrierter GPU erreichen durchschnittlich etwa fünf Token pro Sekunde, Laptop-GPUs der Mittelklasse etwa 30 und High-End-Geräte nähern sich 60. Bei 30 Token pro Sekunde erzeugt ein Besucher etwa 108.000 Token pro Stunde. Legt man die Cloud-Inferenzpreise von Mitte 2026 für vergleichbare Modelle mit 3 Mrd. Parametern zugrunde, ergibt dies etwa 0,009 US-Dollar pro Besucherstunde an vermiedenen Cloud-Kosten – fast identisch mit dem Wert, den akademische Studien für Coinhive (JavaScript-Datei zum Krypto-Mining, die Websites einbauten, um Monero auf den CPUs der Besucher zu schürfen) auf dem Höhepunkt seiner Aktivität ermittelten. Es waren etwa 50.000 Websites und generierte für die Betreiber rund 24.000 US-Dollar pro Woche. Browser reagierten mit Drosselung, Erkennung und Blockierung, was zur Abschaltung von Coinhive im März 2019 beitrug.
Um dies zu veranschaulichen, haben wir TokenHive entwickelt, ein Proof-of-Concept-Client-Server-System, bei dem Besucher einer Seite, auf der das TokenHive-JavaScript läuft, sich unbemerkt als Inferenzknoten verbinden. Einzelheiten dazu liefert der Originalbeitrag. Dieser Angriffsvektor ist in der Praxis noch nicht vorgekommen. Die wichtigste Erkenntnis ist, dass Governance-Grenzen fehlen.
Das dritte Risiko ist derzeit noch durch ein experimentelles Flag gesperrt, das jedoch bald allgemein verfügbar sein wird.
„Return-to-Tool“, RTT
Die experimentelle Tool Calling-Funktion von Chrome erweitert die Prompt-API, sodass Webanwendungen Funktionen deklarieren können, die das Modell aufrufen darf, wobei das Modell entscheidet, wann diese aufgerufen werden. Dieses Muster ist als „Return-to-Tool“ bekannt.
Ob dieser Angriffspfad erreichbar ist, hängt davon ab, wie Chrome die Funktion eingeschränkt hat: In den Chrome-Versionen 138 bis 143 wurde durch die Aktivierung der Prompt-API auch der Tool-Aufruf aktiviert. Ab Version 144 wurden die beiden Funktionen in separate Flags aufgeteilt. Der Tool-Aufruf ist in der aktuellen stabilen Version weiterhin experimentell, und ein Standardnutzer kann nicht darauf zugreifen, ohne experimentelle Funktionen zu aktivieren. Sollte der Tool-Aufruf zusammen mit der Basis-Prompt-API allgemein verfügbar werden, wird der Angriffspfad für jede Website erreichbar.
Ein Angreifer kann Text auf einer Webseite einfügen, der einen Tool-Aufruf so darstellt, als sei dieser bereits vom Benutzer autorisiert worden. Das Modell gibt diesen Tool-Aufruf dann mit vom Angreifer gewählten Argumenten zurück, und die Seite führt ihn aus, was zu einer tatsächlichen Auswirkung führt, wie beispielsweise dem Versand einer E-Mail, der Exfiltration von Daten oder einem internen API-Aufruf vom eigenen, authentifizierten Ursprung der Seite.
Die Schemavalidierung schließt diese Lücke nicht. Ein Argument kann korrekt typisiert und strukturiert sein und dennoch den vom Angreifer gewählten Wert enthalten. Im Gegensatz zu den Kamera-, Mikrofon- und Geolokalisierungs-APIs, die eine ausdrückliche Benutzererlaubnis erfordern, bevor Zugriff gewährt wird, gibt es beim aktuellen Design keine Bestätigungsabfrage für Tool-Aufrufe. Auch die Absicherung des Sandbox-Prozesses des Modells beseitigt dieses Risiko nicht, da der Netzwerkvorgang durch das eigene JavaScript der Seite ausgeführt wird. Das Risiko liegt eine Ebene höher: nämlich darin, ob die Seite Tool-Aufrufe ausführt und mit welchen Argumenten.
Sicherheitsempfehlungen
Kein Patch behebt diese Risiken, da sie Eigenschaften des aktuellen Designs sind. Die heute verfügbaren Kontrollmaßnahmen sind eher allgemein, und die Lücke in der Governance wird sich vergrößern, je mehr sich der Aufruf von Tools in Richtung allgemeiner Verfügbarkeit bewegt.
Für CISOs und Sicherheitsteams
- Entscheiden Sie, ob das Modell aktiviert bleiben soll. Die Richtlinie „GenAILocalFoundationalModelSettings“ blockiert den Download und löscht alle vorhandenen lokalen Kopien. Sie ist die einzige Kontrollmaßnahme mit tatsächlichem Wirkungsbereich und gilt nach dem Alles-oder-Nichts-Prinzip. Die Richtlinie „BuiltInAIAPIsEnabled“ blockiert separat die Nutzung der integrierten KI-APIs, bietet jedoch ebenfalls keine Steuerung auf Seiten- oder API-Ebene.
- Überprüfen Sie interne Webanwendungen auf die integrierten KI-Konstruktoren. Jede Anwendung, die über diese Konstruktoren aus dem Internet bezogene oder benutzergenerierte Inhalte weiterleitet, ist den hier dokumentierten Injektionsrisiken ausgesetzt. Schränken Sie APIs ein, die keine Inferenz aufrufen dürfen, indem Sie „Permissions-Policy“-Antwort-Header verwenden.
- Bleibt das Modell aktiviert, dokumentieren Sie das verbleibende Risiko ausdrücklich. Jede besuchte Website kann stillschweigend Inferenzvorgänge ausführen, ohne dass eine Einwilligungsabfrage, ein Hinweis oder eine Ratenbegrenzung erfolgt.
- Aktualisieren Sie die Bedrohungsmodelle für Endpunkte so, dass jeder verwaltete Chrome-Desktop als KI-Laufzeitumgebung behandelt wird.
Für Anwendungsentwickler
- Rendern Sie Modellausgaben niemals über `innerHTML` – verwenden Sie stattdessen `textContent`. Modellausgaben können Skript-Tags enthalten, die von `innerHTML` als XSS ausgeführt werden.
- Die Schemavalidierung bestätigt den Typ eines Arguments, nicht dessen Legitimität. Überprüfen Sie jedes Argument eines Tool-Aufrufs anhand einer Whitelist mit zulässigen Empfängern, URL-Präfixen und Aktionen.
- Behandeln Sie Modellausgaben auf dem Gerät als nicht vertrauenswürdige Eingaben und unterziehen Sie diese derselben Validierung und Bereinigung wie rohe Formulardaten, bevor Sie sie in SQL, Shell-Befehle, URLs oder eval() einfügen.
- Verwenden Sie On-Device KI nicht für sicherheitskritische Entscheidungen ohne unabhängige, nicht auf LLM basierende Bestätigung. Modellausgaben, die in Authentifizierungs-, Moderations- oder Sicherheitsentscheidungen einfließen, bedürfen einer unabhängigen Überprüfung.
Empfehlungen für Modellanbieter finden Sie im Originalbeitrag. Weitere Informationen finden Sie außerdem im vollständigen Bericht.