|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: recovering ssh passwords from memory
From: Theo de Raadt (deraadt
CVS.OPENBSD.ORG)Date: Fri Aug 04 2000 - 11:39:32 CDT
- Next message: Schimanski, Michael: "Re: FTP Serv-U 2.5e vulnerability."
- Previous message: Elias Levy: "kon2"
- In reply to: Matt Power: "recovering ssh passwords from memory"
- Next in thread: Scott Long: "Re: recovering ssh passwords from memory"
- Reply: Theo de Raadt: "Re: recovering ssh passwords from memory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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.
- Next message: Schimanski, Michael: "Re: FTP Serv-U 2.5e vulnerability."
- Previous message: Elias Levy: "kon2"
- In reply to: Matt Power: "recovering ssh passwords from memory"
- Next in thread: Scott Long: "Re: recovering ssh passwords from memory"
- Reply: Theo de Raadt: "Re: recovering ssh passwords from memory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]