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 Server Team, which is subscribed to socat in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs