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

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2014-03-03T13:32:27Z
Lists: pgsql-hackers
On 03/03/2014 02:00 AM, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> 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?
> It's theoretically possible, since having broken into the build user's
> account they could modify the already-built-but-not-yet-packaged PG
> executables.
>
> Having said that, though, I concur with the feeling that this probably
> isn't a useful exploit in practice.  On Red Hat's build systems, for
> example, different packages are built in different chroots.  So even if
> a malicious package is being built concurrently, it could not reach the
> postmaster's socket.  A breakin would only be possible for somebody who
> had outside-the-chroots control of the build machine ... in which case
> they can hack pretty much any built package pretty much any way they
> want, without need for anything as fiddly as this.
>
> Other vendors might do things differently, but it still seems likely
> that there would be easier exploits available to anyone who's managed
> to get control on a machine used for package building.
>
> 			


I'm less worried about vendor build systems and more about roll your own 
systems like Gentoo, FreeBSD ports, and Homebrew.

cheers

andrew



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.