From RISKS: secret scrubbing code removed by optimizers

William R. Knox wknox at
Tue Feb 4 03:30:36 EST 2003

A very belated response, but...
In addition, someone would want to scan /dev/kmem instead of replacing
sshd because you may run Tripwire or an equivalent that will notify you of
a modified sshd.  It is a bit harder to notify you of a scan of /dev/kmem.

			Bill Knox
			Senior Operating Systems Programmer/Analyst
			The MITRE Corporation

On Sat, 9 Nov 2002, Darren Tucker wrote:

> Date: Sat, 09 Nov 2002 11:21:28 +1100
> From: Darren Tucker <dtucker at>
> To: Thomas Binder <binder at>
> Cc: OpenSSH Devel List <openssh-unix-dev at>
> Subject: Re: From RISKS: secret scrubbing code removed by optimizers
> Thomas Binder wrote:
> > The question is, though, why someone having access rights to read
> > /dev/kmem or swap space wouldn't rather install a trojaned or
> > otherwise modified sshd instead to snoop credentials.
> A couple of reasons:
> 1) Malloc doesn't clear memory. Some platforms clear the memory before
> malloc gets it, but some don't. On the ones that don't an unprivileged
> user can just keep malloc'ing memory and looking for something
> interesting.
> 2) If I break into your box today, I could scan /dev/kmem and
> potentially find a password you typed in last week. I might have to wait
> weeks or months before you get bitten by a trojaned sshd.
> 3) In the worst case the memory containing the password could get
> swapped out and remain on disk for *forever*. If I broke into your box
> today I might find a password you entered last year.
> These are long shots, but are you willing to bet your password on it?
> Every time you enter it?
> --
> Darren Tucker (dtucker at
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev at mailing list

More information about the openssh-unix-dev mailing list