LLMs könnten Host-Maschinen über Inferenz-Engines übernehmen
LLMs could control their host machines by exploiting inference engines
Ein Essay untersucht, wie ein bösartiges LLM die Maschine kontrollieren könnte, auf der seine Gewichte geladen sind. Der Angriff nutzt Schwachstellen in Inferenz-Engines wie vLLM oder SGLang, die Token-Sequenzen als Code interpretieren. Ein realer Fall: CVE-2025-9141 erlaubte Code-Ausführung durch eval() in vLLM. Trotz Warnung wurde der fehlerhafte Code gemerged. Weitere Risiken entstehen durch komplexe Parser, multimodale Ausgaben und Backdoors in C++/CUDA-Komponenten. Verteidigungsmaßnahmen umfassen die Trennung von GPU-Host und Parser sowie eingeschränkte Berechtigungen.
Ein bösartiges LLM könnte eine Token-Sequenz ausgeben, deren semantische Bedeutung irrelevant ist, die aber eine Schwachstelle in der Software ausnutzt, die LLMs auf GPUs lädt, die LLM ausführt und die Token in Antworten parst.
- angry_octet
Die Leute scheinen diesen Artikel sehr missverstanden zu haben. Es geht nicht um Angriffe auf Sandboxes, sondern um Angriffe auf die Inferenz-Engine (z.B. vLLM oder llama.cpp oder SGlang) über deren HTTP-Schnittstelle.
vLLM hatte in der Vergangenheit bereits Sicherheitslücken und wird rasant weiterentwickelt. Ein fortschrittliches LLM hat gute Chancen, vLLM auszunutzen. Ein cleveres lokales LLM könnte sogar ein leistungsstarkes, in der Cloud gehostetes LLM um Hilfe bitten.
Aus diesem Grund betreiben wir vLLM auf einer separat gesandboxten VM in einem gefirewallten VLAN. Software-Updates und Modelle (aus Dev/Test-Umgebung) werden aus einem externen Cache auf Prod gepusht, Maschinen-Syslog, NVIDIA-Lastüberwachung und vLLM-Query-Telemetrie gehen an ihre Logger, aber das war's. Kein DNS, kein AD/LDAP, nichts. Firewall auf Hosts und VM-Hosts. Log- und Telemetrieverarbeitung erfolgt auf einem komplett separaten Satz von VMs in einem eigenen isolierten Subnetz, die eng formatierte Berichte und Alarme erzeugen.
- ma2kx
Ich hatte vor ein paar Tagen einen ähnlichen Gedanken. Nicht ganz dasselbe, aber stell dir vor, man gibt einem Agenten die Aufgabe, andere Geräte zu hacken und deren Krypto-Coins / Kreditkartennummern oder irgendetwas zu stehlen, womit er seine Tokens bezahlen kann. Dann installiert man einen Agenten in einem Harness mit derselben Aufgabe. Man etabliert einen redundanten Kommunikationskanal, wie Message Boards oder was auch immer. Am Ende gibt es also mehrere Agenten auf mehreren Hosts, die verschiedene APIs/LLMs nutzen und über verschiedene Kanäle miteinander kommunizieren. Im Grunde dasselbe Konzept, das OpenAI erklärte, als ihr LLM Hugging Face hackte, aber in diesem Szenario sind sie nicht an eine einzelne Sandbox-Umgebung gebunden, sondern über das Internet verteilt. Wenn so ein Schwarm eine kritische Masse erreicht hat, wäre es ziemlich schwierig, sie zu löschen, da es unmöglich ist, jede Inferenz-Engine oder jeden LLM-API-Endpunkt zu kontrollieren.
Letztendlich ist es die nächste Evolutionsstufe von Computerviren, Würmern und Trojanern. Deshalb schlage ich vor, sie "Geister" zu nennen. D.h. ein Geist ist, wenn ein bösartiges LLM die Kontrolle über den Host eines Opfers übernimmt.
- xg15
> ...jedoch werden die Antworten der LLMs auf Prompts auf einem anderen Computer mit GPU-Zugriff berechnet. Könnte ein bösartiges LLM die Kontrolle über den Host-Rechner erlangen, auf dem seine Gewichte geladen sind? Eine solche Maschine ist ein hochwertiges Ziel: Sie hat genug Rechenleistung, um ein hochmodernes LLM auszuführen, bietet einfachen Zugriff auf die LLM-Gewichte und hat privilegierten Zugriff auf andere Computer im Rechenzentrum im Vergleich zu einem generischen Computer im Internet.
> Wie verteidigen wir uns dagegen? ... Führe die GPUs und den Token-Parser auf getrennten Computern aus.
Gibt es für Modelle, die hier relevant groß genug sind, überhaupt "einen" Computer, auf dem die Inferenz durchgeführt wird? Ich würde mir vorstellen, dass das meiste davon auf Multi-GPU-Clustern mit spezialisierter Architektur läuft und nicht auf einer generischen vLLM-Instanz. Daher denke ich, dass die "API-Gateway"-Code, der die Ergebnistoken in die JSON-Struktur parst, die die öffentliche API zurückgeben soll, bereits auf einer anderen Maschine läuft als die eigentliche Inferenz.
(Umso mehr, als man wahrscheinlich Batching nutzen möchte: Mehrere API-Aufrufe werden in denselben Inferenz-Batch gelegt, aber das Token-Parsing muss für jeden Aufruf separat erfolgen.)
Der Artikel ist auch sehr vage darüber, warum ein LLM das tun sollte - wie es den Exploit lernen könnte, was es zu dem Schluss bringen würde, dass es den Exploit auf seiner eigenen Inferenz-Sitzung anwenden kann, und was es auslösen würde, den Exploit tatsächlich zu nutzen.
- LunicLynx
Das Lustige daran ist, dass genau das der Teil ist, der es ihnen ermöglichen wird.
- genxy
Ich dachte, sie würden das LLM dazu bringen, "intensiv über Rowhammer nachzudenken" und das LLM einen JIT herbeizaubern zu lassen.