AW: Multiple disputed issues in util-vserver

[Fiedler Roman <Roman.Fiedler () ait ac at>]

Hello Carlos,


> Von: Carlos Alberto Lopez Perez [mailto:clopez () igalia com]
>
> 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)?

For code execution, I would guess, this should be less of a risk. The only
thing, I could think of, is that if namespace separation is not completely
clean, that it might be somehow possible, that the guest process (uid=0)
being the parent of the host process finds some way to ptrace et al control
the host process.

DOS might be more likely, therefore a malicious guest process just would
have to fill up the guest pid namespace until e.g. only some PIDs usually
occupied by swapper, IRQ-handler, ssh daemon ... on host are free in guest.
After reparenting, a host process might send a deadly signal to the wrong
parent. I do not known, if this is really a relevant scenario (therefore
asking about this), since even with cgroups/quota and all other things in
place, a guest might find other ways to starve the whole machine to death,
hence not needing such tricks.

> > 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 ?

Sent off-list

> > 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

Yes, this is the stuff about the general problem, this issue is quite a
similar one for su. In both cases (su and vserver), a tool used to enter an
possibly compromised, lower privileged context from a higher privileged one
fail.

The CVE is only for su. For su it seems, that the issue is treated more a
bug than expected feature, but it seems, that it is still not fixed for
current Ubuntu release.

For vserver ...

> > From my point of view, those issues might be expected behavior as
claimed by
> > the developers, ....>

this is the state of discussion, so no bug.

> > ... 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

This should handle the pty issues. But since it requires the admin not to
forget to use the manual workaround EVERY TIME, therefore man page update
should be done in any case. Fix with pty allocation (or detaching from pty
for vserver start) would be best solution. Without technical fix a
"--do-it-insecure" parameter would make it clear on command line, that I
want to proceed knowing the risks.
 
> > [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

Attachment: smime.p7s
Description: