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: [email protected]
Reporter: [email protected]
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@hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostB
and then:
root@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.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
