Proposal: always handle keys in separate process

[Alexander Wuerstlein]

On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler at ait.ac.at> wrote:
> > 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 :)
>
> What do you think of a following procedure?
> 
> * 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)

So, effectively you propose to also split up the ssh client into three
processes.

While it sounds like a good idea in general, I think one should try the
easier split-up into two first. For why I think it is far easier to
first separate out the ssh-agent/key-handling, see below.

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

Those separations and restrictions are the really hairy part here:
Pulling out the key handling is small compared to the amount of
functionality that is e.g. X11-forwarding, agent-forwarding or
(potentially dynamic) proxy/socket-forwarding which would need to be
handled when splitting the management from the connection/terminal part.

Another potential problem is the portability problem which seccomp
poses, there is unfortunately no POSIX syscall filtering or sandboxing
API. That makes things even more complicated.

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

That should all be possible imho.



Ciao,

Alexander Wuerstlein.