pwgen's seeding looks insecure

[RW]

On Mon, 8 Jan 2007 10:42:12 -0800
Garrett Cooper <youshi10 at u.washington.edu> wrote:

> On Jan 8, 2007, at 9:53 AM, RW wrote:
> 
> > Someone recently recommended sysutils/pwgen for generating user
> > passwords.  Out of curiosity I had a look at how it works, and I
> > don't like the look of its PRNG initialization:
> >
> >
> > #ifdef RAND48
> >   srand48((time(0)<<9) ^ (getpgrp()<<15) ^ (getpid()) ^ (time(0) 
> > >>11));
> > #else
> >   srand(time(0) ^ (getpgrp() << 8) + getpid());
> > #endif
> >
> >
> > If pwgen is called from an account creation script, time(0) can be
> > inferred from timestamps, e.g. on a home-directory, so that just  
> > leaves
> > getpid() and  getpgrp(). PIDs are allocated sequentially and
> > globally, so getpid() is highly predictable. I don't know much
> > about getpgrp(), but from the manpage it doesn't appear to be any
> > better.
> >
> > Unless getpgrp() is a better source of entropy than I give it credit
> > for, I think this port should perhaps be marked as vulnerable.
> 
> It's not spectacular looking at that output, but it seems like a  
> typical hash.
> 
> As long as getpgrp() and getpid() don't always fall in the same
> range (thus producing the same sets of numbers) and getpid() doesn't
> return a multiple of getpgrp() << 8, I don't see any particular
> problems with the above setup.
>

My concern is that an unprivileged attacker could log pids created by
his own processes  and virtually eliminate entropy from  getpid(). I'm
wondering if something similar can be done with getpgrp(). If
it can then entropy may fall to a handfull of bits, and bruteforce may
not be all that brutal.