On Fri, Dec 22, 2006 at 04:02:08AM +0100, Christian Biere wrote:
> Thor Lancelot Simon wrote:
> > On Fri, Dec 22, 2006 at 03:29:28AM +0100, Christian Biere wrote:
> > > Christian Biere wrote:
> > > > > static char pwbuf[1024];
> > > > pwbuf is/must be NUL-terminated?
> > > 
> > > Ok, I noticed that pwbuf[] is static and the check for buflen==0.
> > > I guess using a mlock()ed buffer instead would be paranoid?
> > 
> > What exactly is the point of this?  The program which prompted for the
> > user's password, after all,
> 
> Isn't it possible for the program to read the password into a mlock()ed
> buffer when prompting for it? Maybe it's futile for a X11 application
> but if you're reading it from a TTY or some other file descriptor, that's
> possible, isn't it?

1) Do you believe that this is what programs that prompt for passwords
   actually do?

2) If this were what programs that prompted for passwords actually did,
   then what you propose might protect against an attacker who did not
   have root access to the machine now, but could at some point in the
   future, if the programs were swapped out and those swap pages never
   overwritten.  But, in fact, anyone who _does_ have access to not even
   root, but instead the euid of the program that is prompting for the
   password, can simply steal the password _now_.  So I am not sure what,
   in the real world, this change would gain you.

If, instead of a pipe, we used shared memory between the helper and the
userspace program, mlocking the buffer in the helper might guarantee that
it was locked in the caller.  And if the caller never ever copied the
password before or after feeding it to the helper, this might protect
against disclosure of the password to a later attacker with access to the
swap partition.  But that seems like a lot of complexity for a very
hypothetical gain -- particularly when those worried about such attacks
can (and should) just encrypt their entire swap partitions.

Thor