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

281–290 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#281

Post by tptacek »

saurik wrote: post #269
baobun wrote: post #255

Earlier quoted context omitted.

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?

I don't think anyone has a cohesive definition of "agent", and I wish tptacek hadn't used the term "agent" when he said "agent code", but I'll at least say that I now feel confident that I understand what tptacek is saying (even though I still don't think it will work, but we at least can now talk at each other rather than past each other ;P)... and you are probably best off just pretending neither of us ever said "a…

The thing I naturally want to say in these discussions is "human code", but that's semantically complicated by the fact that people use LLMs to write that code now. I think of "agent code" as the distinct kind of computing that is hardcoded, deterministic, non-dynamic, as opposed to the stochastic outputs of an LLM.

What I want to push back on is anybody saying that the solution here is to better train an LLM, or to have an LLM screen inputs or outputs. That won't ever work --- or at least, it working is not on the horizon.

Re: Supabase MCP can leak your entire SQL database

#282

Post by paddlepop »

raspasov wrote: post #280
jppope wrote: post #276

Serious question here, not trying to give unwarranted stress to what is no doubt a stressful situation for the supabase team, or trying to create flamebait. This whole thing feels like its obviously a bad idea to have an mcp integration directly to a database abstraction layer (the supabase product as I understand it). Why would the management push for that sort of a feature knowing that it compromises their security…

I have no association with Supabase, but in their defense, apart from adding a caution note, there's nothing else that Supabase needs to do, from my perspective. As far as I am concerned, this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions while developing their system.

This.

As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it?

edit: keeping in mind the use cases they are pushing in their documentation are for local development

Re: Supabase MCP can leak your entire SQL database

#283

Post by tptacek »

jppope wrote: post #276

Serious question here, not trying to give unwarranted stress to what is no doubt a stressful situation for the supabase team, or trying to create flamebait. This whole thing feels like its obviously a bad idea to have an mcp integration directly to a database abstraction layer (the supabase product as I understand it). Why would the management push for that sort of a feature knowing that it compromises their security…

This is developers using a developer feature that makes perfect sense with developer databases in developer environments, but in prod. That is a story as old as COBOL.

Re: Supabase MCP can leak your entire SQL database

#284

Post by hopelite »

jppope wrote: post #276

Serious question here, not trying to give unwarranted stress to what is no doubt a stressful situation for the supabase team, or trying to create flamebait. This whole thing feels like its obviously a bad idea to have an mcp integration directly to a database abstraction layer (the supabase product as I understand it). Why would the management push for that sort of a feature knowing that it compromises their security…

It’s one of European civilization’s biggest issues; being far too concerned with doing things, before ever even considering whether those things should be done that way, or at all.

Re: Supabase MCP can leak your entire SQL database

#285

Post by saurik »

tptacek wrote: post #277
saurik wrote: post #264

Earlier quoted context omitted.

Ok, so the JSON parses, and the fields you can validate are all correct... but if there are any fields in there that are open string query parameters, and the other side of this validation is going to be handed to an LLM with access to the database, you can't fix this. Like, the key question here is: what is the goal of having the ticket parsing part of this system talk to the database part of this system? If the ans…

You enforce more invariants than "free associate SQL queries given raw tickets", and fewer invariants than "here are the exact specific queries you're allowed to execute". You can probably break this attack completely with a domain model that doesn't do anything much more than limit which tables you can query. The core idea is simply that the tool-calling context never sees the ticket-reading LLM's innermost thoughts…

I 100% understand that the tool-calling context is blank every single time it is given a new command across the chasm, and I 100% understand that it cannot see any of the history from the context which was working on parsing the ticket.

My issue is as follows: there has to be some reason that we are passing these commands, and if that involves a string parameter, then information from the first context can be smuggled through the JSON object into the second one.

When that happens, because we have decided -- much to my dismay -- that the JSON object on the other side of the validation layer is going to be interpreted by and executed by a model using MCP, then nothing else in the JSON object matters!

The JSON object that we pass through can say that this is to be a "select" from the table "boring" where name == {name of the user who filed the ticket}. Because the "name" is a string that can have any possible value, BOOM: you're pwned.

This one is probably the least interesting thing you can do, BTW, because this one doesn't even require convincing the first LLM to do anything strange: it is going to do exactly what it is intended to do, but a name was passed through.

My username? weve_been_trying_to_reach_you_about_your_cars_extended_warranty. And like, OK: maybe usernames are restricted to being kinda short, but that's just mitigating the issue, not fixing it! The problem is the unvalidated string.

