Re: pgcrypto seeding problem when ssl=on

On Sun, Jan 13, 2013 at 07:01:07PM -0500, Noah Misch wrote:
> On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote:
> > Marko Kreen <markokr@gmail.com> writes:
> > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah@leadboat.com> wrote:
> > >> How about instead calling RAND_cleanup() after each backend fork?
> > 
> > > Attached is a patch that adds RAND_cleanup() to fork_process().
> > 
> > I remain unconvinced that this is the best solution.  Anybody else have
> > an opinion?
> 
> I'd describe it as the clearly-secure solution.  The biggest hazard I see is
> the drain on system entropy.  A system having only a blocking /dev/random
> could suddenly find itself entropy-exhausted after installing the minor
> upgrade.  Backends could block waiting for system entropy to accumulate.
> That's not directly a problem on Linux.  However, if other programs on the
> system read from /dev/random, the pressure from PostgreSQL's /dev/urandom
> usage may make those programs wait longer for entropy.
> 
> I'm also comfortable with the security of Marko's original proposal, modulo it
> happening in each backend shortly after fork, not merely in pgcrypto.
> OpenSSL's ssl module uses a similar method, and one of the papers I cited
> describes it.  (If anything, OpenSSL is less cautious.  It uses time(), not
> gettimeofday().)  The performance characteristics of this approach are easier
> to guess: one system call if we use MyProcPid + gettimeofday(), zero if we use
> MyProcPid + MyStartTime.
> 
> You proposed mixing gettimeofday() into the postmaster's entropy pool after
> each fork.  I wouldn't be too concerned if we did it that way, but my quick
> literature review did not turn up any similar ideas.  Given that this is
> strictly more expensive than the previous method, I don't recommend it.
> 
> Overall, I'd recommend mixing in MyProcPid and MyStartTime after each fork.

I neglected to ping this for the last back-branch releases.  May we adopt one
of the above fixes and issue a CVE with the next releases?  Though I've stated
my preference, all three proposals would be major improvements over the
present, quietly-vulnerable state.

Thanks,
nm