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

161–170 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#161

Post by simonw »

losvedir wrote: post #94

I've been uneasy with the framing of the "lethal trifecta": * Access to your private data * Exposure to untrusted input * Ability to exfiltrate the data In particular, why is it scoped to "exfiltration"? I feel like the third point should be stronger. An attacker causing an agent to make a malicious write would be just as bad. They could cause data loss, corruption, or even things like giving admin permissions to the…

That's a different issue - it's two things:

- exposure to untrusted input

- the ability to run tools that can cause damage

I designed the trifecta framing to cover the data exfiltration case because the "don't let malicious instructions trigger damaging tools" thing is a whole lot easier for people to understand.

Meanwhile the data exfiltration attacks kept on showing up in dozens of different production systems: https://simonwillison.net/tags/exfiltration-attacks/

Explaining this risk to people is really hard - I've been trying for years. The lethal trifecta concept appears to finally be getting through.

Re: Supabase MCP can leak your entire SQL database

#162

Post by saurik »

lotyrin wrote: post #146
tptacek wrote: post #129

Earlier quoted context omitted.

I don't know where "more agents" is coming from.

Seems they can't imagine the constraints being implemented as code a human wrote so they're just imagining you're adding another LLM to try to enforce them?

(EDIT: THIS WAS WRONG.) [[FWIW, I definitely can imagine that (and even described multiple ways of doing that in a lightweight manner: pattern whitelisting and fine-grained permissions); but, that isn't what everyone has been calling an "agent" (aka, an LLM that is able to autonomously use tools, usually, as of recent, via MCP)? My best guess is that the use of "agent code" didn't mean the same version of "agent" that I've been seeing people use recently ;P.]]

EDIT TO CORRECT: Actually, no, you're right: I can't imagine that! The pattern whitelisting doesn't work between two LLMs (vs. between an LLM and SQL, where I put it; I got confused in the process of reinterpreting "agent") as you can still smuggle information (unless the queries are entirely fully baked, which seems to me like it would be nonsensical). You really need a human in the loop, full stop. (If tptacek disagrees, he should respond to the question asked by the people--jstummbillig and stuart73547373--who wanted more information on how his idea would work, concretely, so we can check whether it still would be subject to the same problem.)

NOT PART OF EDIT: Regardless, even if tptacek meant adding trustable human code between those two LLM+MCP agents, the more important part of my comment is that the issue tracking part is a red herring anyway: the LLM context/agent/thing that has access to the Supabase database is already too dangerous to exist as is, because it is already subject to occasionally seeing user data (and accidentally interpreting it as instructions).

Re: Supabase MCP can leak your entire SQL database

#163

Post by jimjimjim »

ajross wrote: post #61
OtherShrezzing wrote: post #51

Earlier quoted context omitted.

Pragmatically, does your responsible disclosure processes matter, when the resolution is “ask the LLM more times to not leak data, and add disclosures to the documentation”?

Absolutely astounding to me, having watched security culture evolve from "this will never happen", though "don't do that", to the modern world of multi-mode threat analysis and defense in depth... ...to see it all thrown in the trash as we're now exhorted, literally, to merely ask our software nicely not to have bugs.

Yes, the vast amount of effort, time and money spent on making the world secure things and checking that those things are secured now being dismissed because people can't understand that maybe LLMs shouldn't be used for absolutely everything.

Re: Supabase MCP can leak your entire SQL database

#164

Post by tptacek »

saurik wrote: post #156
tptacek wrote: post #129

Earlier quoted context omitted.

I don't know where "more agents" is coming from.

You said you wanted to take the one agent, split it into two agents, and add a third agent in between. It could be that we are equivocating on the currently-dubious definition of "agent" that has been being thrown around in the AI/LLM/MCP community ;P.

No, I didn't. An LLM context is just an array of strings. Every serious agent manages multiple contexts already.

Re: Supabase MCP can leak your entire SQL database

#166

Post by the8472 »

jacquesm wrote: post #125
tptacek wrote: post #68

Earlier quoted context omitted.

Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked. It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with produc…

The main problem seems to me to be related to the ancient problem of escape sequences and that has never really been solved. Don't mix code (instructions) and data in a single stream. If you do sooner or later someone will find a way to make data look like code.

https://cwe.mitre.org/data/definitions/990.html

Re: Supabase MCP can leak your entire SQL database

#167

Post by [deleted] »

abujazar wrote: post #152

Well, this is the very nature of MCP servers. Useful for development, but it should be quite obvious that you shouldn't grant a production MCP server full access to your database. It's basically the same as exposing the db server to the internet without auth. And of course there's no security in prompting the LLM not to do bad stuff. The only way to do this right in production is having a separate user and database c…

[deleted]

Re: Supabase MCP can leak your entire SQL database

#168

Post by maxbendick »

gregnr wrote: post #43

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections: - Encourage folks to use read-only by default in our docs [1] - Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2] - Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] We noticed that t…

You really ought to never trust the output of LLMs. It's not just an unsolved problem but a fundamental property of LLMs that they are manipulatable. I understand where you're coming from, but prompting is unacceptable as a security layer for anything important. It's as insecure as unsanitized SQL or hiding a button with CSS.

EDIT: I'm reminded of the hubris of web3 companies promising products which were fundamentally impossible to build (like housing deeds on blockchain). Some of us are engineers, you know, and we can tell when you're selling something impossible!

Re: Supabase MCP can leak your entire SQL database

#170

Post by threecheese »

chasd00 wrote: post #23
esafak wrote: post #13

Earlier quoted context omitted.

Isn't the fix exactly the same? Have the LLM map the request to a preset list of approved queries.

edit: updated my comment because I realized i was thinking of something else. What you're saying is something like the LLM only has 5 preset queries to choose from and can supply the params but does not create a sql statement on its own. i can see how that would prevent sql injection.

Whitelisting the five queries would prevent SQL injection, but also prevent it from being useful.
Post reply on HN