Isaac Morland <isaac.morl...@gmail.com> writes:
> On 8 August 2018 at 09:58, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> When the security team was discussing this issue before, we speculated
>> about ideas like inventing a function trust mechanism, so that attacks
>> based on search path manipulations would fail even if they managed to
>> capture an operator reference. I'd rather go down that path than
>> encourage people to do more schema qualification.
> I must be missing something. Aren't search_path manipulation problems
> avoided by using "SET search_path FROM CURRENT"?
No, not if you have any publicly-writable schemas anywhere in your
search path. The reason this business is so nasty is that our
historical default ("$user, public", with pg_catalog implicitly
searched before that) is actually insecure, even for references
intended to go to pg_catalog. There are too many cases where the
ambiguous-operator resolution rules will allow a reference to be
captured by a similarly-named operator later in the search path.
If you're using a secure search_path to start with, it's possible
that decorating your functions with SET search_path FROM CURRENT
would be helpful, but it's not like that's some kind of magic bullet.
> While I'm asking, does anybody know why this isn't the default, especially
> for SECURITY DEFINER functions?
It might fix some subset of security issues, but I think that changing
the default behavior like that would break a bunch of other use-cases.
It'd be especially surprising for such a thing to apply only to
SECURITY DEFINER functions.
The bigger picture here is that it's really hard to fix this class
of problems by trying to dictate changes in the way people have their
search paths set up. You're much more likely to break working
applications than help anybody. I'm still of the opinion that we're
going to be forced to provide loopholes in what we did to pg_dump
et al in CVE-2018-1058. We've been seeing an increasing number
of complaints about that since the patches came out, and I'm pretty
sure that most of the complainers are totally uninterested in
defending against share-my-database-with-a-hostile-user scenarios.
Why should they have to complicate their lives because of problems
that other people might have?
The advantage of a function trust mechanism is that it'd provide
security against calling functions you didn't intend to without
any visible changes in normal application behavior. The security
team gave up on that approach because it seemed too complicated to
pursue as a secretly-developed security patch, but I still think
it's the right long-term answer.
regards, tom lane
