openssh unix dev - Nov 2014 - ControlMaster question

Hello.

I'd like to spread the use of control channel muxing at our institute,
so the plan was to change the defaults for our ssh to, e.g.

ControlMaster auto
ControlPath /tmp/%C.ssh-mux
ControlPersist 0

The idea was:
- use opportunistic muxing
- not all users may have actually homedirs, therefore something like
/tmp needs to be used
- the mux process should be backgrounded (and not block the original
ssh process to remain open) and it should immediately close when it's
no longer used by anyone


Some problems/questions:
1) Is it a security issue, when the sockets are created in /tmp? E.g.
could a malevolent user create such a socket and intercept the other
user's connection? Or does ssh check whether the socket is owned by
BOTH it's own user/group?
I think normally there shouldn't be a way for a user a to create a
file owned by user b,... it may be possible that user a creates a file
which is owned by group b... but if ssh checks BOTH user and group, it
should be fine, right? So does it do such checks?
Are there any other things to obey (thinking of all the different
kinds of /tmp-dir hacks)?

2) Apparently ControlPersist 0 is actually the same as yes and the mux
process isn't stopped 0s (i.e. immediately) after the last connection
has gone, but never.
Is this a bug?


Sincerely,
Philippe

Hey.

Interesting that you bring this up now... I've actually looked into this
a week ago but forgot to write a bug report.

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.

upstream what do you think?


Cheers,
Chris.

btw: I cannot answer your second question, perhaps one of the developers
knows more about that.
-------------- 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/9b58ec3d/attachment.bin>

On Mon, 10 Nov 2014, Philippe Cerfon wrote:
> Some problems/questions:
> 1) Is it a security issue, when the sockets are created in /tmp? E.g.
> could a malevolent user create such a socket and intercept the other
> user's connection? Or does ssh check whether the socket is owned by
> BOTH it's own user/group?
It allows the user who created the socket and root (subject to file
permissions). It's best not to mix users' control sockets in the same
directory. Could you arrange a per-user temporary directory be created
at login time? (e.g. via PAM) If so, then you could put the sockets
there.
> 2) Apparently ControlPersist 0 is actually the same as yes and the mux
> process isn't stopped 0s (i.e. immediately) after the last connection
> has gone, but never.
> Is this a bug?
Kind of - '0' is used internally to implement ControlPersist=yes and
this
leaked through to the UI. It's probably not a good idea to ban it
retrospectively, so I'll add a note to the manual page.

-d

Hey folks.

Damien added a commit[0] which already suggests users to place their
sockets in safe directories only.

But I think this is only part of a proper solution, so I made some
effort and collected all the information from this thread, and placed it
into the ticket[1] I've had created previously:

I've also reported ticket #2318[2] which is loosely related

Ideally, any further discussions, patches, would be placed there.


Cheers,
Chris.


[0]
https://github.com/openssh/openssh-portable/commit/fc302561369483bb755b17f671f70fb894aec01d
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2311#c1
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2318
-------------- 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/20141115/1c7d2f53/attachment.bin>