[16088] in bugtraq
Re: recovering ssh passwords from memory
daemon@ATHENA.MIT.EDU (Theo de Raadt)
Mon Aug 7 01:49:57 2000
Message-ID: <200008041639.e74GdWU15793@cvs.openbsd.org>
Date: Fri, 4 Aug 2000 10:39:32 -0600
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To: Matt Power <mhpower@MIT.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Thu, 03 Aug 2000 18:04:54 EDT."
<200008032204.SAA09100@tiki-god.mit.edu>
> 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.
