Security team review:
- handy tool
- lot's of overlap with netcat
- code is quite old (first packaged in Debian in 2004), code itself is even
older and uses coding conventions that are not defensive
- spot checking buffers, not a lot of input validation. Many are static
buffers, which if exploitable should end in DoS rather than something else due
to our compiler options.
- looking at recv and send operations, things seem ok
- does not sanitize environment so callers need to do this
- SSL functionality doesn't check the hostnames or ip addresses. Seems only
wants to be able to handle ssl connections, not ensure their security (see man
page)
- with the exception of my checking of the send/recv portions of the code,
almost everywhere I looked I found a bug within a few minutes. Some were
crashers due to insufficient input sanitizing.
The code is very old, and I found actual and potential bugs. socat's
design and lack of input validation suggest it is meant to be run by a
user and does therefore makes no effort to protect the user from
herself. In that light, I'm not hugely concerned with socat in main as a
gernerl purpose utility. However, since this is being promoted to
support nova, and nova runs socat as root in an automated fashion, this
breaks upstream's assumptions on invokers of socat and I feel this has
potential to be a problem area for nova security. As such, I am not
comfortable with promoting socat in nova's present form.
Since nova is strategic, here are my suggestions:
- update nova/virt/libvirt/connection.py to use netcat instead of socat (socat
is only used in one place). The patch should be pretty small and could fallback
to netcat if socat is not installed. This would not change upstream behavior
and is likely upstreamable
- adjust nova to perform input validation on get_pty_for_instance() to defend
against any bugs in libvirt (should be upstreamed)
- execute netcat with least privilege (keep in mind that libvirt can be
configured to run VMs as root, and I haven't looked at LXC if that is relevant.
Should be upstreamed)
Since the server team did not comment on why it must be socat and not netcat,
if they determine socat is a hard depends and cannot use netcat, then I suggest:
- adjust nova to perform input validation on get_pty_for_instance() to defend
against any bugs in libvirt (should be upstreamed)
- execute socat with least privilege (keep in mind that libvirt can be
configured to run VMs as root, and I haven't looked at LXC if that is relevant.
Should be upstreamed)
- adjust nova to sanitize the environment, particularly for things socat is
looking at (grep for 'getenv' in the socat source. Should be upstreamed)
- provide a wrapper around socat to rigorously verify its arguments (remember,
socat can be used to launch arbitrary code, just search for 'script' in the man
page)
- provide an AppArmor profile for the socat wrapper, and execute socat with
'ix' to enforce file access, execs, capabilities, etc
** Changed in: socat (Ubuntu)
Assignee: Jamie Strandboge (jdstrand) => (unassigned)
** Changed in: socat (Ubuntu)
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/829234
Title:
[MIR] socat
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/socat/+bug/829234/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
