
CVE-2019-9193: Not a Security Vulnerability - proboscis
https://www.postgresql.org/about/news/1935/
======
Derek_MK
I kinda went back and forth on this. The initial comments here made me think
that this was basically the reporter saying "person with su can do su things".

Then I looked at the PostgreSQL statement, which said that the report claimed
that users with a read-access role could do the su things, and they said that
the claim was not true.

And _then_ I looked at the actual report, which stated that you have to have
the read-access role, _and_ the execute-access role (or su).

So, what it seems like is that both parties didn't represent the actual
situation well, but the root (ha) issue was that it was reported as "IF YOU
HAVE READ ACCESS (and execute access) THEN YOU CAN EXECUTE ARBITRARY
CODE!!11!!!"

~~~
Hello71
allegedly, the reporters only edited their article after publication and
widespread criticism.

~~~
Derek_MK
Oh, if that's the case, then the reporters were just wrong about how the
software worked. If it only required the read access, then that would be a
legitimate vulnerability.

------
michaelhoffman
"It rather involved being on the other side of this airtight hatchway: Writing
to the application directory" (2012)

Raymond Chen on "security vulnerabilities" that depend on already having
superuser status.

[https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=58...](https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=5893)

Looks like Microsoft messed up the line breaks on switching to a new blog
platform.

~~~
ethbro
_> Looks like Microsoft messed up the line breaks on switching to a new blog
platform._

One could argue Microsoft has been messing up line breaks since 1981.

