cendres at videotron.ca
Wed Mar 31 19:26:34 PST 2004
On March 31, 2004 02:13 pm, Bennett Todd wrote:
> 2004-03-31T18:12:24 Robert Connolly:
> > It looks to me like the hash of /proc/`pid`/environ changes with every
> > runtime. Its not entropy but it might be fairly unpredictable.
> Huh? That's just the environment.
Yes, you're right.
This is just brainstorm, maybe I've had too much coffee.
Non-crypto quality runtime random number generator for libc.
For when you want a random value for single use.
Take the values from gettimeofday, getpid, and environ. Gettimeofday is
predictable, but knowing the microsecond a function was executed on isn't so
predictable. The pid is not very predictable; its unknown to remote users,
but is known to local users (there is a grsec option to hide pid's, but I'll
assume its not being used). The reason I like environ is because, at least on
modern kernels, its read only by owner. The environ value would be somewhat
key in preventing a local attack because it would be the only real secret
(except for the gettimeofday value). Any one of these values should be enough
to foil a remote attack. The three values can be added together and hashed to
provide programs with a random value at runtime, to do whatever they want
with (ssp can use it).
Granted, this isn't as good as urandom. But this would be a fairly simple/fast
function that provides values that don't repeat, without draining entropy
from the kernel. I assume the pid allocation uses some of the kernels
randomness, but that's the default anyway, and that just helps make sure this
libc function stays random... from one boot to the next it shouldn't repeat
itself because it is using the kernel's random indirectly.
I know its a bit flakey and only works at runtimes, and in fixed quantities.
More information about the hlfs-dev