Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Securing "make check" (CVE-2014-0067)
Date
Msg-id 5314846B.3080902@dunslane.net
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: VACUUM FULL/CLUSTER doesn't update pg_class's pg_class.relfrozenxid
Next
From: Andres Freund
Date:
Subject: Re: heapgetpage() and ->takenDuringRecovery