On Sun, 16 Apr 2017 12:01:48 +0000 (UTC) Stuart Henderson <s...@spacehopper.org> wrote:
> 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). Are there any applications out there that explicitly require the PRNG to be deterministic? It doesn't make sense to have that kind of thing there for minute corner cases, such as if someone decides it's a brilliant idea to use the contents of a deterministic PRNG as a hash. > 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. Surely looking up a pointer to some have O(n) or O(log n) worst case, since it has to traverse the list? Quite close for a list full of random PIDs. Surely this creates a bit more complacency, "Oh the OS generates random PIDs anyway, let's use that to seed our RNG." Hopefully such practices is abolished in favour of more robust methods. Not suggesting the random PIDs are a bad thing, but I am curious as to how much extra code and cost is needed to implement this over a "sequential" PID that's just an index to an array. > > '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. > I do like the way this is implemented, and it is well integrated within the system too. Shame the function was called arc4random() and not sorandom() or something. Little too late to change it now though I guess.
