Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2019-9193: Not a Security Vulnerability

postgresql.org

Post reply on HN
Print view View original

71–80 of 84 posts

Re: CVE-2019-9193: Not a Security Vulnerability

#71

Post by Derek_MK »

Hello71 wrote: post #30
Derek_MK wrote: post #23

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-…

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

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.

Re: CVE-2019-9193: Not a Security Vulnerability

#72

Post by derefr »

tsimionescu wrote: post #69
derefr wrote: post #56

Earlier quoted context omitted.

I'm unclear on what having the feature "disabled by default" would really help. There are two primary deployment use-cases of a DBMS: - on a dev box (or your own workstation) - in production In the first case, the same person/people using the DBMS can just `sudo su postgres -` to do whatever Postgres would be doing for them. In the second case, nobody who's a pure user of the database (i.e. anyone who's not the DBA o…

There is a misunderstanding here: the 'COPY FROM ... PROGRAM' command, according to both the vulnerability and the postgres article, only allows running commands as the OS user running the server process, NOT a superuser (also, Postgres won't start if you try to start it as root). The confusion probably comes from the notion of a 'database superuser' - the point is that any DB user with enough privileges to run COPY…

No, I'm not misunderstanding. When I said "equates to superuser privileges", I meant the privileges that the database superuser has. We're speaking in the context of DBMS permissions here—in DBMS docs, "user" always means "database user" (and "superuser" always means "database superuser"); and if you want to mean "OS user", you have to explicitly spell that out (as I did each time I meant that.)

But, as well, I think it's important to point out that, on a system that's dedicated to being a database instance, there's really not that much difference between being able to execute arbitrary commands as the OS superuser, and being able to execute arbitrary commands as the OS user that the DBMS runs as. If you can run commands as the OS `postgres` user, you can, for example:

- delete the cluster (even if your DBMS user can't do that)

- read all the Postgres configuration files, including any secrets loaded from such files

- change other [DBMS!] users' passwords

- configure a new authentication method that sends credentials to an arbitrary third-party system (e.g. an LDAP server you control), turning the database instance into a login-credential harvester

Etc.

Yes, the OS `postgres` user isn't the OS superuser; but that is kind of meaningless if the box is essentially just a substrate for running Postgres on.

Re: CVE-2019-9193: Not a Security Vulnerability

#73

Post by pgaddict »

minitech wrote: post #53
codedokode wrote: post #38

Earlier quoted context omitted.

There is ssh which is secure and encrypted. There is no need to invent new unencrypted and insecure remote shell protocol thus increasing attack surface without getting any noticeable benefits.

It’s not a remote shell protocol, though… it runs local programs.

Yeah, and it's super-useful in some cases. Say, passing data directly to gzip (or reading it from it).

Re: CVE-2019-9193: Not a Security Vulnerability

#74

Post by pgaddict »

saltcured wrote: post #57
aasasd wrote: post #32

Earlier quoted context omitted.

> 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.

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…

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).

Re: CVE-2019-9193: Not a Security Vulnerability

#75

Post by vbezhenar »

Derek_MK wrote: post #70
sslayer wrote: post #52

Earlier quoted context omitted.

So, is there a difference between and actual vulnerability in the code, and a vulnerability due to unintended misconfiguration? That's what this sounds like (or am I wrong?), And if so, plenty of software can be misconfigured in an unsecured state.

The point is that, if an admin misconfigures the software, then the vulnerability is on them, and the software itself doesn't need to change (minus arguments of usability but that's a whole other can of worms).

How do you configure execute rights securely? I’ve skimmed over the docs. Execute right allows user to execute programs under postgres Unix account, so getting control of postgres database account should be possible. Basically execute right = superuser. Why even have a separate right for that? Just assign superuser role.

Re: CVE-2019-9193: Not a Security Vulnerability

#76

Post by ncmncm »

cestith wrote: post #64
userbinator wrote: post #58

Earlier quoted context omitted.

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 p…

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.

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

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

Re: CVE-2019-9193: Not a Security Vulnerability

#77

Post by anarazel »

hobs wrote: post #41
michelpp wrote: post #20

Earlier quoted context omitted.

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... 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... """ so no MS didn't really "lock…

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.

The quote's from me, and even in the quoted part explicitly says "if you have a privileged account". And an admin user you just need to enable it, and it works without even the proxy user configured.

Please explain what's FUD about that?

The postgres equivalent this post is about a feature that's only granted to superusers (or in recent version user that have explicitly been granted rights that are equivalent to superuser and documented as such - namely the right to directly write into any database file...).

Re: CVE-2019-9193: Not a Security Vulnerability

#78

Post by anarazel »

vbezhenar wrote: post #75
Derek_MK wrote: post #70

Earlier quoted context omitted.

The point is that, if an admin misconfigures the software, then the vulnerability is on them, and the software itself doesn't need to change (minus arguments of usability but that's a whole other can of worms).

How do you configure execute rights securely? I’ve skimmed over the docs. Execute right allows user to execute programs under postgres Unix account, so getting control of postgres database account should be possible. Basically execute right = superuser. Why even have a separate right for that? Just assign superuser role.

Because enough users asked for them - there was a long debate about that. It's less to prevent those users from intentionally gaining superuser, and more to make it a bit harder to unintentionally have trusted users shoot themselves into the foot. The docs say at https://www.postgresql.org/docs/current/default-roles.html#D...

"The pg_read_server_files, pg_write_server_files and pg_execute_server_program roles are intended to allow administrators to have trusted, but non-superuser, roles which are able to access files and run programs on the database server as the user the database runs as. As these roles are able to access any file on the server file system, they bypass all database-level permission checks when accessing files directly and they could be used to gain superuser-level access, therefore care should be taken when granting these roles to users."

It's not uncommon to grant users the right to change their roles into specific ones with more privileges. For business critical installations the DBA's role will e.g. often not have superuser rights itself, but the permission to do 'SET ROLE some_superuser_role; some_dangerous_command; RESET ROLE;'. And then it can be useful to allow a user to go to different rules. E.g. one that look at files for low-level debugging, but not drop tables, to prevent accidents.

Edit: #1 fight formatting, #2 explain SET ROLE practice.

Re: CVE-2019-9193: Not a Security Vulnerability

#79

Post by cestith »

ncmncm wrote: post #76
cestith wrote: post #64

Earlier quoted context omitted.

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.

Throw enough at the wall, some of it might stick. People who have no reputation tend to worry less about their reputation.

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.

Re: CVE-2019-9193: Not a Security Vulnerability

#80

Post by tsimionescu »

derefr wrote: post #72
tsimionescu wrote: post #69

Earlier quoted context omitted.

There is a misunderstanding here: the 'COPY FROM ... PROGRAM' command, according to both the vulnerability and the postgres article, only allows running commands as the OS user running the server process, NOT a superuser (also, Postgres won't start if you try to start it as root). The confusion probably comes from the notion of a 'database superuser' - the point is that any DB user with enough privileges to run COPY…

No, I'm not misunderstanding. When I said "equates to superuser privileges", I meant the privileges that the database superuser has. We're speaking in the context of DBMS permissions here—in DBMS docs, "user" always means "database user" (and "superuser" always means "database superuser"); and if you want to mean "OS user", you have to explicitly spell that out (as I did each time I meant that.) But, as well, I think…

Well, I was right, there was a misunderstanding - on my part, obviously.

Basically, you were discussing a mechanism for allowing non-admin DB users to safely run COPY FROM... PROGRAM?

Post reply on HN