Live data from Hacker News

Hacking Google Bard – From Prompt Injection to Data Exfiltration

embracethered.com

101–110 of 163 posts

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#101
post #48

Earlier quoted context omitted.

This isn't an LLM problem. It's a XSS problem, and it's as old as Myspace. I don't think prompt engineering needs to be considered. The solution is to treat an LLM as untrusted, and design around that.

How untrustworthy though? Shoud I simply discard all its output? Presumably not, so that's the problem.

Don't run it, not if you don't understand it anyway.

We'll be teaching people to watch out for untrustworthy chatbot generated code sometime soon, possibly too late.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#102

I tested bard prior to release and it was hilarious how breakable it was. The easiest trick I found was to just overflow its context. You fill up the entire context window with junk and then at the end introduce a new prompt and all it knows is that prompt because all the rules have been pushed out.

I was able to browse google and youtube source code in the very very early days. Was only patched when I called up a friend and let him know. And I tried to submit the flaw through normal channels of a supportless technology company but you can guess how well that went...

Well that's pure carelessness, isn't it. I'm guessing it was deployed on a server with volume mounts it shouldn't have while possibly running as root?

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#103

Whats the endgame here? Is the story of LLMs going to be a perpetual cat and mouse game of prompt engineering due to its lack of debuggability? Its going to be _very hard_ to integrate LLMs in sensitive spaces unless there are reasonable assurances that security holes can be patched (and are not just a property of the system)

History doesn't repeat itself, but it rhymes: I foresee LLMs needing to separate executable instructions from data, and marking the data as non-executable. How models themselves are trained will need to be changed so that the instructions channel is never confused with the data channel, and the data channel can be sanitized to avoid confusion. Having a single channel for code (instructions) and data is a security blu…

As you say, LLMs currently don't distinguish instructions from data, there is one stream of tokens, and AFAIK no one knows how to build a two-stream system that can still learn from the untrusted stream without risk.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#104
post #89
post #76

Earlier quoted context omitted.

> Maybe every response can be reviewed by a much simpler and specialised baby-sitter LLM? This doesn't really work in practice because you can just craft a prompt that fools both.

Then make a third llm that checks whether both of those llms have been fooled.

It's turtles all the way down.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#105
post #102

Earlier quoted context omitted.

I was able to browse google and youtube source code in the very very early days. Was only patched when I called up a friend and let him know. And I tried to submit the flaw through normal channels of a supportless technology company but you can guess how well that went...

Well that's pure carelessness, isn't it. I'm guessing it was deployed on a server with volume mounts it shouldn't have while possibly running as root?

That seems like a rather specific guess -- plenty of things can go wrong beside that problem.

I found the comment more reflective of lacking any reporting process, even for "major" vulnerabilities. These days, companies have turned bug bounties into a marketing and recruiting tool, so it's a very different story.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#106

We at Lakera AI work on a prompt injection detector that actually catches this particular attack. The models are trained on various data sources, including prompts from the Gandalf prompt injection game.

How can you provide assurance that that there are no false positives or negatives? XSS detection was a thing that people attempted and it failed miserably because you need it to work correctly 100% of the time for it to be useful. Said another way, what customer needs and is willing to pay for prompt injection protection but has some tolerance for error?

Good point (not sarcastically). What customer needs and is willing to pay for an antivirus that has some tolerance for error?

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#107
post #97

Earlier quoted context omitted.

How untrustworthy though? Shoud I simply discard all its output? Presumably not, so that's the problem.

Hacker News doesn't trust you, and you're still able to post text. There are safe ways to handle untrusted data sources.

Counterpoint: HackerNews does trust you. If they didn't, they would restrict or delete your account, and potentially block your IP. Just because trust is assumed by default doesn't mean there is no trust.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#108
post #91

Earlier quoted context omitted.

> because all the rules have been pushed out. Can you unpack this a little please? Is it possible to ELI5 the mechanisms involved that can "push" a rule set out? I would have assumed the rules apply globally/uniformly across the entire prompt

> ELI5 The model can look at X amount of input to decide what words come next. Normally, Google fills part of X with instructions, and you control the other part. However if you give it exactly X amount of input, then there's no room for Google's original instructions, and you control it all.

