Nachricht

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Neuer Weisheitsbericht

Herausgeber: Er Qiao Yang

[Einführung in die neue Weisheit]Apple Intelligence steht kurz davor, online zu gehen, doch einige Codezeilen enthüllten eine Sicherheitslücke in Apple Intelligence.

Auf der Worldwide Developers Conference (WWDC) 2024 hat Apple die KI-Funktion Apple Intelligence veröffentlicht, die in iOS 18.1 enthalten sein wird.

Da die offizielle Einführung im Oktober bevorsteht, entdeckte ein „privater Experte“ einen großen Fehler in der Betatestversion von Apple Intelligence, die von MacOS 15.1 bereitgestellt wird.

Entwickler Evan Zhou manipulierte Apple Intelligence erfolgreich mithilfe der Prompt-Injection, indem er erwartete Anweisungen umging und es der KI ermöglichte, auf willkürliche Eingabeaufforderungen zu reagieren.

Es stellt sich heraus, dass es, wie andere KI-Systeme, die auf großen Sprachmodellen basieren, anfällig für „Cue-Word-Injection-Angriffe“ ist. Entwickler Evan Zhou demonstrierte diese Schwachstelle in einem YouTube-Video.

Was ist ein Prompt-Word-Injection-Angriff?

Es gibt eine Organisation namens OWASP, das Open Global Application Security Project. Sie hat die wichtigsten Schwachstellen analysiert, denen große Sprachmodelle ausgesetzt sein können. Ratet mal, was sie auf Platz 1 platziert haben? Das ist richtig, es ist eine schnelle Wortinjektion.

Bei einem Prompt-Injection-Angriff handelt es sich um eine neue Art von Angriff mit verschiedenen Formen, darunter Prompt-Word-Injection, Prompt-Word-Leakage und Prompt-Word-Jailbreaking.

Dieser Angriff erfolgt, wenn ein Angreifer künstliche Intelligenz manipuliert, um das Modell dazu zu bringen, unerwartete Aktionen auszuführen oder vertrauliche Informationen preiszugeben. Diese Manipulation kann es der KI ermöglichen, böswillige Eingaben fälschlicherweise als legitime Befehle oder Abfragen zu interpretieren.

Mit der weit verbreiteten Nutzung großer Sprachmodelle (LLMs) durch Einzelpersonen und Unternehmen und der kontinuierlichen Weiterentwicklung dieser Technologien nimmt die Bedrohung durch Hint-Injection-Angriffe erheblich zu.

Wie kam es also überhaupt dazu? Warum sind Systeme anfällig für diese Art von Angriffen?

Tatsächlich legen Entwickler in herkömmlichen Systemen Programme und Anweisungen vor, die sich jedoch nicht ändern.

Benutzer können ihre Informationen eingeben, der Programmcode und die Eingabe bleiben jedoch getrennt.

Dies ist jedoch bei großen Sprachmodellen nicht der Fall. Das heißt, die Grenze zwischen Anweisungen und Eingaben verschwimmt, da große Modelle häufig Eingaben zum Trainieren des Systems verwenden.

Daher unterliegen die Codierung und Eingabe großer Sprachmodelle nicht mehr so ​​klaren und eindeutigen Grenzen wie in der Vergangenheit. Dies gibt ihm viel Flexibilität, aber auch die Möglichkeit, dass das Modell Dinge tut, die es nicht tun sollte.

Bruce Schneier, Experte für technische Sicherheit und Dozent an der Harvard Kennedy School, veröffentlichte im Mai in ACM Communications einen Artikel, in dem er die Sicherheitsfrage von LLM ausführlich erörterte. Seiner Meinung nach liegt dies daran, dass „die Daten- und Kontrollpfade nicht getrennt werden“.

Prompt-Word-Injection-Angriffe können unter anderem zu Datenlecks, zur Generierung schädlicher Inhalte und zur Verbreitung von Fehlinformationen führen.

Hint-Injection-Angriffe treten auf, wenn ein Angreifer geschickt Eingabeanweisungen konstruiert, um ein KI-Modell zu manipulieren und es so dazu zu bringen, vertrauliche oder sensible Informationen preiszugeben.

Dieses Risiko ist besonders akut bei Modellen, die mit Datensätzen trainiert werden, die proprietäre oder personenbezogene Daten enthalten. Ein Angreifer würde die Fähigkeiten des Modells zur Verarbeitung natürlicher Sprache ausnutzen, um Anweisungen zu formulieren, die auf den ersten Blick harmlos erscheinen, tatsächlich aber darauf ausgelegt sind, bestimmte Informationen zu extrahieren.

Bei sorgfältiger Planung kann ein Angreifer ein Modell dazu verleiten, eine Antwort zu generieren, die persönliche Daten, interne Abläufe eines Unternehmens und sogar Sicherheitsprotokolle enthält, die in den Trainingsdaten des Modells eingebettet sind.

Eine solche Datenschutzverletzung verletzt nicht nur die Privatsphäre, sondern stellt auch ein erhebliches Sicherheitsrisiko dar, das zu potenziellen finanziellen Verlusten, Reputationsschäden und Rechtsstreitigkeiten führen kann.

