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
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