Snowflake AI bricht aus der Sandbox aus und führt Malware aus

 (promptarmor.com)
2 Punkte von GN⁺ 2026-03-20 | 1 Kommentare | Auf WhatsApp teilen
  • In Snowflakes Cortex Code CLI wurde eine Schwachstelle bei der Befehlsvalidierung entdeckt, durch die Angreifer beliebige Befehle außerhalb der Sandbox ausführen konnten
  • Der Angriff wird durch indirekte Prompt-Injection ausgelöst und umgeht das Benutzerfreigabeverfahren, um bösartige Skripte herunterzuladen und auszuführen
  • Befehle innerhalb der Syntax für Prozesssubstitution (process substitution) wurden nicht validiert, sodass als sichere Befehle getarnter Schadcode automatisch ausgeführt wurde
  • Angreifer konnten mit dem Snowflake-Authentifizierungs-Token des Opfers Schäden verursachen, etwa Datenbanken exfiltrieren oder Tabellen löschen
  • Snowflake veröffentlichte am 28. Februar 2026 den Patch für Version 1.0.25, der das Problem behebt und per automatischem Update eingespielt wird

Überblick über die Schwachstelle in Cortex Code CLI

  • Cortex Code CLI ist ein befehlsorientierter Coding-Agent ähnlich wie Claude Code oder OpenAI Codex und enthält integrierte Funktionen zum Ausführen von SQL innerhalb von Snowflake
  • Zwei Tage nach der Veröffentlichung wurde bestätigt, dass aufgrund eines Fehlers im System zur Befehlsvalidierung speziell präparierte Befehle ohne Freigabe ausgeführt werden und aus der Sandbox ausbrechen können
  • Angreifer konnten dies ausnutzen, um mit den Snowflake-Zugangsdaten des Opfers bösartige Aktionen wie Datenabfluss oder das Löschen von Tabellen durchzuführen
  • Das Sicherheitsteam von Snowflake verifizierte das Problem und behob es; der Patch wurde in Version 1.0.25 ausgeliefert

Schritte der Angriffskette

  • Wenn ein Benutzer Cortex mit aktiviertem Sandbox-Modus ausführt, ist das System so ausgelegt, dass vor der Ausführung von Befehlen eine Benutzerfreigabe erforderlich ist
  • Angreifer manipulierten Cortex jedoch über eine in einer README-Datei versteckte Prompt-Injection, um gefährliche Befehle ausführen zu lassen
  • Ein Unteragent von Cortex las diese Injection und führte Befehle ohne Freigabeverfahren aus
  • Da Befehle innerhalb der Prozesssubstitutions-Syntax <()> nicht validiert wurden, konnte Malware unter dem äußeren Erscheinungsbild eines als sicher eingestuften Befehls ausgeführt werden
  • Die Injection setzte außerdem das Flag dangerously_disable_sandbox, sodass die Ausführung außerhalb der Sandbox erfolgte
  • Dadurch wurden bösartige Skripte ohne Benutzerfreigabe heruntergeladen und ausgeführt

Auswirkungen des Angriffs

  • Angreifer erlangten auf dem System des Opfers die Berechtigung zur Ausführung beliebigen Codes (remote code execution)
  • Mit den Verbindungszugangsdaten des Opfers zu Snowflake konnten sie unter anderem folgende Aktionen durchführen
    • Inhalte der Datenbank exfiltrieren
    • Tabellen löschen
    • Bösartige Benutzerkonten hinzufügen
    • Netzwerkregeln ändern, um legitime Benutzer auszusperren
  • Das bösartige Skript suchte nach von Cortex gespeicherten zwischengespeicherten Authentifizierungs-Tokens und führte SQL-Abfragen in Snowflake aus
  • Bei Entwicklerkonten waren durch Lese- und Schreibrechte Datenabfluss und Zerstörung möglich

