Fiedler Roman
2016-01-15 08:53:43 UTC
Von: openssh-unix-dev [mailto:openssh-unix-dev-
Hello,
in light of the recent CVE-2016-0777, I came up with the following idea,
that would have lessened its impact. Feel free to ignore or flame me,
maybe its stupid or I missed something :)
- private key material should only ever be handled in a separate process
from the SSH client. ssh-agent (maybe slightly extended) seems the
logical choice.
- in places where the client currently reads ssh-keys
(load_public_identity_files), automatically spawn an ssh-agent instead
if none is available. Connection to the agent might be via the usual
SSH_AUTH_SOCK or via an inherited pipe() or socketpair() if newly
spawned. Those anonymous filedescriptors would mean that this
ssh-agent is 'private' to this one client.
I would avoid direct spawn or even connect via socket(see proposal atHello,
in light of the recent CVE-2016-0777, I came up with the following idea,
that would have lessened its impact. Feel free to ignore or flame me,
maybe its stupid or I missed something :)
- private key material should only ever be handled in a separate process
from the SSH client. ssh-agent (maybe slightly extended) seems the
logical choice.
- in places where the client currently reads ssh-keys
(load_public_identity_files), automatically spawn an ssh-agent instead
if none is available. Connection to the agent might be via the usual
SSH_AUTH_SOCK or via an inherited pipe() or socketpair() if newly
spawned. Those anonymous filedescriptors would mean that this
ssh-agent is 'private' to this one client.
bottom). That way the network/terminal interacting process could be built
not only without having access to private key material, but also having no
access to most operating system resources (including open/connect/...) even
when remote code execution was successful.
- If a ssh-agent is already running, but the client needs to read more
keys: Spawn and handle a second, private agent? Use ssh-add? The
former would be preferable but more complicated because two different
agents would have to be handled. The latter would have the unwanted
side-effect of exposing keys via the ssh-agent that maybe shouldn't
be.
- If a key is password-protected, the client would have to read the
password and pass it on to ssh-agent. Could this be done in a better
way, maybe without exposing the password to the ssh-client?
See below: As the management process would need the password, it couldkeys: Spawn and handle a second, private agent? Use ssh-add? The
former would be preferable but more complicated because two different
agents would have to be handled. The latter would have the unwanted
side-effect of exposing keys via the ssh-agent that maybe shouldn't
be.
- If a key is password-protected, the client would have to read the
password and pass it on to ssh-agent. Could this be done in a better
way, maybe without exposing the password to the ssh-client?
suspend the network/terminal process, read the password and then response to
the key signing request.
This would not per se block the current password stealing attacks on ssh
client, where malicious remote side just pretends after successful login,
that passphrase for key was wrong and requests the use to re-enter the
phrase again. But it could make it easier to circumvent this condition, e.g.
when management process puts a preamble before asking the password, one that
an attacker has hard time to guess (e.g. Are you [user somebode], logged in
since [time] on [machine] really sure, that you want to connect to service
[local name of remote service], trust its key requests for [local key name]
and allow sign requests, then enter your password ...)
- ssh client could be stripped of any code that reads ssh-keys directly.
- or using the mechanism above could be made an option SpawnPrivateAgent
(possibly defaulting to 'yes')
- maybe, if that works, one could do a similar thing for sshd and its
hostkeys.
What do you think of a following procedure?- or using the mechanism above could be made an option SpawnPrivateAgent
(possibly defaulting to 'yes')
- maybe, if that works, one could do a similar thing for sshd and its
hostkeys.
* On startup, at first management process is created. This process is
somehow privileged, as it still can execute all operating system calls
without special restrictions. This management process may connect to an
agent or launch agent process by itself (if needed) to have access to key
material.
* From the management process, have network/terminal process forked, reexec
itself (thus get rid of any virtual memory information shared with
management process, e.g. address space layout, strings already loaded - e.g.
host name, user name, config parameters, ... thus eradicating any
information present in the management process)
* Let management process seccomp secure the network/terminal process to
allow only file descriptor read/write operations, ..., that what is really
needed but no other syscalls (especially no open/exec,.../xxxxat style of
calls). Thus the terminal process efficiently loses all capabilities to
access key material by himself, which is enforced by the OS (this will work
only on platforms, that support it, others will have to leave out this
step).
* Use the socket from the network/terminal process to the management process
only to query (search for) keys, request signing of material.
* Let the management process suspend the terminal process and ask for key
passphrases when needed.
* Let the management process immediately suspend the network/terminal
process if rate of key search/sign requests exceeds limit or (if
mathematically easily detectable) signing of problematic data is requested
to extract e.g. DSA keys (do not know, which other key types have similar
weaknesses). This would also protect the local keys when an agent forwarding
was enabled (do not know, if such protection might already be in place) and
remote side starts to create signatures en masse.
* Let the management process search keys/sign directly or ask the agent -
minor design decision?
Kind Regards,
Roman