This was posted to bugtraq as well.
----- Forwarded message from Theo de Raadt -----
>From [EMAIL PROTECTED] Mon Aug 7 08:46:45 2000
Approved-By: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2000 10:39:32 -0600
Reply-To: Theo de Raadt <[EMAIL PROTECTED]>
Sender: Bugtraq List <[EMAIL PROTECTED]>
From: Theo de Raadt <[EMAIL PROTECTED]>
Subject: Re: recovering ssh passwords from memory
X-To: Matt Power <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
In-Reply-To: Your message of "Thu, 03 Aug 2000 18:04:54 EDT."
<[EMAIL PROTECTED]>
> 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.
----- End of forwarded message from Theo de Raadt -----
--
Atro Tossavainen (Mr.) | The Institute of Biotechnology at the
Systems Analyst | University of Helsinki, Finland, employs
+358-9-19158939 | me, but my opinions are my own.
< URL : http : / / www . iki . fi / atro . tossavainen / >
