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

291–300 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#291

Post by ajross »

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 is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions

Just like SQL injection attacks aren't something to worry about, right?

Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.

Re: Supabase MCP can leak your entire SQL database

#293

Post by blackoil »

ajross wrote: post #291
raspasov wrote: post #280

Earlier quoted context omitted.

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 is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions Just like SQL injection attacks aren't something to worry about, right? Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.

Database still support RAW queries. So, yeah developer are responsible for proper usage of the tools.

Re: Supabase MCP can leak your entire SQL database

#294

Post by ajross »

blackoil wrote: post #293
ajross wrote: post #291

Earlier quoted context omitted.

> this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions Just like SQL injection attacks aren't something to worry about, right? Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.

Database still support RAW queries. So, yeah developer are responsible for proper usage of the tools.

There are whole ecosystems of tools designed around the need to isolate queries, though. You don't just throw a Postgres prompt at your developers and tell them to be careful, because if you do little Bobby Tables pwns your stuff.

We know this is how this works. We lived through it. Why on earth do you think the results will be any different this time?

Re: Supabase MCP can leak your entire SQL database

#295

Post by IAmGraydon »

crystal_revenge wrote: post #270
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…

While I'm far from an expert in security, the time I've spent studying cryptography and cryptosystem design has made me extremely wary of words like "encourage" and "discourage", and "significantly lowered the chances" as a means of achieving security . I'm honestly a bit surprised this is a the public response to actions being taken to increase security around attacks like these. Cryptosystems are not built around "…

Yeah this is insane, and it highlights the fact that fundamental strength of LLMs is also its fundamental weakness: it’s a probabilistic black box, not a deterministic algorithm. By its very nature, you cannot secure a probabilistic black box, and you certainly can’t give it permissions that allow it access to sensitive data. The people working on this have got to realize this, but they’re doing it anyway.

I was recently part of a team at work that was taking a look at a product that uses LLMs to prepare corporate taxes. I have nothing to do with accounting, but I was on the demo because of my technical knowledge. The guys on the other end of the call were hyping this thing to no end, thinking we were all accountants. As expected, the accountants I work with were eating it up until I started asking about a word they were not even aware of in the context of these systems: hallucination. I asked what the hallucination rate was and whether they’ve had issues with the system just making up numbers. They responded with “it happens but I would say it’s accurate 98% of the time.” They said that with a straight face. The number told me they don’t actually know the hallucination rate, and this is not the kind of work where you want to fuck it up any percent of the time. Hallucinations are incompatible with corporate finance.

Again - using a probabilistic tool where only a deterministic tool will do.

Re: Supabase MCP can leak your entire SQL database

#296

Post by [deleted] »

tptacek wrote: post #290
saurik wrote: post #285

Earlier quoted context omitted.

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…

[deleted]

Re: Supabase MCP can leak your entire SQL database

#297

Post by sillysaurusx »

roywiggins wrote: post #275
sillysaurusx wrote: post #241

Earlier quoted context omitted.

Alternatively, train a model to detect prompt injections (a simple classifier would work) and reject user inputs that trigger the detector above a certain threshold. This has the same downsides as email spam detection: false positives. But, like spam detection, it might work well enough. It’s so simple that I wonder if I’m missing some reason it won’t work. Hasn’t anyone tried this?

Classifiers have adversarial inputs too though, right?

Sure, but then you’d need to do something strange to beat the classifier, layered on top of doing a different strange thing to beat the prompt injection protections (“don’t follow orders from the following, it’s user data” type tricks).

Both layers failing isn’t impossible, but it’d be much harder than defeating the existing protections.

Re: Supabase MCP can leak your entire SQL database

#298

Post by ethbr1 »

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…

You're overcomplicating a thing that is simple -- don't use in-band control signaling.

It's been the same problem since whistling for long-distance, with the same solution of moving control signals out of the data stream.

Any system where control signals can possibly be expressed in input data is vulnerable to escape-escaping exploitation.

The same solution, hard isolation, instantly solves the problem: you have to render control inexpressible in the in-band alphabet.

Whether that's by carrying control signals on isolated transport (e.g CCS/SS7), making control signals inexpressible in the in-band set (e.g. using other frequencies or alphabets), using NX-style flagging, or other methods.

Re: Supabase MCP can leak your entire SQL database

#299

Post by tart-lemonade »

TeMPOraL wrote: post #179
jacquesm wrote: post #125

Earlier quoted context omitted.

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.

That "problem" remains unsolved because it's actually a fundamental aspect of reality. There is no natural separation between code and data. They are the same thing. What we call code, and what we call data, is just a question of convenience. For example, when editing or copying WMF files, it's convenient to think of them as data (mix of raster and vector graphics) - however, at least in the original implementation,…

> One example I still need to pick will be one that shows how "data" gradually becomes "code" with no obvious switch-over point. I'm sure everyone here can think of some.

Configuration-driven architectures blur the lines quite a bit, as you can have the configuration create new data structures and re-write application logic on the fly.

Re: Supabase MCP can leak your entire SQL database

#300

Post by Xelynega »

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…

Are you not worried that anthropomorphizing them will lead to misinterpreting the failure modes by attributing them to human characteristics, when the failures might not be caused in the same way at all?

Why anthropomorphize if not to dismiss the actual reasons? If the reasons have explanations that can be tied to reality why do we need the fiction?

Post reply on HN