Re: \gsetenv

On Sun, Dec 20, 2020 at 01:07:12PM -0500, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > On Sun, Dec 20, 2020 at 02:26:14PM +0100, Fabien COELHO wrote:
> >> SELECT 'Calvin' AS foo \gset
> >> \setenv FOO :foo
> >> \! echo $FOO
> >> Calvin
> 
> > You're the second person who's mentioned this workaround, which goes
> > to a couple of points I tried to make earlier:
> 
> > - This is not by any means a new capability, just a convenience, and
> > - In view of the fact that it's a very old capability, the idea that
> >   it has implications for controlling access or other parts of the
> >   space of threat models is pretty silly.
> 
> This is essentially the same workaround as what we recommend for anyone
> who's unhappy with the fix for CVE-2020-25696: do \gset into a non-special
> variable and then copy to the special variable.  The reason it seems okay
> is that now it is clear that client-side logic intends the special
> variable change to happen.  Thus a compromised server cannot hijack your
> client-side session all by itself.  There's nonzero risk in letting the
> server modify your PROMPT1, PATH, or whatever, but you took the risk
> intentionally (and, presumably, it's necessary to your purposes).
> 
> I tend to agree with you that the compromised-server argument is a little
> bit of a stretch.  Still, we did have an actual user complaining about
> the case for \gset, and it's clear that in at least some scenarios this
> sort of attack could be used to parlay a server compromise into additional
> access.  So we're not likely to undo the CVE-2020-25696 fix, and we're
> equally unlikely to provide an unrestricted way to set environment
> variables directly from the server.
> 
> If we could draw a line between "safe" and "unsafe" environment
> variables, I'd be willing to consider a patch that allows directly
> setting only the former.  But I don't see how to draw that line.
> Most of the point of any such feature would have to be to affect
> the behavior of shell commands subsequently invoked with \! ...
> and we can't know what a given variable would do to those.  So on
> the whole I'm inclined to leave things as-is, where people have to
> do the assignment manually.

I suppose now's not a great time for this from an optics point of
view.  Taking on the entire security theater industry is way out of
scope for the PostgreSQL project.

We have plenty of ways to spawn shells and cause havoc, and we
wouldn't be able to block them all even if we decided to put a bunch
of pretty onerous restrictions on psql at this very late date. We have
\set, backticks, \!, and bunches of things less obvious that could,
even without a compromised server, cause real mischief. I believe that
a more effective way to deal with this reality in a way that helps
users is to put clear warnings in the documentation about the fact
that psql programs are at least as capable as shell programs in that
they are innately capable of doing anything that the psql's system
user is authorized to do.

Would a patch along that line help?

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate