Live data from Hacker News

CVE-2019-9193: Not a Security Vulnerability

postgresql.org

61–70 of 84 posts

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

#61
post #4

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

it's more of a defense in depth strategy

If you take that to its logical conclusion you end up with completely unusable, user-hostile software that becomes nearly useless.

The fact that everything can be abused, should not be a reason to ban everything either.

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

#62

If this is CVE, what is Docker then? :) Anyone with privileges to run docker image is basically root on your host.

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.

Much better: replace Docker with https://podman.io/, which runs with user privileges, no root.

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

#63
post #4

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

it's more of a defense in depth strategy If you take that to its logical conclusion you end up with completely unusable, user-hostile software that becomes nearly useless. The fact that everything can be abused, should not be a reason to ban everything either.

It's not about banning but secure by default. A feature that a minority of users needs, shouldn't be accessible by default - it's common security principle.

Someone above mentions that the feature/config is actually off by default!

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

#64
post #8

Earlier quoted context omitted.

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

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.

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

#65
post #63

Earlier quoted context omitted.

it's more of a defense in depth strategy If you take that to its logical conclusion you end up with completely unusable, user-hostile software that becomes nearly useless. The fact that everything can be abused, should not be a reason to ban everything either.

It's not about banning but secure by default. A feature that a minority of users needs, shouldn't be accessible by default - it's common security principle. Someone above mentions that the feature/config is actually off by default!

Thank goodness it's not accessible by default.

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

#66
post #8
post #2

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.

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

> asking for bug bounties

Yeah that's just not done. Dutch: kinderen die vragen worden overgeslagen (it rhymes nicely) - kids that ask will be skipped/passed. I.e., if you ask for a reward (or sweets, in a kids' case), you certainly won't get any.

If you reward people that report silly stuff and then ask for money, that would be bizarro land indeed.

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

#67
post #8

Earlier quoted context omitted.

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

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…

Security vulture, nice. I'll steal that one! Am a security dude myself but I hadn't heard that one before; it sounds quite apt.

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

#69
post #56
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.

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 FROM ... PROGRAM can also do anything else in the DB, so they are already considered a DB superuser.

Quote from the article :

> By design, there exists no security boundary between a database superuser and the operating system user the server runs under. As such, by design the PostgreSQL server is not allowed to run as an operating system superuser (e.g. "root").

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

#70
post #52

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

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).
Post reply on HN