Re: Facility for detecting insecure object naming - Mailing list pgsql-hackers

> On Aug 8, 2018, at 7:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Isaac Morland <isaac.morland@gmail.com> writes:
>> On 8 August 2018 at 09:58, Tom Lane <tgl@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.

Do you have a WIP patch partially developed for this?  If it is no
longer secret, perhaps the rest of us could take a look?

mark