On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah@leadboat.com> wrote:
> This should have gone to security@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
> On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
>> When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
>> which asks for random number, thus requiring initialization
>> of randomness pool (RAND_poll). After that all forked backends
>> think pool is already initialized. Thus they proceed with same
>> fixed state they got from postmaster.
>
>> Attached patch makes both gen_random_bytes() and pgp_encrypt()
>> seed pool with output from gettimeofday(), thus getting pool
>> off from fixed state. Basically, this mirrors what SSL_accept()
>> already does.
>
> That adds only 10-20 bits of entropy. Is that enough?
It's enough to get numbers that are not the same.
Whether it's possible to guess next number when you know
that there is only time() and getpid() added to fixed state
(eg. those cleartext bytes in SSL handshake) - i don't know.
In any case, this is how Postgres already operates SSL connections.
> How about instead calling RAND_cleanup() after each backend fork?
Not "instead" - the gettimeofday() makes sense in any case. Considering
that it's immediate problem only for pgcrypto, this patch has higher chance
for appearing in back-branches.
If the _cleanup() makes next RAND_bytes() call RAND_poll() again?
Then yes, it certainly makes sense as core patch.
--
marko