Re: Securing "make check" (CVE-2014-0067)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2014-03-03T07:00:23Z
Lists: pgsql-hackers
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. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Have config_sspi_auth() permit IPv6 localhost connections.
- 8d9cb0bc4834 9.5.0 cited
-
Lock down regression testing temporary clusters on Windows.
- f6dc6dd5ba54 9.5.0 cited
-
Use a separate temporary directory for the Unix-domain socket
- f545d233ebce 9.5.0 cited
-
Secure Unix-domain sockets of "make check" temporary clusters.
- be76a6d39e28 9.5.0 cited