Sicherheitsrisiken bei RAG: Die Kehrseite innovativer KI-Technologien

Wussten Sie, dass Deutschland auf Rang 3 der Länder mit den meisten exponierten RAG-Systemen steht, gleich hinter den USA und China?

Seit der Einführung von ChatGPT 2022 wollen immer mehr Unternehmen KI-Technologien nutzen – oft mit spezifischen Anforderungen, die über Standardlösungen hinausgehen. Retrieval Augmented Generation (RAG) ist dabei die bevorzugte Technologie, um innovative Anwendungen auf Basis privater Daten zu entwickeln. Doch Sicherheitsrisiken wie ungeschützte Vektorspeicher, fehlerhafte Datenvalidierung und Denial-of-Service-Angriffe stellen eine ernsthafte Gefahr dar, insbesondere angesichts des schnellen Entwicklungszyklus von RAG-Systemen.

RAG benötigt einige Zutaten, um zu funktionieren: Eine Datenbank mit Textbausteinen und eine Möglichkeit, diese abzurufen sind erforderlich. Üblicherweise wird dafür ein Vektorspeicher eingesetzt, der den Text und eine Reihe von Zahlen speichert, die dabei helfen, die relevantesten Textbausteine zu finden. Mit diesen und einem entsprechenden Prompt lassen sich Fragen beantworten oder neue Texte verfassen, die auf privaten Datenquellen basieren und für die jeweiligen Bedürfnisse relevant sind. Tatsächlich ist RAG so effektiv, dass meist nicht die leistungsstärksten LLM benötigt werden. Um Kosten zu sparen und die Reaktionszeit zu verbessern, lassen sich die vorhandenen eigenen Server verwenden, um diese kleineren und leichteren LLM-Modelle zu hosten.

Der Vektorspeicher gleicht einem sehr hilfreichen Bibliothekar, der nicht nur relevante Bücher findet, sondern auch die entsprechenden Passagen hervorhebt. Das LLM ist dann der Forscher, der diese Textstellen nimmt und sie dafür nutzt, um ein Whitepaper zu schreiben oder die Frage zu beantworten. Zusammen bilden sie eine RAG-Anwendung.

Vektorspeicher, LLM-Hosting, Schwachstellen

Vektorspeicher sind nicht ganz neu, erleben aber seit zwei Jahren eine Renaissance. Es gibt viele gehostete Lösungen wie Pinecone, aber auch selbst gehostete Lösungen wie ChromaDB oder Weaviate (https://weaviate.io). Sie unterstützen einen Entwickler dabei, Textbausteine zu finden, die dem eingegebenen Text ähneln, wie z. B. eine Frage, die beantwortet werden muss.

Das Hosten eines eigenen LLM erfordert zwar eine nicht unerhebliche Menge an Arbeitsspeicher und eine gute GPU, aber das ist nichts, was ein Cloud-Anbieter nicht bereitstellen könnte. Für diejenigen, die einen guten Laptop oder PC haben, ist LMStudio eine beliebte Option. Für den Einsatz in Unternehmen sind llama.cpp und Ollama oft die erste Wahl. Alle diese Programme haben eine rasante Entwicklung durchgemacht. Daher sollte es nicht überraschen, dass es noch einige Fehler in RAG-Komponenten zu beheben gilt.

Einige dieser Bugs sind typische Datenvalidierungs-Fehler, wie CVE-2024-37032 und CVE-2024-39720. Andere führen zu Denial-of-Service, etwa CVE-2024-39720 und CVE-2024-39721, oder sie leaken das Vorhandensein von Dateien, wie CVE-2024-39719 und CVE-2024-39722. Die Liste lässt sich erweitern.

Weniger bekannt ist llama.cpp, doch dort fand man in diesem Jahr CVE-2024-42479. CVE-2024-34359 betrifft die von llama.cpp genutzte Python-Bibliothek. Vielleicht liegt der Mangel an Informationen über llama.cpp auch an dessen ungewöhnlichem Release-Zyklus. Seit seiner Einführung im März 2023 gab es über 2.500 Releases, also etwa vier pro Tag. Bei einem sich ständig ändernden Ziel wie diesem ist es schwierig, dessen Schwachstellen zu verfolgen.

Im Gegensatz dazu hat Ollama einen gemächlicheren Release-Zyklus von nur 96 Releases seit Juli 2023, also etwa einmal pro Woche. Als Vergleich, Linux hat alle paar Monate ein neues Release und Windows erlebt jedes Quartal neue „Momente“.

ChromaDB gibt es seit Oktober 2022 und fast zweiwöchentlich erscheint ein neues Release. Interessanterweise sind keine CVEs für diesen Vektorspeicher bekannt. Weaviate, ein weiterer Vektorspeicher, weist ebenfalls Schwachstellen auf (CVE-2023-38976 und CVE-2024-45846 bei Verwendung mit MindsDB). Weaviate existiert seit 2019 und ist damit ein wahrer Großvater dieses Technologie-Stacks, der jedoch immer noch einen wöchentlichen Veröffentlichungszyklus hat. Diese Veröffentlichungszyklen sind nicht in Stein gemeißelt, aber sie bedeuten doch, dass gefundene Bugs schnell gepatcht werden, wodurch die Zeit ihrer Verbreitung begrenzt wird.

LLMs für sich genommen erfüllen wahrscheinlich nicht alle Anforderungen und werden nur schrittweise verbessert, da ihnen die öffentlichen Daten zum Trainieren ausgehen. Die Zukunft gehört wahrscheinlich einer agentenbasierten KI, die LLMs, Speicher, Tools und Workflows in fortschrittlicheren KI-basierten Systemen kombiniert, so Andrew Ng, ein für seine Arbeiten zur Künstlichen Intelligenz und Robotik bekannter Informatiker. Es geht im Wesentlichen um einen neuen Software Entwicklungs-Stack, wobei die LLMs und die Vektorspeicher hier weiterhin eine wichtige Rolle spielen werden.

Doch Achtung: Unternehmen können auf dem Weg in diese Richtung Schaden nehmen, wenn sie nicht auf die Sicherheit ihrer Systeme achten.

Exponierte RAG-Komponenten

Wir befürchten, dass viele Entwickler diese Systeme in ihrer Eile dem Internet ungeschützt aussetzen könnten, und suchten deshalb im November 2024 nach öffentlich sichtbaren Instanzen einiger dieser RAG-Komponenten. Im Fokus standen dabei die vier wichtigsten Komponenten, die in RAG-Systemen zum Einsatz kommen: llama.cpp, Ollama, das LLMs hostet, sowie ChromaDB und Weaviate, die als Vektorspeicher dienen.

(pd/Trend Micro)