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

421–430 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#421

Post by koakuma-chan »

lou1306 wrote: post #402
ttoinou wrote: post #399

Earlier quoted context omitted.

The entire point of programming is that (barring hardware failure and compiler bugs) the computer will always do exactly what it's told New AI tech is not like regular programming we had before. Now we have fuzzy inputs, fuzzy outputs

Given our spectacular inability to make "regular" programs secure in the absence of all that fuzziness, I don't know if it's a good idea.

> Given our spectacular inability to make "regular" programs secure in the absence of all that fuzziness

"our" - *base users? I only hear about *base apps shipping tokens in client code or not having auth checks on the server, or whatever

Re: Supabase MCP can leak your entire SQL database

#422

Post by layoric »

TeMPOraL wrote: post #197
layoric wrote: post #187

Earlier quoted context omitted.

Spot on. The issue I think a lot of devs are grappling with is the non deterministic nature of LLMs. We can protect against SQL injection and prove that it will block those attacks. With LLMs, you just can’t do that.

It's not the non-determinism that's a problem by itself - it's that the system is intended to be general, and you can't even enumerate ways it can be made to do something you don't want it to do, much less restrict it without compromising the features you want. Or, put in a different way, it's the case where you want your users to be able to execute arbitrary SQL against your database, a case where that's a core feat…

> it's that the system is intended to be general, and you can't even enumerate ways it can be made to do something you don't want it to do, much less restrict it without

Very true, and worse the act of prompting gives the illusion of control, to restrict/reduce the scope of functionality, even empirically showing the functional changes you wanted in limited test cases. The sooner this can be widely accepted and understood well the better for the industry.

Appreciate your well thought out descriptions!

Re: Supabase MCP can leak your entire SQL database

#423

Post by Dylan16807 »

TeMPOraL wrote: post #393
Dylan16807 wrote: post #286

Earlier quoted context omitted.

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.

The point is, there is no hard boundary. The LLM too may know[0] following instructions in data isn't part of transcription task, and still decide to do it. -- [0] - In fact I bet it does, in the sense that, doing something like Anthropic did[1], you could observe relevant concepts being activated within the model. This is similar to how it turned out the model is usually aware when it doesn't know the answer to a qu…

If you can measure that in a reliable way then things are fine. Mixup prevented.

If you just ask, the human is not likely to lie but who knows with the LLM.

Re: Supabase MCP can leak your entire SQL database

#424

Post by simonw »

Johngibb wrote: post #346
simonw wrote: post #258

Earlier quoted context omitted.

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.

I am actually asking this question in good faith: are we certain that there's no way to write a useful AI agent that's perfectly defended against injection just like SQL injection is a solved problem? Is there potentially a way to implement out-of-band signaling in the LLM world, just as we have in telephones (i.e. to prevent phreaking) and SQL (i.e. to prevent SQL injection)? Is there any active research in this are…

This is still an unsolved problem. I've been tracking it very closely for almost three years - https://simonwillison.net/tags/prompt-injection/ - and the moment a solution shows up I will shout about it from the rooftops.

Re: Supabase MCP can leak your entire SQL database

#425

Post by skinner927 »

reddalo wrote: post #368
skinner927 wrote: post #327

Earlier quoted context omitted.

Microsoft’s cloud gets hacked multiple times a year, nobody cares. Everyone is connecting everything together. Business people with no security training/context are “writing” integrations with Lego-like services (and now LLMs). Cloudflare hiccups and the Internet crashes. Nobody cares about the things you’re saying anymore (I do!!). Extract more money. Move faster. Outcompete. Fix it later. Just get a bigger cyber in…

>Microsoft’s cloud gets hacked multiple times a year What cloud? Private SharePoint instances? Accounts? Free Outlook accounts? Do you have any source on this?

https://www.theguardian.com/technology/2024/apr/03/microsoft...

Re: Supabase MCP can leak your entire SQL database

#426

Post by simonw »

frabcus wrote: post #362
paddlepop wrote: post #282

Earlier quoted context omitted.

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

Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it. MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem. Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to d…

> MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem.

That's exactly the problem here: the ability for end users to combine MCP tools means that those end users are now responsible for avoiding insecure tool combinations. That's a really hard thing for end users to do - they have to understand the lethal trifecta risk in order to make those decisions.

