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

[bugzilla-daemon at mindrot.org]

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.