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@itk.swiss To: oss-secur...@lists.openwall.com oss-secur...@lists.openwall.com <oss-secur...@lists.openwall.com>, 857...@bugs.debian.org <857...@bugs.debian.org>, Stéphane Graber <stgra...@ubuntu.com>, serge.hal...@ubuntu.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@itk.swiss To: oss-secur...@lists.openwall.com <oss-secur...@lists.openwall.com>, 857...@bugs.debian.org <857...@bugs.debian.org> Stéphane Graber <stgra...@ubuntu.com>, serge.hal...@ubuntu.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: tyhi...@canonical.com To: oss-secur...@lists.openwall.com Stéphane Graber <stgra...@ubuntu.com>, serge.hal...@ubuntu.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: tyhi...@canonical.com > To: oss-secur...@lists.openwall.com > Stéphane Graber <stgra...@ubuntu.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 >
