On Wed, Nov 07, 2012 at 11:48:27PM -0600, Corey Wright wrote:
> On Thu, 8 Nov 2012 00:19:58 +0100
> Herbert Poetzl <herbert@13thfloor.at> wrote:
>> On Wed, Nov 07, 2012 at 09:53:02PM +0000, halfdog wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> 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 repo.psand.net.
>> 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,
> but...
> 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.
that sounds correct, but if we want to cover that case, we
have to disable TIOCSTI completely.
when enter is used, a host pts/tty is required, and if
you want to actually see/get output from that enter, this
pts/tty will have to be accessible inside the guest, so
AFAICT, there is no way to solve this case without
disabling TIOCSTI completely ...
note that I'm perfectly fine with disabling TIOCSTI on
a per guest or per host system level, but I was told
that there are legitimate applications using this 'feature'
best,
Herbert
> 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.
> corey
> --
> undefined@pobox.com
>> best,
>> Herbert
>>>> [1]
>>>> http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/
>>> - --
>>> http://www.halfdog.net/
>>> PGP:
>>> 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> iEYEARECAAYFAlCa19wACgkQxFmThv7tq+7vQQCfXFqKlbudPXCANMPoE0TUuETK
>>> gC0Aniqjm0QRUIZdhyTBIQaxdbKw7KCO
>>> =8bfi
>>> -----END PGP SIGNATURE-----
Received on Thu Nov 8 15:12:13 2012