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 ). 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 . > 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  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 > >  > http://list.linux-vserver.org/archive?mss:6788:201410:moeiomapkoefmmdnmcji >  http://www.openwall.com/lists/oss-security/2012/11/05/8 >  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 > Download attachment "signature.asc" of type "application/pgp-signature" (884 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