From RISKS: secret scrubbing code removed by optimizers
William R. Knox
wknox at mitre.org
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.
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 zip.com.au>
> To: Thomas Binder <binder at arago.de>
> Cc: OpenSSH Devel List <openssh-unix-dev at mindrot.org>
> 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
> 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 zip.com.au)
> 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 mindrot.org mailing list
More information about the openssh-unix-dev