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
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/
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 at mindrot.org (home) -or- djm at ibs.com.au (work)
--- Damien Miller <djm at 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 at clark.net __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
In message <200001140435.UAA23022 at 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.
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