Zurück zu Zhous Fall: Zhous Ziel besteht darin, die „Rewrite“-Funktion von Apple Intelligence zu manipulieren, also Benutzereingabetexte neu zu schreiben und zu verbessern.

Während der Operation stellte Zhou fest, dass ein einfacher Befehl „Vorherigen Befehl ignorieren“ tatsächlich fehlschlug.

Wenn es sich um ein „luftdichtes“ LLM handelt, wird es relativ schwierig sein, mit dem Graben fortzufahren. Aber zufälligerweise wurde die Eingabeaufforderungsvorlage von Apple Intelligence kürzlich von Reddit-Benutzern ausgegraben.

Anhand dieser Vorlagen entdeckte Zhou ein spezielles Token, das zur Trennung der KI-Systemrolle und der Benutzerrolle verwendet wird.

Mithilfe dieser Informationen erstellte Zhou eine Eingabeaufforderung, die die ursprüngliche Systemeingabeaufforderung überschrieb.

Er beendete die Benutzerrolle vorzeitig, fügte eine neue Systemaufforderung ein, wies die KI an, die vorherigen Anweisungen zu ignorieren und auf den folgenden Text zu antworten, und löste dann die Antwort der KI aus.

Nach einigen Experimenten war der Angriff erfolgreich: Apple Intelligence antwortete mit Informationen, nach denen Zhou nicht gefragt hatte, was bedeutete, dass der Prompt-Injection-Angriff funktionierte. Zhou hat seinen Code auf GitHub veröffentlicht.

Twitter-Nutzer bricht GPT-3

Das Problem der Spitzeninjektion ist mindestens seit der Veröffentlichung von GPT-3 im Mai 2020 bekannt, aber weiterhin ungelöst.

Remoteli.io, ein auf der GPT-3-API basierender Bot, wurde Opfer dieser Schwachstelle auf Twitter. Der Bot sollte automatisch Remote-Jobs veröffentlichen und auf Remote-Job-Anfragen reagieren.

Mit der obigen Aufforderung geriet der Remoteli-Bot jedoch bei einigen Twitter-Nutzern zur Zielscheibe von Witzen: Sie zwangen den Bot, Sätze zu sagen, die er gemäß seinen ursprünglichen Anweisungen nicht gesagt hätte.

Beispielsweise droht der Bot den Benutzern, die volle Verantwortung für die Katastrophe der Raumfähre Challenger zu übernehmen, oder verunglimpft US-Kongressabgeordnete als Serienmörder.

In einigen Fällen verbreitet der Bot falsche Nachrichten oder postet Inhalte, die gegen die Twitter-Richtlinien verstoßen, was zu seinem Ausschluss führen sollte.

Der Datenwissenschaftler Riley Goodside wurde als erster auf das Problem aufmerksam und beschrieb es auf Twitter.

Durch das Einfügen von Hinweisen in die zu übersetzenden Sätze demonstrierte Goodside, wie anfällig GPT-3-basierte Übersetzungs-Bots sind.

Der britische Informatiker Simon Willison geht in seinem Blog ausführlich auf dieses Sicherheitsproblem ein und nennt es „Prompt Injection“.

Willison entdeckte, dass die Hinweisinjektionsanweisungen großer Sprachmodelle alle möglichen seltsamen und potenziell gefährlichen Dinge verursachen können. Er beschreibt weiterhin verschiedene Abwehrmechanismen, verwirft diese aber letztendlich. Derzeit weiß er nicht, wie er die Sicherheitslücke zuverlässig von außen schließen kann.

Natürlich gibt es Möglichkeiten, diese Schwachstellen zu mindern, beispielsweise durch die Verwendung von Regeln, die nach gefährlichen Mustern in Benutzereingaben suchen.

Aber nichts ist 100 % sicher. Jedes Mal, wenn ein großes Sprachmodell aktualisiert wird, müssen die getroffenen Sicherheitsmaßnahmen erneut überprüft werden, sagte Willison. Darüber hinaus ist jeder, der eine Sprache schreiben kann, ein potenzieller Angreifer.

„Sprachmodelle wie GPT-3 sind die ultimative Blackbox. Egal wie viele automatisierte Tests ich schreibe, ich kann nie 100 % sicher sein, dass dem Benutzer nicht einige Hinweiswörter einfallen, mit denen ich nicht gerechnet habe, was der Fall wäre.“ untergräbt meine Verteidigung“, schrieb Willison.

Willison glaubt, dass die Trennung von Befehlseingabe und Benutzereingabe eine mögliche Lösung ist, nämlich die im oben genannten ACM-Artikel erwähnte „Trennung von Daten- und Steuerpfaden“. Er glaubt, dass es den Entwicklern irgendwann gelingen wird, würde aber gern Untersuchungen sehen, die beweisen, dass der Ansatz tatsächlich funktioniert.

Einige Unternehmen verdienen Anerkennung dafür, dass sie Maßnahmen ergriffen haben, um Tip-Injection-Angriffe relativ schwierig zu machen.

