BUG: simple attack when control channel muxing is used

[Ángel González]

On 10/11/14 18:20, Christoph Anton Mitterer wrote:
> Uhm... no I talk an about evil user,...
> As long as the user can create the socket, he can at least trick root
> into using it (if that uses the socket from a location as /tmp), just as
> my example has shown.
> The socket there was owned by user:user and had mode 600... yet root
> connected to it without noting.
>
>
> If one does it the other way round, i.e. root creates the mux:
> I tried last week something like this:
> root at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC
>
> and then:
> user at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB
>
> It "fails" of course, at least it cannot open the socket and then goes
> on an connects normally.

Note that Linux enforces the discretionary permissions set on unix 
sockets but other
Unix (including the BSD family) doesn't.

The ssh check

> if ((euid != 0) && (getuid() != euid)) { error("multiplex uid 
> mismatch: peer euid %u != uid %u", (u_int)euid, (u_int)getuid());

seems precisely to be trying to protect from this (euid is the peer euid).

I guess the (euid != 0) checkis there in case ssh was root setuid? It 
should probably be
changed to if ((euid != 0 && (getuid() != uid)) && (getuid() != euid)) 
not to make it so easy
for a malicious root to use your remote connections (yes, it would need 
receiving the peer ruid).

However, for the attack shown, there's not so much to win from improving 
the check at the
socket server side. It should be the connecting ssh (ie. root's) the one 
verifying that the socket
is owned by himself.


> That being said,... I haven't checked for any racey hacks...
Sadly, the provided patch has a race condition between the stat and the 
connect. And I don't think
fstat()ing a connected unix socket would give us the owner of the socket 
inode... :(


Regards