Re: [vserver] Security issue: guest to host escape via TIOCSTI ioctl in vserver enter

From: Corey Wright <>
Date: Thu 08 Nov 2012 - 05:48:27 GMT
Message-Id: <>

On Thu, 8 Nov 2012 00:19:58 +0100
Herbert Poetzl <> wrote:

> On Wed, Nov 07, 2012 at 09:53:02PM +0000, halfdog wrote:
> > Hash: SHA1
> > Herbert Poetzl wrote:
> >> On Wed, Nov 07, 2012 at 04:13:48PM +0000, halfdog wrote: Security
> >> testing showed that when an admin enters a vserver guest from
> >> interactive shell, a malicious user inside the guest can use this
> >> to execute commands on the host. ...
> >>> TIOCSTI only works if enabled for a guest (VXC_TIOCSTI) so
> >>> unless you have found a bug to circumvent this, I think
> >>> Linux-VServer is not affected.
> > That's strange, perhaps I made some mistake during testing with
> > the packages from
> what kernel did you use for your tests?
> > Is VXC_TIOCSTI enabled by default, how to check that it is
> > really disabled.
> no, it shouldn't be enabled by default.
> you can check it either via 'vattribute --get ...'
> or by looking at the CCAPS in 'cat /proc/virtual/<xid>/status'
> VXC_TIOCSTI is defined as 0x00000010, so it is bit #4
> > And did you try to run the gdb-test?
> no, didn't try that yet
> > Were there any errors attaching to the process or during exec?
> > I'll try to run test-set again from completely fresh setup
> > as soon as possible. (or do you have a completely sane test
> > environment available?)
> new default installation should be sane, but also note that
> vserver <name> enter is only intended for emergency maintainance
> and not for occasional visits to a running and working guest
> (which you should better do via ssh)

"vserver ... enter" has always been presented on this mailing list as the
non-preferred solution to entering a guest as it has limitations.

but i also won't say that i never use it, just like i won't say that i never
"su postgres" to perform database maintenance. (no, i've never misconfigured
my postgresql acls or forgotten my database password. ;-)

> in any case, if TIOCSTI is possible inside a guest without
> VXC_TIOCSTI enabled, then there is a bug which needs to be fixed

my apologies if i'm speaking out of ignorance (as i will readily admit i'm
not an expert on linux/unix terminals) and showing myself to be an idiot,

the specific check for VXC_TIOCSTI (from patch-3.0.46-vs2.3.2.5.diff) is:

@@ -2080,7 +2081,8 @@ static int tiocsti(struct tty_struct *tt
        char ch, mbz = 0;
        struct tty_ldisc *ld;
- if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
+ if (((current->signal->tty != tty) &&
+ !vx_capable(CAP_SYS_ADMIN, VXC_TIOCSTI)))
                return -EPERM;
        if (get_user(ch, p))
                return -EFAULT;

so if the "acting from" and "act upon" ttys (if i understand them correctly)
match, then the if conditional is short-circuited and VXC_TIOCSTI is never
tested for.

in inspecting the output of vps (in the host context on tty1) while having
entered the guest from tty2, here's what i note:

 * process, context, terminal
 * -bash, host, tty2
 * login, guest, tty2
 * /bin/bash -login, guest, pts/1

the login process is executing within the guest context on the tty2 terminal,
which is shared by the initiating shell in the host context. presumably if
someone was to inject code into the login process on the guest, then it could
execute in the host context by way of TIOCSTI and the initiating shell and
the kernel check would not prevent it because the terminals are the same (ie
tty2) and the VXC_TIOCSTI capability would never be checked.

apart from "vserver ... enter", it appears that the check for VXC_TIOCSTI
provides the intended isolation between contexts (eg a user in guest1
can't interact with a terminal in guest2, even if that user is root),
similar to how linux provides isolation between users and their terminals
(apart from CAP_SYS_ADMIN).

if i made any stupid mistakes or foolish assumptions, then please do not
hesitate to correct me.


> best,
> Herbert
> >> [1]
> >>
> > - --
> >
> > PGP:
> > 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > gC0Aniqjm0QRUIZdhyTBIQaxdbKw7KCO
> > =8bfi
> > -----END PGP SIGNATURE-----
Received on Thu Nov 8 05:48:39 2012
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 08 Nov 2012 - 05:48:39 GMT by hypermail 2.1.8