Sicherheitslücke in Gemini Live API: Fehlendes Feld ermöglicht Angreifern die Übernahme von KI-Sprachsitzungen

Das fehlende live_connect_constraints-Feld

Laut Ferdiansyahs Analyse fehlte in der Referenzimplementierung für die Token-Erstellung das live_connect_constraints-Feld . Dieses Feld soll ein bidi_generate_content_setup-Objekt enthalten, das das Token an ein bestimmtes Modell, eine bestimmte Systemanweisung und einen bestimmten Satz von Tools bindet.

Wenn live_connect_constraints leer oder nicht vorhanden ist, werden keine Einschränkungen durchgesetzt. Ein Angreifer, der das Ephemeral Token erbeutet, kann dann einen clientgesteuerten Setup-Frame senden, der ein beliebiges Modell, einen beliebigen System-Prompt und beliebige Tools angibt. Der Server, dem keine token-gebundenen Werte zum Abgleich vorliegen, akzeptiert die Konfiguration des Angreifers.

Wichtiger Hinweis: Die bereitgestellten Quellen enthalten weder Googles offizielle Dokumentation für live_connect_constraints, eine CVE noch eine Google-Sicherheitswarnung, die dieses Verhalten bestätigt. Die Behauptung stammt aus Ferdiansyahs Medium-Artikel und sollte als unbestätigt, aber plausibel betrachtet werden .

Auswirkung: Was ein Angreifer mit einem uneingeschränkten Token anrichten kann

Sollte die Sicherheitslücke real sein, sind die Konsequenzen für jede Anwendung, die die Gemini Live API im Browser-Kontext nutzt, erheblich:

• Sandbox-Codeausführung über Tools – Die Beispiele für die Gemini Live API beinhalten Client-seitige Unterstützung für das Hinzufügen benutzerdefinierter Tools . Ein Angreifer, der eine bösartige Tool-Definition einschleusen kann, könnte potenziell Code innerhalb der Sandbox der Anwendung ausführen.
• Rechenmissbrauch – Eine gekaperte Sitzung verbraucht das Kontingent und die Abrechnungsressourcen der Opferanwendung. Da Ephemeral Tokens für Einmalverbindungen konzipiert sind, könnte ein Angreifer über den Backend-Endpunkt wiederholt neue Tokens anfordern und so die Kosten in die Höhe treiben .
• Prompt-Manipulation – Die Kontrolle über den Setup-Frame bedeutet die Kontrolle über die Systemanweisung. Ein Angreifer könnte die Sitzung umfunktionieren, um vertrauliche Informationen zu extrahieren, schädliche Inhalte zu generieren oder einen vertrauenswürdigen Agenten zu imitieren .
• Wiederholter Sitzungsmissbrauch – Live-API-Sitzungen haben ein Verbindungslimit von etwa 10 Minuten . Ein Angreifer müsste sich erneut verbinden, könnte die Sitzung aber mit demselben uneingeschränkten Token-Ablauf wiederholt kapern.

Entwickler im Google AI Forum berichteten von Problemen mit Ephemeral Tokens, die Systemanweisungen ignorieren und nicht wie erwartet mit eingeschränkten Endpunkten funktionieren – ein Hinweis darauf, dass das gesamte Ökosystem noch reift .

Die Ein-Feld-Korrektur

Die von Ferdiansyah beschriebene Abhilfe ist unkompliziert: Das Feld

live_connect_constraints.bidi_generate_content_setup

1. model – Das genaue zu verwendende Gemini-Modell (z.B. models/gemini-2.5-flash-native-audio-latest).
2. system_instruction – Der gewünschte System-Prompt, strukturiert als parts mit text.
3. tools – Ein leeres Array [] oder nur explizit erlaubte Tools, um Client-seitige Injektionen zu verhindern.

Hier ist der illustrative Python-Code aus Ferdiansyahs Artikel :

Hinweis: Da live_connect_constraints in der offiziellen Google-API-Referenz der Quellen nicht dokumentiert ist, basiert dieses Beispiel auf Ferdiansyahs eigener Beschreibung und sollte vor dem Produktionseinsatz gegen die tatsächliche API getestet werden .

Was noch unbestätigt ist

Die folgenden Kernpunkte bleiben durch die bereitgestellten Quellen unbestätigt:

• Keine offizielle Google-Dokumentation bestätigt die Existenz oder das Schema von live_connect_constraints.
• Keine CVE oder Sicherheitswarnung wurde veröffentlicht.
• Keine unabhängige Reproduktion des Exploits ist in den Quellen enthalten.
• Das genaue Verhalten des BidiGenerateContentConstrained-Endpunkts beim Erhalt eines uneingeschränkten Tokens ist in den bereitgestellten offiziellen Referenzen nicht dokumentiert .

Was Entwickler jetzt tun sollten

Bis Google eine offizielle Warnung veröffentlicht, ist der sicherste Ansatz, die Sicherheitslücke als plausibel zu betrachten und die Korrektur proaktiv anzuwenden:

1. Überprüfen Sie Ihren Code zur Token-Erstellung – Prüfen Sie, ob Ihr Backend das live_connect_constraints-Feld oder ein entsprechendes Äquivalent befüllt.
2. Offenlegen Sie niemals rohe API-Keys – Verwenden Sie für Browser-seitige Verbindungen immer Ephemeral Tokens .
3. Setzen Sie kurze Token-Laufzeiten – Google empfiehlt newSessionExpireTime von etwa 60 Sekunden, um das Zeitfenster für Token-Diebstahl zu begrenzen .
4. Validieren Sie Setup-Frames serverseitig – Auch wenn Clients ihre eigene Konfiguration senden, sollte Ihr Backend das beabsichtigte Modell, den Prompt und die Tools durchsetzen.
5. Überwachen Sie auf Missbrauch – Achten Sie auf ungewöhnliche Sitzungsmuster, insbesondere auf wiederholte Verbindungen mit demselben Token oder unerwartete Tool-Aufrufe.

Die Gemini Live API ist ein mächtiges Werkzeug für den Aufbau von Echtzeit-Sprach- und Videoerlebnissen. Ein einzelnes fehlendes Feld im Token-Erstellungsprozess sollte diese Fähigkeit nicht untergraben – aber Entwickler müssen sicherstellen, dass ihre Implementierungen vollständig sind.

Dieser Artikel wurde anhand von 27 bereitgestellten Quellen faktengeprüft, darunter offizielle Google-Dokumentation, Community-Forum-Diskussionen und der ursprüngliche Artikel des Forschers. Kernbehauptungen des Forschers konnten zum Zeitpunkt der Veröffentlichung nicht unabhängig aus offiziellen Quellen verifiziert werden.