Re: Securing "make check" (CVE-2014-0067)

Josh Berkus <josh@agliodbs.com>

From: Josh Berkus <josh@agliodbs.com>
To: pgsql-hackers@postgresql.org
Date: 2014-03-02T22:17:33Z
Lists: pgsql-hackers
On 03/02/2014 12:17 PM, Stephen Frost wrote:
> The issue here is about how much effort to go to in order to secure the
> PostgreSQL system that is started up to do the regression tests.  It's
> already set up to only listen on localhost and will run with only the
> privileges of the user running the tests.  The concern is that another
> user on the same system could gain access to the account which is
> running the 'make check' by connecting over localhost to the PostgreSQL
> instance and being superuser there, which would allow executing
> commands, etc, as that other user (eg: with COPY PIPE).

My $0.02:  Not a lot of effort.

A) Few users run the regression tests at all, because they use packages.

B) Of the users who do self-builds, most do so on secure systems deep
inside the corporate firewall.

C) A related attack requires not only access to the host but good timing
as well, or the ability to leave a booby-trap program on the system.

D) If the host is compromised, the user gains access to the build user
... which should be a regular, unprivilged, shell user.

The only way I can see this being of real use to an attacker is if they
could use this exploit to create a wormed version of PostgresQL on the
target build system.  Is that possible?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Have config_sspi_auth() permit IPv6 localhost connections.

  2. Lock down regression testing temporary clusters on Windows.

  3. Use a separate temporary directory for the Unix-domain socket

  4. Secure Unix-domain sockets of "make check" temporary clusters.