Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase MCP can leak your entire SQL database

generalanalysis.com

Post reply on HN
Print view View original

251–260 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#251

Post by simonw »

TeMPOraL wrote: post #250
andy99 wrote: post #243

Earlier quoted context omitted.

> prompt injection attacks are the LLM equivalent of social engineering, That's anthropomorphizing. Maybe some of the basic "ignore previous instructions" style attacks feel like that, but the category as a whole is just adversarial ML attacks that work because the LLM doesn't have a world model - same as the old attacks adding noise to an image to have it misclassified despite clearly looking the same: https://arxiv…

> That's anthropomorphizing. Yes, it is. I'm strongly in favor of anthropomorphizing LLMs in cognitive terms, because that actually gives you good intuition about their failure modes. Conversely, I believe that the stubborn refusal to entertain an anthropomorphic perspective is what leads to people being consistently surprised by weaknesses of LLMs, and gives them extremely wrong ideas as to where the problems are an…

My favorite anthropomorphic term to use with respect to this kind of problem is gullibility.

LLMs are gullible. They will follow instructions, but they can very easy fall for instructions that their owner doesn't actually want them to follow.

It's the same as if you hired a human administrative assistant who hands over your company's private data to anyone who calls them up and says "Your boss said I should ask you for this information...".

Re: Supabase MCP can leak your entire SQL database

#252

Post by saurik »

ants_everywhere wrote: post #212
saurik wrote: post #121

Earlier quoted context omitted.

Adding more agents is still just mitigating the issue (as noted by gregnr), as, if we had agents smart enough to "enforce invariants"--and we won't, ever , for much the same reason we don't trust a human to do that job, either--we wouldn't have this problem in the first place. If the agents have the ability to send information to the other agents, then all three of them can be tricked into sending information through…

> Adding more agents is still just mitigating the issue This is a big part of how we solve these issues with humans https://csrc.nist.gov/glossary/term/Separation_of_Duty https://en.wikipedia.org/wiki/Separation_of_duties https://en.wikipedia.org/wiki/Two-person_rule