Re: Supabase MCP can leak your entire SQL database

#427

Post by simonw »

jstummbillig wrote: post #379
simonw wrote: post #329

Earlier quoted context omitted.

There's a crucial difference here. When you were working as a pentester, how often did you find a security hole and report it and the response was "it is impossible for us to fix that hole"? If you find an XSS or a SQL injection, that means someone made a mistake and the mistake can be fixed. That's not the case for prompt injections. My favorite paper on prompt injection remedies is this one: https://arxiv.org/abs/2…

How would you say this compares to human error? Let's say instead of the LLM there's a human that can be fooled into running an unsafe query and returning data. Is there anything fundamentally different there, that makes it less of a problem?

You can train the human not to fall for this, and discipline, demote or even fire them if they make that mistake.

Re: Supabase MCP can leak your entire SQL database

#428

Post by simonw »

raspasov wrote: post #383
simonw wrote: post #325

Earlier quoted context omitted.

> No different from exposing a REST endpoint that fetches private sales figures; then someone might find or guess that endpoint and leak the data. I don't think you fully understand this vulnerability. This isn't the same thing as an insecure REST endpoint. You can have completely secure endpoints here and still get your data stolen because the unique instruction following nature of LLMs means that your system can be…

I think I fully understand it. I was just making an analogy which is imprecise by definition. If you are inputting untrusted content in an LLM that has abilities to run code and side-effect the outside world a vulnerability is guaranteed. I don’t need a list of papers to tell me that. The cases you are outlining are more abstract and hypothetical. LLM AI assistant… Summarizing email or web page is one thing. But LLM…

> If you are inputting untrusted content in an LLM that has abilities to run code and side-effect the outside world a vulnerability is guaranteed.

OK, you do get it then!

Re: Supabase MCP can leak your entire SQL database

#429

Post by simonw »

pmontra wrote: post #394
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 write about mitigations and I'm afraid that you are correct. Can any method be more than just a mitigation? When we give read access to something to somebody we can expect that only loyalty (or fear, or... but let's stick with loyalty) prevents that person from leaking information to other parties. Improvements to prompting might increase the LLM equivalent of loyalty but people will always be creative at finding…

Giving read access to only the people who should have read access doesn't solve the problem here.

The vulnerability is when people who should have read access to the database delegate their permission to an LLM tool which may get confused by malicious instructions it encounters and leak the data.

If the LLM tool doesn't have a way to leak that data, there's no problem.

But this is MCP, so the risk here is that the user will add another, separate MCP tools (like a fetch web content tool) that can act as an exfiltration vector.

Re: Supabase MCP can leak your entire SQL database

#430

Post by gortok »

I am baffled by the irrational exuberance of the MCP model.

Before we even get into the technical underpinnings and issues, there's a logical problem that should have stopped seasoned technologists dead in their tracks from going further, and that is:

> What are the probable issues we will encounter once we release this model into the wild, and how what is the worst that can probably happen.

The answer to that thought-experiment should have foretold this very problem, and that would have been the end of this feature.

This is not a nuanced problem, and it does not take more than an intro-level knowledge of security flaws to see. Allowing an actor (I am sighing as I say this, but "Whether human or not") to input whatever they would like is a recipe for disaster and has been since the advent of interconnected computers.

The reason why this particularly real and not-easy-to-solve vulnerability made it this far (and permeates every MCP as far as I can tell) is because there is a butt-load (technical term) of money from VCs and other types of investors available to founders if they slap the term "AI" on something, and because the easy surface level stuff is already being thought of, why not revolutionize software development by making it as easy as typing a few words into a prompt?

Programmers are expensive! Typing is not! Let's make programmers nothing more than typists!

And because of the pursuit of funding or of a get-rich-quick mentality, we're not only moving faster and with reckless abandon, we've also abandoned all good sense.

Of course, for some of us, this is going to turn out to be a nice payday. For others, the ones that have to deal with the data breaches and real-world effects of unleashing AI on everything, it's going to suck, and it's going to keep sucking. Rational thought and money do not mix, and this is another example of that problem at work.

Post reply on HN