Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Oct 2014 21:24:51 +0200
From: Carlos Alberto Lopez Perez <clopez@...lia.com>
To: Fiedler Roman <Roman.Fiedler@....ac.at>
CC: 766073@...s.debian.org, vserver@...t.linux-vserver.org,
 me@...fdog.net, oss-security@...ts.openwall.com
Subject: Re: Multiple disputed issues in util-vserver

On 14/10/14 16:31, Fiedler Roman wrote:
> Hi,
> 
> While fixing a bug, I noticed some strange behavior in linux vserver
> virtualization, that I would call a security problems, but project
> developers see it differently. Since the util-vserver packages and patched
> kernel were or are included in some Linux distros, I would be interested in
> the communities' opinion on that.
> 
> Issue 1: When calling util-vserver tool on the host to execute a job within
> the guest, e.g. to install updates, the host process (in host PID ns) might
> end up being the child of a guest process (with PID only in guest ns), thus
> the parent PID of the host process pointing to a guest ns PID. If the host
> process wants to signal the parent process or some other tool operates using
> the ppid, a host process might interact with another arbitrary host process
> on error (see [1]). Compared to issue 2-3, I'm not sure for myself if it is
> really a bug and what the correct behavior of kernel with pid namespaces
> would be. At least it breaks bash process handling (gets stuck) when calling
> "vserver exec" in a certain way, start-stop-daemon or upstart might not like
> it also.
> 

Is there any (practical) scenario in which an attacker that has
compromised an vserver guest could use this behavior to compromise or
execute code on the host (master)?

> Issue 2: When entering the container from the host or executing commands
> within the container, e.g. to perform common administrative tasks, a
> malicious login shell inside the container might overwrite the
> /usr/sbin/vcontext on the host, thus allowing on to execute arbitrary code
> on the host with root privileges next time vcontext is invoked. See [3].
> Feedback from developer: " Yes, vlogin is known to have several security
> issues. It's a maintenance backdoor, much like the iLO or iDRAC on hardware.
> If you can find ways to improve it, patches would be accepted, but I doubt
> it will ever be possible to do what it does securely." Project documentation
> does not strike out those restrictions (or at least I did not find that or
> the list of "several known security issues" online), other sources, e.g.
> container vs system virtualization comparison strike out the importance of
> the feature to enter a guest from the host easily for maintenance, so I
> guess that those tools were not useful just for me alone. This issue I would
> rate a killer for production use, e.g. for mass hosting.
> 

Can you please send me the PoC for this issue ?

> Issue 3: It seems that handling of open tty FDs on enter, that allows to
> inject arbitrary keyboard input to be read by the parent process, also
> affects the tool to start the guest container. This seems to be the same
> issue with "vserver start" as reported in [2] for vserver enter, which was
> classified as less relevant back than. My rating would be little lower than
> 2 but still quite high for mass hosting: manual restart, e.g. during
> maintenance, seems quite common to me.
> 

If I understand correctly, this (and the previous one) are
CVE-2005-4890, isn't it?.

http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation


> From my point of view, those issues might be expected behavior as claimed by
> the developers, but if so it should be at least stated more clearly in
> documentation:
> 
> a) never use any tools except vserver stop (to terminate the container) to
> interact with a running and possibly compromised container from the host
> b) only use network/socket-based tools to connect to processes inside a
> possibly compromised guest, e.g. SSH. 
> c) never start a possibly compromised container from interactive shell to
> avoid injection of shell commands
> 
> Regarding documentation I would even vote for a solution d), that all those
> tools get a mandatory argument like
> '--i-know-entering-insecure-container-may-kill-my-host' so that it is not
> very likely, that someone will use those tools for something else then
> testing or nice-world administration.
> 
> Opinions to issues 1-3?
> 
> What about solutions?
> 

Halfdog (CC'ed) already suggested some possible solutions:
http://www.paul.sladen.org/vserver/archives/201211/0011.html

> Kind regards,
> Roman
> 
> [1]
> http://list.linux-vserver.org/archive?mss:6788:201410:moeiomapkoefmmdnmcji
> [2] http://www.openwall.com/lists/oss-security/2012/11/05/8
> [3] Guest -> Host escape POC: C-code to be put as /bin/bash replacement in
> guest, will overwrite /usr/sbin/vcontext on host. Available on request
> 
> 
> DI Roman Fiedler
> Scientist
> Safety & Security Department
> Assistive Healthcare Information Technology
> 
> AIT Austrian Institute of Technology GmbH
> Reininghausstraße 13/1  |  8020 Graz  |  Austria
> T +43(0) 50550 2957  |  M +43(0) 664 8561599  |  F +43(0) 50550 2950
> roman.fiedler@....ac.at | http://www.ait.ac.at/
> 
> FN: 115980 i HG Wien  |  UID: ATU14703506
> http://www.ait.ac.at/Email-Disclaimer
> 


[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