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(at)gmail(dot)com> writes:
> > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah(at)leadboat(dot)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