Live data from Hacker News

CVE-2019-9193: Not a Security Vulnerability

postgresql.org

31–40 of 84 posts

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

#31

"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... Looks like Microsoft messed up the line breaks on switching to a new blog platform.

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

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

#32
post #9

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

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

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

#34
post #26

Earlier quoted context omitted.

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?

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.

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

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

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

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

#37

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

No, this feature is like ssh, but without any encryption and authentication.

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

#38
post #10

Earlier quoted context omitted.

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

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?

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.

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

#39
post #26

Earlier quoted context omitted.

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.

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

[deleted]

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

#40

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.

You can't run Postgres as root without patching it first. It really wants to run as a low privilege user.
Post reply on HN