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

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: VACUUM FULL/CLUSTER doesn't update pg_class's pg_class.relfrozenxid
Следующее
От: Andres Freund
Дата:
Сообщение: Re: heapgetpage() and ->takenDuringRecovery