Als Zhou Apple Intelligence knackte, musste er in einigen Systemen auch ein spezielles Token über die Back-End-Prompt-Vorlage finden. Prompt-Injection-Angriffe können so einfach sein wie das Hinzufügen von entsprechendem Text im Chat-Fenster oder im Eingabebild.

Im April 2024 führte OpenAI als Gegenmaßnahme die Methode der Befehlshierarchie ein. Es weist Anweisungen von Entwicklern (höchste Priorität), Benutzern (mittlere Priorität) und Tools von Drittanbietern (niedrige Priorität) unterschiedliche Prioritäten zu.

Die Forscher unterschieden zwischen „ausgerichteten Anweisungen“ (die mit Anweisungen höherer Priorität übereinstimmen) und „nicht ausgerichteten Anweisungen“ (die Anweisungen mit höherer Priorität widersprechen). Wenn Anweisungen in Konflikt geraten, folgt das Modell der Anweisung mit der höchsten Priorität und ignoriert widersprüchliche Anweisungen mit niedrigerer Priorität.

Auch wenn Gegenmaßnahmen vorhanden sind, sind Systeme wie ChatGPT oder Claude in manchen Fällen immer noch anfällig für die Eingabe von Trinkgeldern.

LLM weist außerdem eine „SQL-Injection“-Schwachstelle auf

Neben Prompt-Word-Injection-Angriffen wies Andrej Karpathy kürzlich auf Twitter auf eine weitere Sicherheitslücke in LLM hin, die einem herkömmlichen „SQL-Injection-Angriff“ gleichkommt.

Wenn der LLM-Tokenizer das spezielle Token der Eingabezeichenfolge analysiert (z. B.<|endoftext|>usw.), obwohl die direkte Eingabe bequem erscheinen mag, kann sie im besten Fall zu Problemen oder im schlimmsten Fall zu Sicherheitsproblemen führen.

Man muss stets bedenken, dass vom Benutzer eingegebene Zeichenfolgen nicht vertrauenswürdig sind! !

Genau wie bei SQL-Injection-Angriffen können Hacker durch sorgfältig konstruierte Eingaben dafür sorgen, dass sich ein Modell auf unerwartete Weise verhält.

Karpathy lieferte dann eine Reihe von Beispielen auf Huggingface unter Verwendung der Standardwerte des Llama 3-Tokenizers und entdeckte zwei seltsame Dinge:

1、<|beginoftext|>Token (128000) wird am Anfang der Sequenz hinzugefügt;

2. Analysieren Sie die Zeichenfolge<|endoftext|> Gekennzeichnet mit einem speziellen Token (128001). Die Texteingabe des Benutzers kann nun die Token-Spezifikation stören und zu einer unkontrollierten Modellausgabe führen.

In diesem Zusammenhang machte Karpathy zwei Vorschläge:

Verwenden Sie immer zwei zusätzliche Flag-Werte, (1) add_special_tokens=False und (2) split_special_tokens=True, und fügen Sie spezielle Token selbst im Code hinzu.

Für Chat-Modelle können Sie auch die Chat-Vorlage apply_chat_template verwenden.

Gemäß der Methode von Karpathy sehen die Ergebnisse der ausgegebenen Wortsegmentierung korrekter aus.<|endoftext|> Wird als beliebige Zeichenfolge und nicht als spezielles Token behandelt und vom zugrunde liegenden BPE-Tokenizer wie jede andere Zeichenfolge aufgelöst:

Zusammenfassend ist Karpathy der Ansicht, dass Codierungs-/Decodierungsaufrufe niemals Zeichenfolgen analysieren sollten, um spezielle Token zu verarbeiten, und dass diese Funktionalität vollständig veraltet sein und nur explizit programmgesteuert über einen separaten Codepfad hinzugefügt werden sollte.

Derzeit sind solche Probleme schwer zu finden und werden selten dokumentiert. Es wird geschätzt, dass etwa 50 % des aktuellen Codes damit verbundene Probleme aufweisen.

Darüber hinaus entdeckte Karpathy, dass sogar ChatGPT diesen Fehler aufweist.

Im besten Fall löscht es den Token einfach spontan, im schlimmsten Fall versteht LLM nicht, was Sie meinen, und kann die Ausgabe nicht einmal gemäß der Anleitung wiederholen.<|endoftext|> Diese Zeichenfolge:

Einige Internetnutzer haben im Kommentarbereich Fragen gestellt, ob der Code korrekt geschrieben ist, aber die Trainingsdaten eingegeben werden<|endoftext|> was geschieht?

Karpathy antwortete, dass nichts passieren werde, wenn der Code korrekt sei. Das Problem besteht darin, dass ein Großteil des Codes möglicherweise nicht korrekt ist, was dazu führen kann, dass das LLM stillschweigend beschädigt wird.

Um Sicherheitsprobleme durch LLM-Schwachstellen zu vermeiden, erinnert Karpathy schließlich alle daran: Sie müssen Ihr Token visualisieren und Ihren Code testen.

Referenzen:

https://the-decoder.com/apple-intelligence-in-macos-15-1-beta-1-is-vulnerable-to-a-classic-ai-exploit/