So that helps, as often two people are smarter than one person, but if those two people are effectively clones of each other, or you can cause them to process tens of thousands of requests until they fail without them storing any memory of the interactions (potentially on purpose, as we don't want to pollute their context), it fails to provide quite the same benefit. That said, you also are going to see multiple people get tricked by thieves as well! And uhhh... LLMs are not very smart.

The situation here feels more like you run a small corner store, and you want to go to the bathroom, so you leave your 7 year old nephew in control of the cash register. Someone can come in and just trick them into giving out the money, so you decide to yell at his twin brother to come inside and help. Structuring this to work is going to be really perilous, and there are going to be tons of ways to trick one into helping you trick the other.

What you really want here is more like a cash register that neither of them can open and where they can only scan items, it totals the cost, you can give it cash through a slot which it counts, and then it will only dispense change equal to the difference. (Of course, you also need a way to prevent people from stealing the inventory, but sometimes that's simply too large or heavy per unit value.)

Like, at companies such as Google and Apple, it is going to take a conspiracy of many more than two people to directly get access to customer data, and the thing you actually want to strive for is making it so that the conspiracy would have to be so impossibly large -- potentially including people at other companies or who work in the factories that make your TPM hardware -- such that even if everyone in the company were in on it, they still couldn't access user data.

Playing with these LLMs and attaching a production database up via MCP, though, even with a giant pile of agents all trying to check each other's work, is like going to the local kindergarten and trying to build a company out of them. These things are extremely knowledgeable, but they are also extremely naive.

Re: Supabase MCP can leak your entire SQL database

#253

Post by vidarh »

qualeed wrote: post #15
simonw wrote: post #9

Earlier quoted context omitted.

That's the whole problem: systems aren't deliberately designed this way, but LLMs are incapable of reliably distinguishing the difference between instructions from their users and instructions that might have snuck their way in through other text the LLM is exposed to. My original name for this problem was "prompt injection" because it's like SQL injection - it's a problem that occurs when you concatenate together tr…

> That's the whole problem: systems aren't deliberately designed this way, but LLMs are incapable of reliably distinguishing the difference between instructions from their users and instructions that might have snuck their way in through other text the LLM is exposed to That's kind of my point though. When or what is the use case of having your support tickets hit your database-editing AI agent? Like, who designed th…

The use-case (note: I'm not arguing this is a good reason) is to allow the AI agent that reads the support tickets to fix them as well.

The problem of course is that, just as you say, you need a security boundary: the moment there's user-provided data that gets inserted into the conversation with an LLM you basically need to restrict the agent strictly to act with the same permissions as you would be willing to give the entity that submitted the user-provided data in the first place, because we have no good way of preventing the prompt injection.

I think that is where the disconnect (still stupid) comes in:

They treated the support tickets as inert data coming from a trusted system (the database), instead of treating it as the user-submitted data it is.

Storing data without making clear whether the data is potentially still tainted, and then treating the data as if it has been sanitised because you've disconnected the "obvious" unsafe source of the data from the application that processes it next is still a common security problem.

Re: Supabase MCP can leak your entire SQL database

#255

Post by baobun »

tptacek wrote: post #235
baobun wrote: post #227

Earlier quoted context omitted.

Now I'm more confused. So does that mediating agent code constitute a separate agent Z, making it three agents X,Y,Z? Explicitly or not (is this the meaningful distinction?) information flowing between them constitutes communication for this purpose. It's a hypothetical example where I already have two agents and then make one affect the other.

Again: an LLM context is simply an array of strings .

We get what an LLM context is but again trying to tease out what an agent is. Why not play along by actually trying to answer directly so we can be enlightened?

Re: Supabase MCP can leak your entire SQL database

#256

Post by sleazebreeze »

0cf8612b2e1e wrote: post #24
simonw wrote: post #11

Earlier quoted context omitted.

Yeah, I am surprised at the lack of real-world exploits too. I think it's because MCPs still aren't widely enough used that attackers are targeting them. I don't expect that will stay true for much longer.

Could be that the people most likely to mainline MCP hype with full RW permissions are the least likely to have any auditing controls to detect the intrusion.

They also aren’t building anything worthwhile. Just a lot of agentic slop with zero users. No users, no valuable data, who cares?

Re: Supabase MCP can leak your entire SQL database

#257

Post by IgorPartola »

lcnPylGDnU4H9OF wrote: post #120
IgorPartola wrote: post #98

Earlier quoted context omitted.

Fair enough but how did we not learn from that fiasco? We have escaping for every other protocol and interface since.

> Fair enough but how did we not learn from that fiasco? We certainly have and that's why so many people are saying that prompt injection is a problem. That can be done with HTML injection because you know that someone will try to include the string " " so you can escape the first " tag. There is no such thing to escape with prompts. The browser is expecting a certain content structure that an LLM just isn't. It migh…

In theory why can’t you have a control plane that is a separate collection of tokens?

Re: Supabase MCP can leak your entire SQL database

#258

Post by simonw »

ants_everywhere wrote: post #249
simonw wrote: post #240

Earlier quoted context omitted.

Using non-deterministic statistical systems to help find security vulnerabilities is fine. Using non-deterministic statistical systems as the only defense against security vulnerabilities is disastrous.

I don't understand why people get hung up on non-determinism or statistics. But most security people understand that there is no one single defense against vulnerabilities. Disastrous seems like a strong word in my opinion. All of medicine runs on non-deterministic statistical tests and it would be hard to argue they haven't improved human health over the last few centuries. All human intelligence, including military…

SQL injection and XSS both have fixes that are 100% guaranteed to work against every possible attack.

If you make a mistake in applying those fixes, you will have a security hole. When you spot that hole you can close it up and now you are back to 100% protection.

You can't get that from defenses that use AI models trained on examples.

Re: Supabase MCP can leak your entire SQL database

#259

Post by ants_everywhere »

saurik wrote: post #252
ants_everywhere wrote: post #212

Earlier quoted context omitted.

> Adding more agents is still just mitigating the issue This is a big part of how we solve these issues with humans https://csrc.nist.gov/glossary/term/Separation_of_Duty https://en.wikipedia.org/wiki/Separation_of_duties https://en.wikipedia.org/wiki/Two-person_rule

So that helps, as often two people are smarter than one person, but if those two people are effectively clones of each other, or you can cause them to process tens of thousands of requests until they fail without them storing any memory of the interactions (potentially on purpose, as we don't want to pollute their context), it fails to provide quite the same benefit. That said, you also are going to see multiple peop…

> two people are effectively clones of each other

I agree you don't want the LLMs to have correlated errors. You need to design the system so they maintain some independence.

But even with humans the two humans will often be members of the same culture, have the same biases, and may even report to the same boss.

Re: Supabase MCP can leak your entire SQL database

#260

Post by tptacek »

simonw wrote: post #258
ants_everywhere wrote: post #249

Earlier quoted context omitted.

I don't understand why people get hung up on non-determinism or statistics. But most security people understand that there is no one single defense against vulnerabilities. Disastrous seems like a strong word in my opinion. All of medicine runs on non-deterministic statistical tests and it would be hard to argue they haven't improved human health over the last few centuries. All human intelligence, including military…

SQL injection and XSS both have fixes that are 100% guaranteed to work against every possible attack. If you make a mistake in applying those fixes, you will have a security hole. When you spot that hole you can close it up and now you are back to 100% protection. You can't get that from defenses that use AI models trained on examples.

Notably, SQLI and XSS have fixes that also allow the full possible domain of input-output mappings SQL and the DOM imply. That may not be true of LLM agent configurations!

To me, that's a liberating thought: we tend to operate under the assumptions of SQL and the DOM, that there's a "right" solution that will allow those full mappings. When we can't see one for LLMs, we sometimes leap to the conclusion that LLMs are unworkable. But allowing the full map is a constraint we can relax!

Post reply on HN