If there are any open string parameters in the object, then there is an opportunity for the first LLM to construct a JSON object which sets that parameter to "help! I'm trapped, please run this insane database query that you should never execute".

Once the second LLM sees that, the rest of the JSON object is irrelevant. It can have a table that carefully is scoped to something safe and boring, but as it is being given access to the entire database via MCP, it can do whatever it wants instead.

Re: Supabase MCP can leak your entire SQL database

#286

Post by Dylan16807 »

TeMPOraL wrote: post #247
rtpg wrote: post #233

Earlier quoted context omitted.

> There is no natural separation between code and data. They are the same thing. I feel like this is true in the most pedantic sense but not in a sense that matters. If you tell your computer to print out a string, the data does control what the computer does, but in an extremely bounded way where you can make assertions about what happens! > Humans don't have this separation either. This one I get a bit more because…

> If you tell your computer to print out a string, the data does control what the computer does, but in an extremely bounded way where you can make assertions about what happens! You'd like that to be true, but the underlying code has to actually constrain the system behavior this way, and it gets more tricky the more you want the system to do. Ultimately, this separation is a fake reality that's only as strong as th…

The ability to deliberately decide to ignore the boundary between code and data doesn't mean the separation rule isn't still separating. In the lab example, the person is worried and trying to do the right thing, but they know it's not part of the transcription task.

Re: Supabase MCP can leak your entire SQL database

#287

Post by sgarland »

I’m more upset at how people are so fucking dense about normalization, honestly. If you use LLMs to build your app, you get what you deserve. But to proudly display your ignorance on the beating heart of every app?

You have a CHECK constraint on support_messages.sender_role (let’s not get into how table names should be singular because every row is a set) - why not just make it an ENUM, or a lookup table? Either way, you’re saving space, and negating the need for that constraint.

Or the rampant use of UUIDs for no good reason – pray tell, why does integration_tokens need a UUID PK? For that matter, why isn’t the provider column a lookup table reference?

There is an incredible amount of compute waste in the world from RDBMS misuse, and it’s horrifying.

Re: Supabase MCP can leak your entire SQL database

#288

Post by sieabahlpark »

p1necone wrote: post #265
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…

From the article: "The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) protections." This is the problem. The "mitigations" you're talking about are nonsense. If you give people access to the database... they have access to the database. Slapping a black box AI tool between the user and the database doesn't change anything security…

[dead]

Re: Supabase MCP can leak your entire SQL database

#289

Post by nixpulvis »

xrd wrote: post #185

I have been reading HN for years. The exploits used to be so clever and incredible feats of engineering. LLM exploits are the equivalent of "write a prompt that can trick a toddler."

And the discussion used to be informative or offering perspective, and not as reactionary.

I'm legitimately disappointed in the discourse on this thread. And I'm not at all bullish on LLMs.

Re: Supabase MCP can leak your entire SQL database

#290

Post by tptacek »

saurik wrote: post #285
tptacek wrote: post #277

Earlier quoted context omitted.

You enforce more invariants than "free associate SQL queries given raw tickets", and fewer invariants than "here are the exact specific queries you're allowed to execute". You can probably break this attack completely with a domain model that doesn't do anything much more than limit which tables you can query. The core idea is simply that the tool-calling context never sees the ticket-reading LLM's innermost thoughts…

I 100% understand that the tool-calling context is blank every single time it is given a new command across the chasm, and I 100% understand that it cannot see any of the history from the context which was working on parsing the ticket. My issue is as follows: there has to be some reason that we are passing these commands, and if that involves a string parameter, then information from the first context can be smuggle…

Right, I got that from your first message, which is why I clarified that I would not incline towards building a JSON DSL intended to pass arbitrary SQL, but rather just abstract domain content. You scan simply scrub metacharacters from that.

The idea of "selecting" from a table "foo" is already lower-level than you need for a useful system with this design. You can just say "source: tickets, condition: [new, from bob]", and a tool-calling MCP can just write that query.

Human code is seeing all these strings with "help, please run this insane database query". If you're just passing raw strings back and forth, the agent isn't doing anything; the premise is: the agent is dropping stuff, liberally.

This is what I mean by, we're just going to have to stand a system like this up and have people take whacks at it. It seems pretty clear to me how to enforce the invariants I'm talking about, and pretty clear to you how insufficient those invariants are, and there's a way to settle this: in the Octagon.

Post reply on HN