[Bug 2311] simple attack when control channel muxing is used

Sat Nov 15 14:13:28 EST 2014

https://bugzilla.mindrot.org/show_bug.cgi?id=2311

--- Comment #1 from Christoph Anton Mitterer <calestyo at scientia.net> ---
I've seen that Damien committed
fc302561369483bb755b17f671f70fb894aec01d, which adds some lines of
documentation, telling people to only place the sockets into locations
where other users cannot access them.

However, I think this should still be solved technically. It's the same
as with permissions on the identity files: OpenSSH doesn't just
document somewhere that these files should have certain permissions, it
also checks for that per default (StrictModes yes).

Since discussion on the mailing list evolved a bit further but
basically stopped now, I'm trying to collect all the information from
there here (I'm not going to quote which information comes from which
persons, that can be read up in the list archives):

MOTIVATION:
The basic problem is that people may accidentally (who reads the
manpages correctly? ^^) or intentionally want to place the control mux
sockets into locations which are readable by different users.
Typical examples: /tmp or shared homedirs.

ATTACKS & SITUATION:
(a) As shown in the original report, it works at least that a user
creates a socket, and may trick root into using it (thereby redirecting
root's connection to any host, and intercepting all data that is sent).
The name's for the sockets are easily guessable/observable and can be
created by a normal user, when a public location as /tmp is used.
=> bad

It was pointed out[2], that there is some use case to this, but it
should probably not be allowed per default.
See POSSIBLE SOLUTIONS below.

(b) Trying to protect users against an evil root is of course moot.
So no need to protect users from a root that intentionally wants to
trick them into using wrong sockets.

(c) When root accidentally makes his own sockets readable by other
users, the server side of the socket (i.e. root's ssh) blocks the
access[1]. => fine
However, see (e).

(d) When normal users try to trick other normal users into using their
sockets, by allowing it via their permissions, ssh behaves as in (c),
i.e. the server side of the socket (i.e. root's ssh) blocks the
access[1]. => fine
However, see (e).

(e) Another possible attack vector was pointed out[3]:
The UID checks from (c) and (d) seem to happen only on the server side
of the socket, i.e. the ssh of the user who tries to trick root or
another user into using his own socket.
Such user could likely compile his own ssh, remove the check from
there, and then the attack from (d) would succeed.
=> bad
See POSSIBLE SOLUTIONS below.

OTHER ISSUES:
(f) Normal behaviour of ssh is usually, that when using a socket fails,
it connects normally. This doesn't work however in (c) and (d) above
and no error is given.
See (5).

(g) See bug #2318.

POSSIBLE SOLUTIONS:
(1) Implement a counterpart to StrictModes, enabled per default, which
only allows a socket to be used, when it's in a directory that is only
accessible by the user.

(2) socket client side: For all users (including root), ssh should ONLY
use such sockets, which are owned by the same user, have mode 0600 (and
depending on (1) are in a "safe" directory).
socket server side: For all users (including root), ssh should only
accept connections from the same user (likely with the exception of
root).

An option should allow to disable each of these two behaviours.

(3) Do *not* exclude root from any of these checks per default. In
order to allow the use cases mentioned in (a), the config options
proposed in (2) could be used.

(4) Add all the various checks from the socket's server side to the
client side as well.

(5) If ssh fails to connect to a socket for reasons of the UID checks
leading to a failure, let ssh connect normally.

(6) Document, whether or not using publicly writeable locations (e.g.
/tmp) is safe after the above and/or further solutions would have been
applied.

FURTHER INFORMATION & PATCHES:
- There is some further analysis[5] of the UID checks already in place.
- There's a patch[6] from mancha (mancha1 at zoho.com), which does (2) for
the socket client side (not for the socket server side) and also adds a
hard link check.
It should probably be checked for race conditions, and whether the hard
link check actually makes sense or not.

OPEN QUESTIONS:
- Are there further attacks (abusing race/timing conditions when the
sockets are create in /tmp)?
In [0] it was said that the sockets would be created "pseudo
atomically" - whatever that means...

- The question was brought up, whether hardlinks could be used to do
any nasty things.
In some newer Linuxes, normal users cannot create hardlinks to files
from other Linux (if some CONFIG option is enabled during kernel
compilation), but this doesn't necessarily apply to other OSes, so we
cannot trust on it.

I personally, would guess, that if (2) from above was implemented, not
much evil could be done with hardlinks.
If the socket client checks whether he is the socket file's user owner,
then not other user (than root) could have set that ownership. Thus is
shouldn't be possible that an evil normal user creates a socket,
hardlinks it, and tricks another user into using one of the two, while
he uses the other (for whatever imaginable evil).
But beware, that I'm not that filesystem expert, so maybe I oversee
something how this could be exploited.

FURTHER IDEAS:
- It may make sense (as proposed here[4]) to change the defaults for:
ControlPath /tmp/%C.ssh-mux
ControlPersist 1s
once this bug was solved and using /tmp as a socket location would be
safe.
With that defaults, control muxing wouldn't still happen per default
(since ControlMaster defaults to no), but using muxes would be simpler,
since it would just require once setting ControlMaster != no.

It should be noted (pointed out here[4] that ControlPersist=0s, is the
same as yes, and *not* the behaviour to immediately close the mux after
the last connection. 

- There are some further wishes expressed here[7].

Cheers,
Chris.

[0]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033128.html
[1]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033130.html
[2]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033134.html
[3]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033133.html
[4]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033124.html
[5]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033133.html
[6]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033141.html
[7]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033142.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.