[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DJvRoKIuVbRyh3w6YppaTZqH1Dcid84FuuKxC6GKQeaXXt2iBfmnPlSvpDlx-wu52iIHxc6-aq7Hpa5PkpetzfBwyuo6NXmTzADSPd9LdG4=@itk.swiss>
Date: Tue, 28 Mar 2017 06:45:34 -0400
From: Stiepan <stie@....swiss>
To: oss-security@...ts.openwall.com
Cc: "857295@...s.debian.org" <857295@...s.debian.org>, Stéphane Graber <stgraber@...ntu.com>, serge.hallyn@...ntu.com
Subject: Re: LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
Thanks to the 2.0.7-2 update by Evgeni Golov and his crystal-clear instructions on how to use lxcbr0 with this version, I could confirm that the issue with the host's routing table being affected by changes in the containers' routing tables is not there anymore when using that version (lxc 2.0.7-2 from jessie-backports), which includes the fixes to CVE-2017-5985 which were brought in LXC 2.0.7 (upstream).
This was thus basically a variation of said CVE, which probably doesn't need to be separately numbered as such, the core problem at stake being the same:
network namespace ownership was not respected by a setuid-root program enabling the user to configure networks as non-root, which is now solved.
This leads me to a suggestion to the upstream developers: couldn't the same be achieved using specific network-related capabilities, instead of setuid-root, thereby further reducing the risk of lxc-user-nic being exploited and hence, reducing overall attack surface (in unprivileged mode)?
I have read in https://wiki.ubuntu.com/UserNamespace that the approach of using "targeted capabilities" was then considered. This is probably the closest to what I am suggesting (specifically for lxc-user-nic - the current approach with 1-1 uid mappings seems fine for network-unrelated things).
Stiepan
-------- Original Message --------
Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
Local Time: 15 March 2017 11:55 AM
UTC Time: 15 March 2017 10:56
From: stie@....swiss
To: oss-security@...ts.openwall.com
oss-security@...ts.openwall.com <oss-security@...ts.openwall.com>, 857295@...s.debian.org <857295@...s.debian.org>, Stéphane Graber <stgraber@...ntu.com>, serge.hallyn@...ntu.com
I have found a workaround to start the container in user mode again on Debian 8:
use a "true" br0 bridge instead of lxc-br0 and disable, or stop the lxc-net service.
Under these conditions, using lxc 2.0.7(-1) from jessie-backports, I am not able to reproduce the routing issue I saw running lxc 2.0.6 in user mode using lxc-net. So a safe fallback (for Debian 8), for the time being, seems to be to avoid using user mode lxc networking and use a plain old br0 instead. This should work on all CPU architectures (even on powerpc, known to be recalcitrant to lxc on Debian 8).
Stiepan
-------- Original Message --------
Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
Local Time: 14 March 2017 5:17 PM
UTC Time: 14 March 2017 16:17
From: stie@....swiss
To: oss-security@...ts.openwall.com <oss-security@...ts.openwall.com>, 857295@...s.debian.org <857295@...s.debian.org>
Stéphane Graber <stgraber@...ntu.com>, serge.hallyn@...ntu.com
You are welcome. As stated in my reply to Serge H. Hallyn's off-list message, in the meantime I have installed version 2.0.7 from jessie-backports and am unable to reproduce the issue, as I cannot start unprivileged containers anymore (due to a network error). According to Debian's tracker page for lxc, the version that I have installed from backports is 2.0.7-1, which does not include latest upstream fixes. I guess that I have to wait for the 2.0.7-2 package - which includes latest upstream fixes - to land in jessie-backports for these issues (both security and functional) to be fixed.
CC-ing the Debian address for this bug, as they explicitly asked to do this in case there is a need to reopen the Debian bug, which seems to be the case here (at least, for Jessie, since the intermediary 2.0.7-1 .deb apparently breaks unprivileged networking, besides not fixing the security issue).
To the Debian team in charge of this bug:
As unprivileged mode is not activated by default on Debian, I understand that this is not a priority, but it would still be nice to have this fixed quickly.
By the way, not directly related to this specific bug, but I hope that snapd + LXD somehow finds its way into jessie-backports: that would be great!
Stiepan
-------- Original Message --------
Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
Local Time: 14 March 2017 2:06 AM
UTC Time: 14 March 2017 01:07
From: tyhicks@...onical.com
To: oss-security@...ts.openwall.com
Stéphane Graber <stgraber@...ntu.com>, serge.hallyn@...ntu.com
On 03/10/2017 06:03 AM, Stiepan wrote:
> I don't know whether that is the same bug, or a related one, but on Debian8 using LXC from jessie-backports, setting the default route in a container affects the host - namely, from an unpriv. container, setting the route sets the host's route as well.
> lxc-info --version outputs 2.0.6 and no update is currently available (on Debian).
Thanks for the report. I just tried to reproduce the issue on Ubuntu
16.04 with 2.0.7-0ubuntu1~16.04.2, which is the package patched for the
issue that I announced in this thread. I couldn't reproduce it.
I then installed an old 2.0.6 based deb (2.0.6-0ubuntu1~ubuntu16.04.1)
and still couldn't reproduce it.
I'd suggest opening an upstream bug here:
https://github.com/lxc/lxc/issues/new
(Normally, they prefer private security bugs on Launchpad but your
report to this list is already public so I don't see a need.)
Tyler
> Stiepan
>
>
>
> -------- Original Message --------
> Subject: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
> Local Time: 9 March 2017 5:54 PM
> UTC Time: 9 March 2017 16:55
> From: tyhicks@...onical.com
> To: oss-security@...ts.openwall.com
> Stéphane Graber <stgraber@...ntu.com>
>
> Jann Horn discovered that the lxc-user-nic program could be tricked into
> operating on a network namespace over which the caller did not hold
> privilege.
>
> The behavior didn't follow what was documented in the lxc-user-nic(1)
> man page:
>
> It ensures that the calling user is privileged over the network
> namespace to which the interface will be attached.
>
> This issue is CVE-2017-5985.
>
> https://lists.linuxcontainers.org/pipermail/lxc-users/2017-March/012925.html
> https://launchpad.net/bugs/1654676
> https://github.com/lxc/lxc/commit/16af238036a5464ae8f2420ed3af214f0de875f9
>
> Tyler
>
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.
