Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 22.10.2013 15:41, Honza Horak wrote:
>> In order to enlarge possible data domain of the seed we can include sec
>> count as well and shift some xor-ed variables to use the whole range or
>> unsigned int. The attached patch uses a way that gave me much better
>> results (collision found approx. after a hundred thousands of values):
>>
>> - srandom((unsigned int) (MyProcPid ^ usecs));
>> + srandom((unsigned int) (MyProcPid ^ (usecs << 12) ^ secs));
> Seems reasonable, committed. Thanks!
While that change seems reasonable as far as it goes, we could do more.
In particular, including the current seconds count only provides a few
extra bits of variability over the short term, so I don't think this has
really moved the ball very far downfield.
I had been wondering about the idea of taking the next random value in the
postmaster's sequence and xor'ing that into the seed, along with the
components suggested above. This should add close to 32 bits worth of
hard-to-predict randomness into each seed.
There are a couple of arguments to be made against this idea:
1. To work properly, the random() call would have to be made before the
fork(), with the value being passed down to the child process. This is
no big deal in the fork() case but would add a little bit of complexity
in EXEC_BACKEND mode. Still, we pass a lot of stuff to the child already,
and one more int isn't very much.
2. In principle, an attacker with free access to the state of a child
process might be able to infer the postmaster's random() value that had
been passed down. I'm not sure about the potential security consequences
of that, but in a system with a very bad implementation of random() it
seems possible that the attacker might be able to guess nearby values
in the postmaster's random() sequence, which would lead to being able to
guess the salt values used in subsequently-launched children's password
challenges. OTOH, even if all this was really feasible, what does that
buy for the attacker?
regards, tom lane
