Re: recovering ssh passwords from memory

[Theo de Raadt <deraadt () CVS OPENBSD ORG>]

> If you use the ssh-1.2.30 ssh client on Solaris 8, a password typed
> for password authentication can often be partially recovered from
> the client process memory long afterwards, using pcat (from the TCT
> distribution). As far as I know, the problem is that ssh reads the
> password using fgets, and the program happens to not subsequently
> overwrite the relevant memory locations used by that stdio buffer.
> (It overwrites the main password buffer, but not the stdio buffer.)

I assume that pcat is similar to gcore.

> Note that this is not portable. If you wanted to use a similar
> approach on other systems, you might need to use f->_IO_read_base
> rather than f->_base. Also, you could instead modify the code so that
> read(2) is used for password input, avoiding stdio completely.

Yeah, that is massively non-portable.

For the record, OpenSSH does not have this problem since it does not
use stdio for reading such data.  Instead it uses a routine which
calls read() per-character, so that proper semantics result from
hitting ^C and EOF on the wire.  The code we use is similar to that
found in getpass(3).

> They can instead sometimes recover passwords from
> the portions of /dev/mem corresponding to kernel tty->read_buf's long
> after the password was typed (there might be a similar level of
> tty-buffer risks with the kernel on Solaris or other systems; I
> haven't checked). To prevent this, you can modify the kernel -- I
> happen to put a "memset(tty->read_buf, 0, N_TTY_BUF_SIZE);" before the
> "return retval;" line in the function read_chan in
> linux/drivers/char/n_tty.c, along with some heuristic conditional
> logic for when that memset statement will be executed.

I'm just writing mods to OpenBSD so that it clears out the ring
buffers used for tty management, upon tty close.  I am not completely
comfortable with clearing data out as it is copied to userland; things
get quite complicated.  Of course, if your kmem can be read, you're
already in heaps more trouble.