openssh bugs - Nov 2014 - [Bug 2311] New: simple attack when control channel muxing is used

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

            Bug ID: 2311
           Summary: simple attack when control channel muxing is used
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: P3
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.net

Hi.

A thread[0] on the list reminded me about something I've noted a week
or so ago.

It seems that when using control channel multiplexing, ssh (and likely
scp and friends as well) doesn't make any checks on whether the socket
is fully owned by the current user/group, which in turn makes it easy
for an attacker to trick someone else into using an existing channel
(and e.g. upload sensitive data to that system).


A simple test showed, that ssh doesn't employ any security checks...
when it is able to open the socket, it'll use it apparently:

I tried last week something like this:
user at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostB

and then:
root at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostC

As you can see, the socket is created by user, and root "accidentally"
uses it, even trying to connect to another node.
ssh will just do so without any complains.

And even when one uses something like %h, %p or that like, an attacker
can easily guess these.


Since it doesn't seem to be documented that the socket must be created
in a secure location and since neither there are any owner checks like
sshd's StrictMode... I'd probably consider that a security hole.

Any further possible attack vectors? Things like the other typical
attacks on /tmp files?

Cheers,
Chris.

[0]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033124.html

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

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.

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

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.net>
---
Created attachment 2506
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2506&action=edit
mux socket client side checks

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

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

--- Comment #3 from Christoph Anton Mitterer <calestyo at scientia.net>
---
Comment on attachment 2506
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2506
mux socket client side checks

For the records, added the patch from mancha (and not from myself).

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
As I mentioned, root being able to access user sockets is intentional
behaviour. I'm not interested in adding additional checks to prevent
this - they would need to be behind an option to avoid breaking
existing, legitimate uses and I don't believe that the maintenance and
complexity cost of a new config option is warranted.

Don't use shared directories for mux sockets.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Tomas Mraz <t8m at centrum.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t8m at centrum.cz

--- Comment #5 from Tomas Mraz <t8m at centrum.cz> ---
It should be documented in the ssh manual page that the socket must be
created in proper places.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #6 from Christoph Anton Mitterer <calestyo at scientia.net>
---
(In reply to Damien Miller from comment #4)
> As I mentioned, root being able to access user sockets is
> intentional behaviour. I'm not interested in adding additional
> checks to prevent this - they would need to be behind an option to
> avoid breaking existing, legitimate uses and I don't believe that
> the maintenance and complexity cost of a new config option is
> warranted.
> 
> Don't use shared directories for mux sockets.
It seems kinda strange that you blindly close this issue away, even
though it's a very valid issue (which someone might have sooner or
later worked upon - while now it will just be forgotten),... especially
since my analysis contained several other issues, which are not simply
solved by adding documentation.

Also you seem to completely ignore the security issue pointed out by
someone on the list, that it's apparently only the MUC server, which
makes UID checks while the client blindly trusts.

Especially when one looks at similar situations (strictmodes on key
files, etc.) where one didn't just let this handle improperly by
documentation, instead properly intercepting it on a code level.
Actually someone did even provide a patch which would have likely
properly fixed some of the issues described herein, so why didn't that
got merged?

Or is control muxing simply considered a dead feature where development
is no longer desired to be seen?




(In reply to Tomas Mraz from comment #5)
> It should be documented in the ssh manual page that the socket must
> be created in proper places.
It already is (at least partially)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.