Re: allow building trusted languages without the untrusted versions

On Mon, May 23, 2022 at 4:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maybe I shouldn't be putting words into Nathan's mouth, but I think
> what he is after is a mode intended for use by cloud service providers,
> who would like to offer locked-down database services where there's
> just no way to get to the disk from inside the DB, superuser or no.

The cloud service provider use case is also what I was thinking about.

> What you're talking about is perhaps interesting to a different set of
> people, but it doesn't offer any guarantees because it's always possible
> that $attacker manages to hack his way into access to a superuser role.

I mean, you can hypothesize that any sort of restriction can be
bypassed, regardless of how they're implemented. I don't think this is
a valid way of discriminating among possible solutions.

> The main flaw I'm aware of in that argument is that it used to be possible
> for superusers to create C-language pg_proc entries pointing at random C
> entry point symbols, eg open(2) or write(2), and then invoke those
> functions from SQL --- maybe with only restricted possibilities for the
> arguments, but you just need to find one combination that works.
> When we got rid of v0 function call support, that became at least far
> more difficult to exploit, but I'm not sure if it's entirely impossible.
> A component of this exercise would need to be making sure that that's
> bulletproof, ie you can't make a usable pg_proc entry that points at
> something that wasn't meant to be a SQL-callable function.

It's not just a question of whether it was meant to be SQL-callable --
it's also a question of what arguments it was expecting to be called
with. At the very least, you can cause the server to core dump if you
pass something that isn't a valid pointer to a function that is
expecting a pointer, which is something a CSP very likely does not
want a customer to be able to do. I think, however, that there's every
possibility that you can create more havoc than that. You can
basically call a function that's expecting a pointer with a pointer to
anything you can find or guess the memory address of. Maybe that's not
enough control to cause anything worse than a server crash, but I sure
wouldn't bet on it. There's a lot of functions floating around, and if
none of them can be tricked into doing filesystem access today, well
someone might add a new one tomorrow.

--
Robert Haas
EDB: http://www.enterprisedb.com