[Bug 829234] Re: [MIR] socat
Thanks for your analysis Jamie, based on your comments we will replace it with netcat if viable. Thanks! ** Changed in: socat (Ubuntu) Status: Confirmed => Won't Fix -- 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
[Bug 829234] Re: [MIR] socat
I should mention that performing input validation on get_pty_for_instance() and dropping privileges would be enough to 'solve' the immediate issues with nova's use of socat, but the other suggestions are for future-proofing against the new (and presumably rapidly changing) nova codebase and for ensuring that we are protected from problems not found in this shallow security audit. -- 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
[Bug 829234] Re: [MIR] socat
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
[Bug 829234] Re: [MIR] socat
I'll answer my own question, from nova/virt/libvirt/connection.py:
def get_pty_for_instance(instance_name):
virt_dom = self._lookup_by_name(instance_name)
xml = virt_dom.XMLDesc(0)
dom = minidom.parseString(xml)
for serial in dom.getElementsByTagName('serial'):
if serial.getAttribute('type') == 'pty':
source = serial.getElementsByTagName('source')[0]
return source.getAttribute('path')
port = get_open_port()
token = str(uuid.uuid4())
host = instance['host']
ajaxterm_cmd = 'sudo socat - %s' \
% get_pty_for_instance(instance['name'])
cmd = ['ajaxterm', '--command', ajaxterm_cmd, '-t', token,
'-p', port, '-T', '300']
utils.execute(cmd)
I think this could potentially be replaced with netcat as it looks like
netcat provides equivalent args. I'm not sure why we are using '-t
' with socat since '-t' is a timeout value
socat is being invoked as root by nova here, and the socat code is fairly
crufty (see my review below) so this is not desirable. On my non-nova qemu-kvm
VMs, I see that the pty is owned by the unprivileged libvirt-qemu:
$ ls -l /dev/pts/5
crw--w 1 libvirt-qemu tty 136, 5 2011-09-21 10:29 /dev/pts/5
I can say that while the code is running as root, the arguments passed
to socat do not seem to be under attacker control and utils.execute() is
not generally susceptible to shell injection on this host, so that is
good. However, combined with ajaxterm, it does look like if someone is
somehow able to adjust the output of the get_pty_for_instance() command,
then shell injection the arguments to socat could be adjusted for
arbitrary code execution (since it supports scripting). Fiddling with
libvirt and defining some bad XML, I was not able to subvert libvirt
into accepting bad input, but I also didn't try very hard.
Perhaps if sticking with socat these can be adjusted:
- run 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)
- perform input validation on get_pty_for_instance() to defend against any bugs
in libvirt
--
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
[Bug 829234] Re: [MIR] socat
I'm still reviewing this, but there is a lot of overlap between socat and netcat, and I wonder what specific features of socat are required over netcat. -- 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
[Bug 829234] Re: [MIR] socat
** Changed in: socat (Ubuntu) Assignee: Ubuntu Security Team (ubuntu-security) => Jamie Strandboge (jdstrand) -- 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
[Bug 829234] Re: [MIR] socat
** Changed in: socat (Ubuntu) Assignee: Canonical Security Team (canonical-security) => Ubuntu Security Team (ubuntu-security) -- 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
