8 ms·

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 a

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu...
      - deleted 7y ago
        [deleted]
    - Twisell 7y ago
      And it is disabled by default from my understanding.
    - derefr 7y ago
      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 of the cluster) should have the privileges required to `COPY FROM ... PROGRAM` anyway. (They certainly won't on any managed environment like RDS.) As Raymond Chen says: if you can `COPY FROM ... PROGRAM`, you're already on the other side of the airtight hatchway. --- Admittedly, though, it'd be nice if `COPY FROM ... PROGRAM` was made into something that didn't equate to superuser privileges. I think that's totally possible. The simplest first step would be to ship with Postgres a setuid "shim launcher" binary, owned by the OS user `nobody` in the `postgres` group, with permissions 070 (i.e. only Postgres can run it.) Postgres could then just run all its `COPY FROM ... PROGRAM` command lines by fork+exec'ing this binary. A simple sandbox, but usually pretty effective. (Being `nobody` isn't a perfect sandbox; you would need to trust someone with the privilege to execute `COPY FROM ... PROGRAM` statements about as much as you'd trust them with their own entirely-unprivileged shell account on the host instance. But—as the type of user who you'd give this privilege [e.g. users who can do ETL things to your DB] would already be able to thrash most of the same resources through Postgres that they could thrash with an unprivileged shell account, I don't see there being any extra risk in granting this privilege to such users, IMHO. They can write GBs of data to /tmp as `nobody`? Well, they can create GBs-wide temporary tables in Postgres. Etc.) A cleaner, longer-term solution, in my mind, would be to actually get Postgres to take advantage of the way POSIX specifies "one user attempting to run a command as another user" privileges: sudoers(5). Just a few changes would be necessary: 1. Postgres user roles would need to maintain, as a property, a mapping to an OS user of the host instance (either manually, or as a session property discovered from whatever AAA system the user authenticated through when connecting, e.g. LDAP or PAM.) 2. Postgres would execute `COPY FROM ... PROGRAM` statements by attempting to run the command line under the appropriate mapped OS user for the connected session, using sudo(1). 3. Postgres would expect the sysadmin to place entries in /etc/sudoers.d/, enabling its OS user to sudo(1) as specific other OS users for specific commands. It would gracefully handle failure-to-sudo(1) as a failure of the statement. 4. Installing Postgres would add at least one sudoers(5) entry, allowing the OS `postgres` user to execute any command as the OS `nobody` user. Postgres would target the `nobody` user for all `COPY FROM ... PROGRAM` statements by default†, unless you explicitly executed a `COPY FROM ... PROGRAM (... AS HOST USER)` statement. It really should be up to OS security policy, not application software, to decide whether one OS user (e.g. `postgres`) is allowed to execute a given command line as another given OS user. sudoers(5) is the POSIX way‡ to declare such OS-level policy. Postgres just needs to take advantage of the OS—to communicate to the OS which OS user its commands should be interpreted as being on behalf of. † Well, the default OS user would have to be configurable, to allow backward compatibility with existing ETL pipelines that expect `COPY FROM ... PROGRAM` to execute as the OS `postgres` user. Just have a global config param `postgres_copy_subcommand_default_os_user`, default it to "postgres" if it's unset (as it would be in existing installs), and update the postgresql.conf template for new installs to set it to "nobody". ‡ I'm not sure how you'd do this on non-POSIX OSes like Windows. I know Windows has `runas`, but that's equivalent to su(1), not sudo(1); it doesn't have policy-based non-password-prompting elevation capabilities. Anyone know what you'd do here? How does e.g. Docker on Windows run containers with specific user privileges?
  - veryworried 7y ago
    There is no rational, people who simply don't understand or use a certain feature are more likely to write it off as a bad or useless feature. Pay them no mind. COPY TO/FROM PROGRAM has been valuable for our data warehousing operations.
  - codedokode 7y ago
    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.
    - jakobegger 7y ago
      How about not giving people superuser privileges instead of asking for useful features to be dropped?
    - minitech 7y ago
      It’s not a remote shell protocol, though… it runs local programs.
      - pgaddict 7y ago
        Yeah, and it's super-useful in some cases. Say, passing data directly to gzip (or reading it from it).
sctb 7y ago
Thanks, we've updated the link here from https://meterpreter.org/postgresql-announces-to-deny-cve-2019-9193/ https://meterpreter.org/postgresql-announces-to-deny-cve-201....

ajross 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu...
    - deleted 7y ago
      [deleted]
  - Twisell 7y ago
    And it is disabled by default from my understanding.
  - derefr 7y ago
    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 of the cluster) should have the privileges required to `COPY FROM ... PROGRAM` anyway. (They certainly won't on any managed environment like RDS.) As Raymond Chen says: if you can `COPY FROM ... PROGRAM`, you're already on the other side of the airtight hatchway. --- Admittedly, though, it'd be nice if `COPY FROM ... PROGRAM` was made into something that didn't equate to superuser privileges. I think that's totally possible. The simplest first step would be to ship with Postgres a setuid "shim launcher" binary, owned by the OS user `nobody` in the `postgres` group, with permissions 070 (i.e. only Postgres can run it.) Postgres could then just run all its `COPY FROM ... PROGRAM` command lines by fork+exec'ing this binary. A simple sandbox, but usually pretty effective. (Being `nobody` isn't a perfect sandbox; you would need to trust someone with the privilege to execute `COPY FROM ... PROGRAM` statements about as much as you'd trust them with their own entirely-unprivileged shell account on the host instance. But—as the type of user who you'd give this privilege [e.g. users who can do ETL things to your DB] would already be able to thrash most of the same resources through Postgres that they could thrash with an unprivileged shell account, I don't see there being any extra risk in granting this privilege to such users, IMHO. They can write GBs of data to /tmp as `nobody`? Well, they can create GBs-wide temporary tables in Postgres. Etc.) A cleaner, longer-term solution, in my mind, would be to actually get Postgres to take advantage of the way POSIX specifies "one user attempting to run a command as another user" privileges: sudoers(5). Just a few changes would be necessary: 1. Postgres user roles would need to maintain, as a property, a mapping to an OS user of the host instance (either manually, or as a session property discovered from whatever AAA system the user authenticated through when connecting, e.g. LDAP or PAM.) 2. Postgres would execute `COPY FROM ... PROGRAM` statements by attempting to run the command line under the appropriate mapped OS user for the connected session, using sudo(1). 3. Postgres would expect the sysadmin to place entries in /etc/sudoers.d/, enabling its OS user to sudo(1) as specific other OS users for specific commands. It would gracefully handle failure-to-sudo(1) as a failure of the statement. 4. Installing Postgres would add at least one sudoers(5) entry, allowing the OS `postgres` user to execute any command as the OS `nobody` user. Postgres would target the `nobody` user for all `COPY FROM ... PROGRAM` statements by default†, unless you explicitly executed a `COPY FROM ... PROGRAM (... AS HOST USER)` statement. It really should be up to OS security policy, not application software, to decide whether one OS user (e.g. `postgres`) is allowed to execute a given command line as another given OS user. sudoers(5) is the POSIX way‡ to declare such OS-level policy. Postgres just needs to take advantage of the OS—to communicate to the OS which OS user its commands should be interpreted as being on behalf of. † Well, the default OS user would have to be configurable, to allow backward compatibility with existing ETL pipelines that expect `COPY FROM ... PROGRAM` to execute as the OS `postgres` user. Just have a global config param `postgres_copy_subcommand_default_os_user`, default it to "postgres" if it's unset (as it would be in existing installs), and update the postgresql.conf template for new installs to set it to "nobody". ‡ I'm not sure how you'd do this on non-POSIX OSes like Windows. I know Windows has `runas`, but that's equivalent to su(1), not sudo(1); it doesn't have policy-based non-password-prompting elevation capabilities. Anyone know what you'd do here? How does e.g. Docker on Windows run containers with specific user privileges?
- veryworried 7y ago
  There is no rational, people who simply don't understand or use a certain feature are more likely to write it off as a bad or useless feature. Pay them no mind. COPY TO/FROM PROGRAM has been valuable for our data warehousing operations.
- codedokode 7y ago
  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.
  - jakobegger 7y ago
    How about not giving people superuser privileges instead of asking for useful features to be dropped?
  - minitech 7y ago
    It’s not a remote shell protocol, though… it runs local programs.
    - pgaddict 7y ago
      Yeah, and it's super-useful in some cases. Say, passing data directly to gzip (or reading it from it).

sctb 7y ago

Thanks, we've updated the link here from https://meterpreter.org/postgresql-announces-to-deny-cve-2019-9193/ https://meterpreter.org/postgresql-announces-to-deny-cve-201....