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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 16143.1393830023@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Securing "make check" (CVE-2014-0067)  (Andrew Dunstan <andrew@dunslane.net>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Re: Triggers on foreign tables
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Securing "make check" (CVE-2014-0067)