Re: vulnerability/SSL

From: Marco Colombo <pgsql(at)esiway(dot)net>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: vulnerability/SSL
Date: 2005-06-09 14:49:27
Message-ID: 1118328567.12004.192.camel@Frodo.esi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 2005-06-09 at 15:53 +0200, Magnus Hagander wrote:
[...]
> > > I guess we could read in the password ourselves and drop it in our
> > > shared memory segment to pass to subprocesses - though that
> > means they
> > > can get to the password easier as well. Assuming OpenSSL
> > has the APIs
> > > for that, I haven't checked that. I'm unconvinced it makes
> > enough of a
> > > difference to be worthwhile, though.
> > > (BTW, am I correct in reading this as a problem that only
> > appears on
> > > win32, because of the exec nature of the backend, right? Or does it
> > > show up on Unix as well?)
> >
> > Is the Unix version much different? I think the postmaster
> > just forks and execs the backends.
>
> It forks. It doesn't exec. As such, it inherits all the memory from the
> postmaster.

Oh, I need to check it out then. I thought the 'postmaster' executable
forks and execs 'postgres', and then they share mem via shmat(2). But
now I see they are the same executable - weird how I've never noticed
that before.

> > But, aren't connections
> > handled by the postmaster? All the SSL thing should happen
> > before the fork I think. Is the Windows model different? Do
> > backends handle SSL negotiation?
>
> On win32 we do fork() + exec(), and the OpenSSL library requires a new
> initialization, including reading the key. I should say I'm speaking
> from memory of stuff I looked at a longt ime ago, though - it could
> probably do with someone looking throuhg exactly how it is now ;-)
>
> IIRC, the problem is that the openssl structs contain function pointers,
> which are not guaranteed to point to the same thing in the child.

Ouch, I see the problem. You do need to pass the unencrypted key around
then, assuming openssl supports such a thing. Now I also see it's
useless to setup the openssl context only to destroy it with exec. So it
has to be the child to handle it.

.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo(at)ESI(dot)it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-06-09 14:49:34 Re: [HACKERS] Strange transaction-id behaviour? (was Re: Two updates problem)
Previous Message GIROIRE, Nicolas (COFRAMI) 2005-06-09 14:30:10 "returning" in postgresql request