On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler@xxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
