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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Securing "make check" (CVE-2014-0067)
Date: 2014-03-03 07:00:23
Message-ID: 16143.1393830023@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-03-03 07:50:21 Re: Securing "make check" (CVE-2014-0067)
Previous Message Ronan Dunklau 2014-03-03 06:48:04 Re: Triggers on foreign tables