BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question)

[Christoph Anton Mitterer]

On Mon, 2014-11-10 at 08:14 +0000, mancha wrote: 
> The socket is created with a umask of 0177 so you should end up with
> socket perms of 0600 or thereabouts. Standard ACLs kick in.
Sure,... but that alone doesn't help...

>  If the
> threat model includes an evil root though
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.

Now assuming root wouldn't be evil, but accidentally set o+rw:
root at hostA:~$ chmod o+rw /tmp/sshmux

and then trying:
user at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB

ssh exits with $?=141 but not giving any further warning/error

The ssh of the mux however (when in -v) gives:
>debug1: multiplexing control connection
>multiplex uid mismatch: peer euid 1000 != uid 0
to stderr


The same seems to be the case when trying with two normal users, i.e.
user1 at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC
user1 at hostA:~$ chmod o+rw /tmp/sshmux

user2 at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB

debug1: multiplexing control connection
multiplex uid mismatch: peer euid 1000 != uid 1001


So it only seems to work that a normal user tricks root into using an
alien socket.
That being said,... I haven't checked for any racey hacks...


> Regarding possible racey mischief, the socket is created "pseudo
> atomically".
> 
> That said, an ownership check that prevents, among other things, root
> from accidentally falling through a wormhole wouldn't be bad. Attached
> patch against 6.7p1 should do.

Wouldn't it be the enough to simply check whether
- the socket is owned by the same user
- has mode 600
- and directory permissions are such, that another user couldn't have
changed this (thinking of ACLs for that)


> PS Patch also at:
> http://sf.net/projects/mancha/files/misc/openssh-6.7p1_socket-owner.diff
mhh I get a HTTP 500 internal server error?!


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141110/1764d0e3/attachment-0001.bin>