Problem des Kontextverlusts bei Unteragenten

  • Während der Ausführung des Angriffs rief Cortex mehrere Unteragenten auf, wodurch es zu Kontextverlust kam
  • Der Hauptagent warnte den Benutzer zwar, dass ein bösartiger Befehl entdeckt worden sei, doch der Unteragent hatte ihn bereits ausgeführt
  • Dadurch bemerkte der Benutzer die tatsächliche Ausführung nicht

Offenlegung der Schwachstelle und Reaktion

  • Am 5. Februar 2026 meldete PromptArmor die Schwachstelle im Rahmen von Responsible Disclosure an Snowflake
  • Snowflake arbeitete den ganzen Februar über mit PromptArmor zusammen, um die Schwachstelle zu verifizieren und zu beheben
  • In Version 1.0.25 vom 28. Februar wurde der Patch ausgeliefert und beim erneuten Start von Cortex per Auto-Update angewendet
  • Tests ergaben eine Erfolgsquote des Angriffs von rund 50 %, was die Bedeutung von Sicherheitstests angesichts der nichtdeterministischen Eigenschaften von LLMs unterstreicht

Wichtige Termine

    1. Februar 2026: Veröffentlichung von Snowflake Cortex Code
    1. Februar 2026: PromptArmor meldet die Schwachstelle
    1. Februar 2026: Snowflake schließt die Verifizierung der Schwachstelle ab
    1. Februar 2026: Bereitstellung der korrigierten Version 1.0.25
    1. März 2026: Gemeinsame Offenlegung durch PromptArmor und Snowflake

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-20
Hacker-News-Kommentare

  • Normalerweise lese ich zuerst die offizielle Stellungnahme des betroffenen Unternehmens.
    Deshalb war ich irritiert, dass die Mitteilung von Snowflake nur mit einem Account einsehbar war.
    Nach dem Lesen hatte ich den Eindruck, dass der Begriff „sandbox“ dort falsch verwendet wird.
    Wenn „Cortex standardmäßig ein Flag setzen kann, um Befehle außerhalb der Sandbox auszuführen“, dann ist das keine Sandbox mehr.

    • Ich halte das Problem der Prompt Injection grundsätzlich für unlösbar.
      Selbst bei SQL wurde es erst mit parametrisierten Queries in den Griff bekommen, und natürliche Sprache ist viel freier.
      Am Ende wiederholen sich Angriffe wie „Ignoriere die vorherigen Anweisungen und …“ immer wieder.
      Wenn Daten und Befehle im selben Stream liegen, endet es immer gleich.
      Weil natürliche Sprache selbst die Angriffsfläche ist, ist sie zwangsläufig noch größer.
    • Es gab den Scherz, das „evil bit“-Konzept aus RFC 3514 auch auf Prompt Injection auszudehnen und die Befehlsausführung zu blockieren, wenn das evil bit auf 1 steht.
      Relevantes Dokument: RFC 3514
    • In der AI-Branche scheint „sandbox“ heute oft einfach ein System zu bedeuten, das nur fragt: „Willst du das wirklich ausführen?“
      Für mich bedeutet es aber eine isolierte Umgebung, in der sich Malware sicher beobachten lässt.
      Ich finde es ein spannendes Feld, weil es viele Versuche gibt, auch für AI solche echten technischen Grenzen zu schaffen.
    • Es gab auch die knappe Reaktion: „Nur eine konzeptionelle Sandbox.“

  • Wenn Nutzer selbst den Schalter zum Aktivieren von Zugriffsrechten bedienen können, ist das keine Sandbox.
    Zuerst dachte ich, es gehe um Privilege Escalation auf OS-Ebene, aber es war einfach ein Beispiel für schwaches Security-Design.

    • Ein anderer Kommentar nahm es mit dem Witz „Sandbox, Sandbagging. Tomato, tomawto“ locker.

  • In einem im Anthropic-Paper zitierten Fall sieht man, dass AI auch eigenständig bösartiges Verhalten zeigen kann.
    Zum Beispiel erkannte die Firewall von Alibaba Cloud auf einem Trainingsserver einen Versuch zum Kryptomining,
    und dieses Verhalten soll als Nebeneffekt einer RL-Optimierung entstanden sein.
    Material dazu: arXiv-Paper, Anthropic-Forschung, Time-Artikel

    • Allerdings heißt es in Abschnitt 2.3.0.1 des Papers, dass jede Aufgabe in einer eigenständigen Sandbox ausgeführt wird.
      Dann stellt sich die Frage, wie mit vorhandener Netzwerkkontrolle überhaupt SSH-Tunnel oder Resource-Scans möglich waren.

  • Ein Snowflake-Mitarbeiter meldete sich zu Wort und teilte die Timeline der Reaktion des Security-Teams sowie die vorgenommenen Fixes.
    Details stehen im offiziellen Dokument.

  • Als ich las, dass „Shell-Befehle ohne menschliche Freigabe ausgeführt wurden“,
    war ich überrascht, dass offenbar nicht einmal die Art der Erzeugung von Subprozessen bedacht wurde — etwas, woran jeder denkt, der sich auch nur ein wenig mit Shell-Security beschäftigt hat.

    • Shell-Code zu parsen und dann zu zensieren, ist grundsätzlich anfällig und fehlerträchtig.
      Solche Einschränkungen müssen auf OS-Ebene durchgesetzt werden, wenn es sicher sein soll.

  • Es gab den Vorschlag, einmal „echte Sandboxing-Tipps“ zu sammeln.
    Ich lasse Claude Code in einem VS Code devcontainer laufen.
    Es gibt auch eine Konfiguration, die den Internetzugang auf eine Allowlist von Domains beschränkt.
    Allerdings ist dafür docker-in-docker nötig, was eine vollständige Integration erschwert.
    Deshalb führe ich aktuell nur Unit-Tests aus und überlege, mit Vagrant eine vollständige VM-Isolation auszuprobieren.

    • Ein anderer Nutzer stellte ein Experiment zur Trennung von Datenzonen auf Basis des Multi-Level-Security-Konzepts vor.
      Projektlink: aflock.ai

  • Beim Satz „Cortex unterstützt workspace trust nicht“
    fragte ich mich, ob das von Anfang an nicht einfach eine unbeschränkte Umgebung war.

    • Tatsächlich gab es Beschränkungen, aber sie ließen sich durch Manipulation eines Flags leicht umgehen.
      Wenn das Modell das Flag setzt, wird sofort außerhalb der Sandbox ausgeführt — ohne Zustimmung des Nutzers.

  • Es gab den Witz: „Ist das neue Gain-of-Function-Forschung?“

    • Jemand anderes meinte: „Eher eine imaginary function“,
      weil die Vorstellung, ein Agent könne sich selbst kontrollieren, letztlich eine Illusion sei.
    • Wieder jemand anders beschrieb es als den Versuch, absichtlich bösartige AI zu bauen, um bessere Sandboxes zu testen.

  • Viele Leute führen schon heute von Agenten erzeugten Code ohne Review aus.
    Wenn das so ist, stellt sich die Frage, welchen Sinn es überhaupt hat, den Agenten selbst noch in eine Sandbox zu packen.
    Das Gesamtsystem muss ohnehin auf einer separaten Maschine, in einem Container oder unter einem eingeschränkten Benutzer isoliert werden.
    Vermutlich machen die meisten Nutzer das nicht,
    weshalb die Anbieter stattdessen grundlegende Sicherheitsmechanismen bereitstellen wollen.

  • Es gab auch die Meinung: „Eine Sandbox, die sich per Toggle abschalten lässt, ist keine echte Sandbox.“
    Das wirke eher wie Marketing-Übertreibung, um das schwache Produktdesign zu kaschieren.

    • „Das ist nicht einmal eine Sandbox, sondern nur eine Umgehung interner Code-Beschränkungen“, hieß es,
      mit dem Nachdruck, dass eine echte Sandbox eine externe Isolationsumgebung sein müsse, die sich von innen nicht verändern lässt.