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@hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC
and then:
user@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
