On Wed, Dec 16, 2020 at 05:30:13PM -0500, Tom Lane wrote: > David Fetter <da...@fetter.org> writes: > > We have \gset to set some parameters, but not ones in the environment, > > so I fixed this with a new analogous command, \gsetenv. > > In view of the security complaints we just had about \gset > (CVE-2020-25696), I cannot fathom why we'd consider adding another > way to cause similar problems.
The RedHat site says, in part: the attacker can execute arbitrary code as the operating system account running psql This is true of literally everything that requires a login shell in order to use. I remember a "virus" my friend Keith McMillan wrote in TeX back in the 1994. You can download the PostScript file detailing the procedure, bearing in mind that PostScript also contains ways to execute arbitrary code if opened: ftp://ftp.cerias.purdue.edu/pub/doc/viruses/KeithMcMillan-PlatformIndependantVirus.ps That one got itself a remote code execution by fiddling with a person's .emacs, and it got Keith a master's degree in CS. I suspect that equally nasty things are possible when it comes to \i and \o in psql. It would be a terrible idea to hobble psql in the attempt to prevent such attacks. > We were fortunate enough to be able to close off the main security > risk of \gset without deleting the feature altogether ... but how > exactly would we distinguish "safe" from "unsafe" environment > variables? It kind of seems like anything that would be worth > setting at all would tend to fall into the "unsafe" category, > because the implications of setting it would be unclear. But *for > certain* we're not taking a patch that allows remotely setting PATH > and things like that. Would you be so kind as to explain what the actual problem is here that not doing this would mitigate? If people run code they haven't seen from a server they don't trust, neither psql nor anything else[1] can protect them from the consequences. Seeing what they're about to run is dead easy in this case because \gsetenv, like \gset and what in my view is the much more dangerous \gexec, is something anyone with the tiniest modicum of caution would run only after testing it with \g. > Besides which, you haven't bothered with even one word of positive > justification. What's the non-hazardous use case? Thanks for asking, and my apologies for not including it. I ran into a situation where we sometimes got a very heavily loaded and also well-protected PostgreSQL server. At times, just getting a shell on it could take a few tries. To mitigate situations like that, I used a method that's a long way from new, abstruse, or secret: have psql open in a long-lasting tmux or screen session. It could both access the database at a time when getting a new connection would be somewhere between difficult and impossible. The bit that's unlikely to be new was when I noticed that it could also shell out and send information off to other places, but only when I put together a pretty baroque procedure that involved using combinations of \gset, \o, and \!. All of the same things \gsetenv could do were doable with those, just less convenient, so I drafted up a patch in the hope that fewer others would find themselves jumping through the hoops I did to get that set up. Separately, I confess to some bafflement at the reasoning behind the CVE you referenced. By the time an attacker has compromised a database server, it's already game over. Code running on the compromised database is capable of doing much nastier things than crashing a client machine, and very likely has access to other high-value targets on its own say-so than said client does. Best, David. [1] search for "gods themselves" here: https://en.wikiquote.org/wiki/Friedrich_Schiller -- 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