[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 15 Dec 2014 18:00:54 +0000
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Multiple disputed issues in util-vserver
> Von: Fiedler Roman [mailto:Roman.Fiedler@....ac.at]
>
> [Snip]
>
> > > 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.
As there was not really much feedback from the vserver side and as there are
quite more issues with vserver I hoped to get rid of all those issues using
LXC. At least issue 3 is also with lxc-attach is quite the same, but
documentation of lxc-attach does not mention the risks either (at least on
Ubuntu). Calling
# lxc-attach --name buildhost-trusty -- /bin/ls
will create file outside when e.g. /bin/ls was replaced with
/root/TtyPushbackSignaling --NoSignal -- "touch /xxx"
So I guess one should not use attach to run e.g. automatic updates in the
guest or something alike.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (6344 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
