On 2017-04-15, <bytevolc...@safe-mail.net> <bytevolc...@safe-mail.net> wrote:
> OpenBSD still randomizes PIDs, but I don't see the point these days:
> https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961
'Protect against PID prediction vulnerabilities affecting mostly
software which use the PID value to generate temporary file names.
This was a common concern at that time, but today I think it would
be quite rare to encounter production-level software still not
using a proper method.'
Between some of the less common software that is still used, and various
sysadmin shell scripts people might have around, I don't think it's all
that unlikely.
'A PID is not designed to seed a random number generator or generate
session ID or cookies.'
Correct that it's not designed for that. But we looked into this a lot
when introducing srand_determinstic(3). It's still *very* common to seed
based on pid, time, or a combination of the two, either as the main
method, or as a fallback if /dev/urandom can't be opened (as may happen
as a result of FD exhaustion [possibly attacker-triggered] or in a chroot
jail).
t = (unsigned char)getpid();
while (i < size) {
do {
buf[i] = ((unsigned char)rand()) ^ t;
} while (buf[i] == 0);
t = buf[i++] << 1;
The srand_deterministic change makes this less of a problem on OpenBSD
for programs using rand(), but sometimes programs have their own PRNG
and aren't seeding it nicely, any extra protection we can give these
seems useful.
'As a general preventive measure, "If something can be random, make it
random."'
With OpenBSD's random subsystem it is intentional to have many
consumers. See http://www.openbsd.org/papers/hackfest2014-arc4random/.
The idea is to slice up the chacha20 (formerly arc4) stream as much
as possible.
