Mailing List Archive

Inhibiting swapping with mlock
There's one vulnerability that's bugged me for some time. It applies
to nearly all crypto software, including ssh. That's the swapping of
sensitive info (such as keys and key equivalents) onto hard drives
where they could possibly be recovered later.

The Linux kernel provides a system call, mlock(), that inhibits
swapping of a specified region of virtual memory. It locks it into
real memory.

I see no calls to mlock anywhere in ssh.

The easiest thing would be for ssh to mlock its entire data and stack
segments at startup (no need to protect the text segment). This does
entail a risk of deadlocking machines with limited RAM, though.

What do people think? Should this be a build option?

Phil
Re: Inhibiting swapping with mlock [ In reply to ]
On Thu, 13 Jan 2000, Phil Karn wrote:

> The Linux kernel provides a system call, mlock(), that inhibits
> swapping of a specified region of virtual memory. It locks it into
> real memory.
>
> I see no calls to mlock anywhere in ssh.

OpenBSD supports swap encryption instead. shouldn't be hard to port to
Linux.

option UVM_SWAP_ENCRYPT
Enables kernel support for encrypting pages that are written out to swap
storage. Swap encryption prevents sensitive data from remaining on the
disk even after the operating system has been shut down. This option
should be turned on if cryptographic filesystems are used. The sysctl
variable vm.swapencrypt controls its behaviour. See sysctl(8) and
sysctl(3) for details.

-d.

---
http://www.monkey.org/~dugsong/
Re: Inhibiting swapping with mlock [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 13 Jan 2000, Dug Song wrote:

> On Thu, 13 Jan 2000, Phil Karn wrote:
>
> > The Linux kernel provides a system call, mlock(), that inhibits
> > swapping of a specified region of virtual memory. It locks it into
> > real memory.
> >
> > I see no calls to mlock anywhere in ssh.
>
> OpenBSD supports swap encryption instead. shouldn't be hard to port to
> Linux.

i was about to say that maybe swap should be encrypted. And, if
you're really paranoid, you might go so far as to apply ipsec/swan
principles to paged memory entirely (ie encrypt ALL memory and implement
an authentication scheme process by process). This would really slow
things down, however, and also leads to the question of where do you keep
the keys? On the insecure hard drive?
Of course, for most purposes, having swap on a partition that's
not touchable by anyone but root is usually good enough, plus the fact
that most modern OSes (*BSD and Linux in particular) don't allow processes
to acess other processes memory, except under special conditions (ie
forks, shared libs, etc)

Systems Programmer - Nathan Paul Simons
http://www.nmt.edu/~enigma Speare 20 x5748

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBOH4uCYagi6ObDYzdAQGgHgQAkh+g5dTU3XMbCtYacS75F1eEIjDGBU/k
hBm4sT0sWQ8FL90iKR9odViZI1NcDMzBEscaugvSP16KoaLgqyauMpgcGQy0sNLi
tGUab8RLytsNrGSCDGLPqw8acIxBYThk6sIdJCYFOo1D6wWuOGci8BXCKdXPkJ5c
+0tQra6Y+TU=
=Q6JZ
-----END PGP SIGNATURE-----
Re: Inhibiting swapping with mlock [ In reply to ]
> Of course, for most purposes, having swap on a partition that's
>not touchable by anyone but root is usually good enough, plus the fact
>that most modern OSes (*BSD and Linux in particular) don't allow processes

I'm thinking mainly about a machine that has been physically seized.

Phil
Re: Inhibiting swapping with mlock [ In reply to ]
On Thu, 13 Jan 2000, Phil Karn wrote:

> There's one vulnerability that's bugged me for some time. It applies
> to nearly all crypto software, including ssh. That's the swapping of
> sensitive info (such as keys and key equivalents) onto hard drives
> where they could possibly be recovered later.

FWIW OpenSSH is pretty careful to bzero() sensitive data (such as
keys and passphrases) as soon as possible.

This does not protect data that has been swapped, but it does reduce
the likelyhood of it reaching swap in the first place.

Regards,
Damien Miller

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)
Re: Inhibiting swapping with mlock [ In reply to ]
--- Damien Miller <djm@mindrot.org> wrote:
> On Thu, 13 Jan 2000, Phil Karn wrote:
>
> > There's one vulnerability that's bugged me for
> some time. It applies
> > to nearly all crypto software, including ssh.
> That's the swapping of
> > sensitive info (such as keys and key equivalents)
> onto hard drives
> > where they could possibly be recovered later.
>
> FWIW OpenSSH is pretty careful to bzero() sensitive
> data (such as
> keys and passphrases) as soon as possible.
>
> This does not protect data that has been swapped,
> but it does reduce
> the likelyhood of it reaching swap in the first
> place.

I don't know about Linux and the BSD variants, but I
think you can lock a process into memory which will
prevent it from being paged out in Solaris. Perhaps
this is something we should investigate?

Ben
mailto:bent@clark.net
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: Inhibiting swapping with mlock [ In reply to ]
In message <200001140435.UAA23022@homer.ka9q.ampr.org>, Phil Karn writes:
>I'm thinking mainly about a machine that has been physically seized.
That was the main motivation behind the swap encryption I implemented
for OpenBSD. It is amazing what you find on a swap partition: plaintext
passwords, old icb conversations, old emails, old netscape url history
lists, etc... Data survives across multiple system shutdowns.

Niels.
Re: Inhibiting swapping with mlock [ In reply to ]
I agree, encrypting the swap partition is an effective defense, but it
sure seems expensive. How much CPU time does it take to encrypt a disk block
compared to a) the CPU time spent in the filesystem and device driver code
and b) the real time needed to do the disk I/O? What ciphers are generally used?

Phil