------
lloydde
Direct link to “CVE-2019-9193: Not a Security Vulnerability”
[https://www.postgresql.org/about/news/1935/](https://www.postgresql.org/about/news/1935/)

Which is also currently a banner at postgresql.org titled “4th April 2019:
CVE-2019-9193: Not a Security Vulnerability”

~~~
ajross
Per the links in the NVC CVE page, the reporter seems to have retracted it
too.

It was a bad report. To be fair, it's also a bad feature. But bad features
working as intended shouldn't be "vulnerabilities".

~~~
michelpp
COPY TO/FROM PROGRAM is not a bad feature. It is in fact an amazing and
wonderful thing that makes ETL with Postgres much more powerful. Almost all
language runtimes can spawn subprocesses. What is your rational for declaring
it "bad" with no explanation?

~~~
ajross
Sigh. We literally went through all this with SQL Server's xp_cmdshell feature
already. All the same flame wars apply, I don't have the energy to argue it
all again.

The community consensus was the MS should make this thing disabled by default,
and they did. Postgres should too.

~~~
michelpp
xp_cmdshell can be re-enabled, from SQL, with the same kind of privileged
account postgres requires to run COPY...PROGRAM:

[https://docs.microsoft.com/en-us/sql/database-
engine/configu...](https://docs.microsoft.com/en-us/sql/database-
engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-
server-2017)

------
Tostino
After reading the discussion, that seems like the entirely right call.

The security researchers did not seem too concerned with the feedback they got
from the community prior to releasing this CVE.

~~~
mutagen
Yeah, I discovered a flaw in SSH the other day, if my account on the remote
server Is listed in the sudoers file I can escalate to root priviliges, as
soon as I create a snazzy logo I'm going to get myself a CVE.

Seriously though, security research is starting to drift into bizarro land,
security contacts at companies are inundated with port-scans asking for bug
bounties because there's an open port and now people are registering CVEs on
expected and documented behavior.

~~~
userbinator
_security research is starting to drift into bizarro land_

Remember that these people are essentially trying to earn a living by finding
vulnerabilities, so it's no surprise that they'll try to spin _anything_ as
one, regardless of any other considerations.

I've used the term "security vultures" before in reference to such things.
It's unfortunate that a lot of companies misunderstand or obey their requests,
and in the process useful features are destroyed and software becomes more
user-hostile.

~~~
cestith
Perhaps I'm naive, but I think it is surprising anyone wants to be taken
seriously as a researcher in any field and proceeds to publish information
that in on its face and with no effort provably false.

~~~
ncmncm
Throw enough at the wall, some of it might stick.

People who have no reputation tend to worry less about their reputation.

~~~
cestith
I can't reasonably say that doesn't happen. Obviously it does. It may even be
a useful tactic in the very short term. It however does not appear to be a
very useful decision for a long term career or hobby.

------
jpeter
The researcher should watch this video
[https://www.youtube.com/watch?v=866olNIzbrk](https://www.youtube.com/watch?v=866olNIzbrk)

~~~
michelpp
Thank you! Didn't know about that silly Python non-CVE, a great example of the
same shallow thinking that created this bogus CVE.

------
kerng
Sounds the same as xp_cmdshell scenarios in past. Although worth pointing out
Microsoft there did lock down things further to even disable the feature and
it has to be turned on explicitly.

That's possibly an improvement Postgress can do to avoid easy pivoting. Its
what a less defensive security reply would include, because if hackers use it
to pivot it might not look good down the road.

But from a pure argument standpoint Postgres is correct, it's more of a
defense in depth strategy.

~~~
michelpp
Quoting Andreas Freund from the mailing list:

""" Btw, the xp_cmdshell thing the author references several times? It can be
enabled via tsql if you have a privileged account.

[https://docs.microsoft.com/en-us/sql/database-
engine/configu...](https://docs.microsoft.com/en-us/sql/database-
engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-
server-2017)

and it allows to execute shell code (as a specified user) even when not a
sysadmin: [https://docs.microsoft.com/en-us/sql/relational-
databases/sy...](https://docs.microsoft.com/en-us/sql/relational-
databases/system-stored-procedures/xp-cmdshell-transact-sql?view=sql-
server-2017#xp_cmdshell-proxy-account) """

so no MS didn't really "lock down" the feature.

~~~
hobs
If you make a proxy account, AS AN ADMIN. I have personally walked dozens of
DBAs through making said proxy account as it was non-trivial to accomplish.

Please stop repeating this FUD.

~~~
michelpp
You cannot run COPY...PROGRAM without a permission that can only be granted to
you by a superuser and which is not granted by default. I'm failing to see the
distinction.

Postgres is just a process that happens to do a lot of I/O. It's no different
than any other Unix process: it can spawn children, it can dynamically load
libraries on request. It protects these powerful tools with permissions, which
is the sane and correct approach taken by many, many other languages and
frameworks, all just unix processes, all just trying to get shit done.

~~~
hopler
sudo exists, even though an admin could just log in as root all the time,
because it's safer to keep your gun unloaded when you aren't planning to use
it immediately. Keeping your gun loaded isn't a security flaw, but it is
dangerous.

~~~
michelpp
sudo requires being granted permission. If you have it, you can run code as
root. It is not granted by default.

COPY...PROGRAM requires being granted permission. If you you have it you can
run code as the postgres user. It is not granted by default.

------
StreamBright
Is this the same as somebody executes sudo bash and observes that he got root
prompt?

------
based2
[http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2019-9193](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2019-9193)

------
johannkokos
This is the original blog post by the author who filed the cve.
[https://www.trustwave.com/en-
us/resources/blogs/spiderlabs-b...](https://www.trustwave.com/en-
us/resources/blogs/spiderlabs-blog/authenticated-arbitrary-command-execution-
on-postgresql-9-3/)

------
bdarnell
I think this is an argument for not giving root/superuser all possible
permissions by default. It's OK that granting the `pg_execute_server_program`
permission gives access to this feature, but it should still be something you
have to opt in to, instead of making database superuser equivalent to the host
user that the database runs as.

For comparison, in CockroachDB (disclosure: I'm a co-founder of Cockroach
Labs), we don't have any features that let you execute server programs, but we
do have something analogous to `pg_{read,write}_server_files` via the BACKUP,
RESTORE, and IMPORT commands. In order to use these commands with a target on
the server's filesystem, though, the database `admin` role isn't enough. The
server also needs to be started with the `--external-io-dir` flag (and file
operations will be limited to that directory). This gives an extra layer of
opt-in before filesystem operations are allowed.

~~~
SpicyLemonZest
It's an argument for sure. But there's a significant maintenance cost to every
security boundary you impose, especially when it's as counter-intuitive as
"root may not do suchandsuch".

------
kijin
While the behavior described might be by design, I'm skeptical of any database
query that involves accessing user-specified local files or executing system
commands. (MySQL also has the infamous LOAD DATA INFILE query.) They look like
band-aids designed for people who can't be bothered to import/export their
data using standard shell commands, scripts, pipes, and database-specific
dump/restore tools. These kinds of features should be disabled by default.

~~~
aasasd
> _They look like band-aids designed for people who can 't be bothered_

Also those schmucks who like data to be loaded way way faster.

~~~
saltcured
What is way way faster here? Are you only comparing COPY versus individual row
INSERT statements?

I prefer using COPY ... STDIN/STDOUT. AFAICT, you get the same bulk table
access performance. But, the external file access is via the client,
separating DB rights and filesystem rights. When appropriate, you can also SSH
to the server and invoke psql as a regular user there, manipulating files
under that user's control on the server filesystem.

The psql command also provides built-in \COPY command to make it easy to
combine several such commands into one transaction in a SQL script. It looks a
little like the SQL COPY command, but accesses files on the client side and
executes equivalent COPY ... STDIN/STDOUT statements on the server.

In Python, you can use the copy_expert() method with psycopg2 connections to
access the COPY ... STDIN/STDOUT feature for similar bulk ETL. However, Python
will become the performance bottleneck if you try to do any real row-level
processing rather than just relaying byte buffers to/from the filesystem.

~~~
pgaddict
You're missing the point.

    
    
        COPY TO/FROM PROGRAM is useful e.g. when you already have the data locally on the server (same filesystem, ...).
    
        COPY FROM STDIN/STDOUT are useful when the data are on some other system (say, on a different server, etc).
    

Of course, you might write a script that reads the local data and loads it
through a regular client, i.e. something like

    
    
        COPY t FROM PROGRAM 'gunzip -c /path/to/compressed/data.gz';
    

might be rewritten like

    
    
        gunzip -c /path/to/compressed/data.gz | psql db -c 'copy t from stdin';
    

but well, that requires some access to the server and ability to execute
commands on it (although not as a postgres superuser).

Ultimately it's a tradeoff - don't trust your users? Don't give them superuser
access, don't grant them the role. It's possible to restrict that in other
ways (e.g. security-definer functions + extra validations).

~~~
saltcured
I'm not missing the point. I was responding to a comment about performance. In
my experience, COPY ... STDIN/STDOUT are just as fast the other COPY, given
the same filesystems. I think many people are unnecessarily conflating bulk
COPY advantages with superuser rights here.

We use it all the time via psql authenticated with unix domain socket. In most
situations where there are users performing ETL and such, I think it is much
safer to have them using a non-superuser role and manipulating files in their
own user or group space. You can have all the performance of a bulk COPY
without the risk of mangling the service-related files under the postgres
user. I think it is better to give regular SSH accounts to these users than to
give them elevated DB privileges so they can use server-side file or program
COPY.

Also, with psql you can do \copy ... program within your SQL script. It has
all the expressive power of a server-side copy but actually runs commands
under the invoking user instead of the postgres service.

------
mixologist
If this is CVE, what is Docker then? :)

Anyone with privileges to run docker image is basically root on your host.

~~~
imtringued
This is why you should never add your user to the docker group. Just use `sudo
docker` or put your docker commands in a script that can only be edited by
root and execute the script via sudo with NOPASSWD.

~~~
ahachete
Much better: replace Docker with [https://podman.io/](https://podman.io/),
which runs with user privileges, no root.

------
ZeroCool2u
TL;DR Don't grant root to strangers, because they might do something rude with
your db.

------
codedokode
Running a program remotely from a database client is an awful idea. DB client
is not a secure remote shell; if you need a shell access, use ssh. Postgres is
making a mistake, developers will run postgres as root (because it is the
easiest way to solve problem with permissions), they will write apps that
connect to postgres server as root and run SQL queries made from user input.

~~~
gmueckl
You can't run Postgres as root without patching it first. It really wants to
run as a low privilege user.

