Re: WAL file location

Поиск
Список
Период
Сортировка
От Curt Sampson
Тема Re: WAL file location
Дата
Msg-id Pine.NEB.4.44.0207310838420.454-100000@angelic.cynic.net
обсуждение исходный текст
Ответ на Re: WAL file location  (Lamar Owen <lamar.owen@wgcr.org>)
Ответы Re: WAL file location  (Lamar Owen <lamar.owen@wgcr.org>)
Список pgsql-hackers
On Tue, 30 Jul 2002, Lamar Owen wrote:

> On Tuesday 30 July 2002 02:34 pm, Tom Lane wrote:
>
> > Who said anything about poisoning the environment?  My point was that
> > there will be strings in the environment that were put there perfectly
> > legitimately, but could still serve as an attack vehicle.
>
> I said it. In any case, using strings that are in the environment
> requires an untrusted PL, or a C function.

Ah. See, we already have a failure in a security analysis here. This
command:
   CREATE DATABASE foo WITH LOCATION = 'BAR'

uses a string that's in the environment.

> Regardless, if such a hole was exploited the only security risk to
> the system at large is that posed by the postgres user, which, IMHO,
> shouldn't even have write access to its own executables.

So what you're saying is that we should make the opportunity for people
to configure the system in an insecure manner?

Configuration errors by administrators are probably the number one
cause of security breaches, you know.

> I wouldn't mind seeing an example of such an exploit, for
> educational purposes.

I don't have one. But consider a couple of possibilities:

1. The exploit can't exist until someone adds more code to postgres.
So maybe it doesn't exist in 7.3, but will appear in 7.4.

2. The exploit is there, but nobody has figured it out yet. The recent
BIND resolver library vulnerability has been in that code for at least
ten years, but it was only last month that someone figured out that it
was even there, much less how to exploit it.

I've been securing systems since I started an ISP in 1995, and so I've
seen a lot of security vulnerabilities come and go, and I've got a bit
of a feel for what kinds of things are typically exploited. And this one
one just screams, "potential security vulnerability!" to me.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC
 



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

Предыдущее
От: Curt Sampson
Дата:
Сообщение: Re: Why is MySQL more chosen over PostgreSQL?
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: WAL file location