Re: protocol support for privilege seperation

[Niels Provos <provos%citi.umich.edu@localhost>]

that is a known problem.  but for the same reason, if the
non-privilege separated process gets compromised, it can do
a man-in-the-middle with ifself.  or just read the key file
and use if from a different hosts.   this increases security,
it is not perfection.

On Wed, Jun 26, 2002 at 10:29:31PM -0700, Wei Dai wrote:
> It's a good idea for an SSH server to drop down to normal user privileges 
> after authentication is complete, and only make requests to a privileged 
> monitor for things like key re-exchanges. Unfortunately, without changes 
> to the SSH protocol as currently defined, there seems to be no way to do 
> this without allowing the non-privileged process to perform 
> man-in-the-middle attacks if it was compromised.
> 
> The attack is as follows. Assume an attacker is able to corrupt a 
> non-privileged SSH process and cause it to execute arbitrary code. He 
> impersonates the server at the TCP/IP layer and waits for someone to log 
> in. When a connection comes in, he starts a key re-exchange as the 
> couterparty to the SSH process that he controls, using the SSH_MSG_KEXINIT 
> packet he received from the remote party and forwarding responses back and 
> forth until the key exchange is complete. At this point, even if the 
> Diffie-Hellman key generation and agreement were done in the privileged 
> monitor, the monitor must either pass the shared secret back to the 
> non-privileged process, or act as an encryption/MAC oracle for it. Either 
> way, the attacker can now send arbitrary messages to the remote party that 
> it will think came from the server.
> 
> The problems seems to be that the privileged monitor has no way to tell 
> whether a SSH_MSG_KEXINIT packet is for the initial key exchange, or for a 
> re-exchange. I propose making use of the reserved field of 
> SSH_MSG_KEXINIT, something like:
> 
> byte      SSH_MSG_KEXINIT
> ...
> boolean   first_kex_packet_follows
> boolean   is_initial_exchange
> byte[3]   0 (reserved)
> 
> The privileged monitor would refuse to sign any exchange hash where
> is_initial_exchange is true if it's not an initial exchange. I think that
> would allow implementors to take full advantage of privilege seperation
> and avoid this attack. If current implementations are programmed to ignore
> the reserved field (rather than treat a non-zero value as an error), this
> should cause no compatibility problems. Specificly, an old client that
> does not make use of is_initial_exchange would be vulnerable to this
> attack, but it would still work.
> 
> Comments?