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.fied...@ait.ac.at | http://www.ait.ac.at/ > > FN: 115980 i HG Wien | UID: ATU14703506 > http://www.ait.ac.at/Email-Disclaimer >
signature.asc
Description: OpenPGP digital signature