Thanks! So is patching this as simple as not allowing the entire space of X for user prompt? i.e. guaranteeing some amount of X for model owner's instructions

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#109

Earlier quoted context omitted.

I have beef with Lakera AI specifically -- Lakera AI has never produced a public demo that has a 100% defense rate against prompt injection. Lakera has launched a "game" that it uses for harvesting data to train its own models, but that game has never been effective at preventing 100% of attacks and does not span the full gamut of every possible attack. If Lakera AI had a defense for this, the company would be able t…

Sorry, where is Lakera claiming to have 100% success rate to an ever changing attack? Of course that’s a known fact among technical people expert in that matter that an impassable defense against any kind of attack of this nature is impossible.

> Sorry, where is Lakera claiming to have 100% success rate to an ever changing attack?

In any other context other than prompt injection, nearly everyone would interpret the following sentence as meaning Lakera's product will always catch this attack:

> We at Lakera AI work on a prompt injection detector that actually catches this particular attack.

If we were talking about SQL injections, and someone posted that prepared statements catch SQL injections, we would not expect them to be referring to a probabilistic solution. You could argue that the context is the giveaway, but honestly I disagree. I think this statement is very far off the mark:

> Of course that’s a known fact among technical people expert in that matter that an impassable defense against any kind of attack of this nature is impossible.

I don't think I've ever seen a thread on HN about prompt injection that hasn't had people arguing that it's either easy to solve or can be solved through chained outputs/inputs, or that it's not a serious vulnerability. There are people building things with LLMs today who don't know anything about this. There are people launching companies off of LLMs who don't know anything about prompt injection. The experts know, but very few of the people in this space are experts. Ask Simon how many product founders he's had to talk to on Twitter after they've written breathless threads where they discover for the first time that system prompts can be leaked by current models.

So the non-experts that are launching products discover prompt injection, and then Lakera swoops in and says they have a solution. Sure, they don't outright say that the solution is 100% effective. But they also don't make a strong point to say that it's not; and people's instincts about how security works fill in the gaps in their head.

People don't have the context or the experience to know that Lakera's "solution" is actually a probabilistic model and that it should not be used for serious security purposes. In fact, Lakera's product would be insufficient for Google to use in this exact situation. It's not appropriate for Lakera to recommend its own product for a use-case that its product shouldn't be used for. And I do read their comment as suggesting that Lakera AI's product is applicable to this specific Bard attack.

Should we be comfortable with a company coming into a thread about a security vulnerability and pitching a product that is not intended to be used for that class of security vulnerability? I think the responsible thing for them to do is at least point out that their product is intended to address a different kind of problem entirely.

A probabilistic external classifier is not sufficient to defend against data exfiltration and should not be advertised as a tool to guard against data exfiltration. It should only be advertised to defend against attacks where a 100% defense is not a requirement -- tasks like moderation, anti-spam, abuse detection, etc... But I don't think that most readers know that about injection classifiers, and I don't think Lakera AI is particularly eager to get people to understand that. For a company that has gone to great lengths to teach people about the potential dangers of prompt injection in general, that educational effort stops when it gets to the most important fact about prompt injection: that we do not (as of now) know how to securely and reliably defend against it.

Re: Hacking Google Bard – From Prompt Injection to Data Exfiltration

#110
post #108

Earlier quoted context omitted.

> ELI5 The model can look at X amount of input to decide what words come next. Normally, Google fills part of X with instructions, and you control the other part. However if you give it exactly X amount of input, then there's no room for Google's original instructions, and you control it all.

Thanks! So is patching this as simple as not allowing the entire space of X for user prompt? i.e. guaranteeing some amount of X for model owner's instructions

No. The input and the output are the same thing with transformers. Internally, you're providing them with some sequence of tokens and asking them to continue the sequence. If the sequence they generate exceeds their capacity, they can "forget" what they were doing.

The "obvious" fix for this is to ensure that the their instructions are always within their horizon. But that has lots of failure modes as well.

To really fix this, you need to find a way to fully isolate instructions, input data, and output.

Post reply on HN