lxc: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Debian Bug report logs - #857295
lxc: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lxc: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Thu, 09 Mar 2017 18:57:25 +0100

Source: lxc
Version: 1:1.0.6-6
Severity: grave
Tags: patch upstream security
Justification: user security hole

Hi,

the following vulnerability was published for lxc, filling it with RC
severity, should possibly be fixed in stretch before the release,
although we do not enable user namespaces by default.

CVE-2017-5985[0]:
lxc-user-nic didn't verify network namespace ownership

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-5985
[1] https://lists.linuxcontainers.org/pipermail/lxc-users/2017-March/012925.html
[2] https://launchpad.net/bugs/1654676
[3] https://github.com/lxc/lxc/commit/16af238036a5464ae8f2420ed3af214f0de875f9

Regards,
Salvatore

Message #10 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: 857295@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>

Subject: Re: Bug#857295: lxc: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Thu, 9 Mar 2017 19:07:21 +0100

Hi,

On Thu, Mar 09, 2017 at 06:57:25PM +0100, Salvatore Bonaccorso wrote:
> Source: lxc
> Version: 1:1.0.6-6
> Severity: grave
> Tags: patch upstream security
> Justification: user security hole
> 
> Hi,
> 
> the following vulnerability was published for lxc, filling it with RC
> severity, should possibly be fixed in stretch before the release,
> although we do not enable user namespaces by default.

FTR, for jessie I think this can go with the next point release, and
does not necessarly need a DSA.

Regards,
Salvatore

Message #17 received at 857295-close@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: 857295-close@bugs.debian.org

Subject: Bug#857295: fixed in lxc 1:2.0.7-2

Date: Sat, 11 Mar 2017 10:03:37 +0000

Source: lxc
Source-Version: 1:2.0.7-2

We believe that the bug you reported is fixed in the latest version of
lxc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 857295@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Evgeni Golov <evgeni@debian.org> (supplier of updated lxc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 11 Mar 2017 09:47:20 +0100
Source: lxc
Binary: lxc lxc-dev lxc-tests liblxc1 python3-lxc lua-lxc
Architecture: source
Version: 1:2.0.7-2
Distribution: unstable
Urgency: high
Maintainer: pkg-lxc <pkg-lxc-devel@lists.alioth.debian.org>
Changed-By: Evgeni Golov <evgeni@debian.org>
Description:
 liblxc1    - Linux Containers userspace tools (library)
 lua-lxc    - Linux Containers userspace tools (Lua bindings)
 lxc        - Linux Containers userspace tools
 lxc-dev    - Linux Containers userspace tools (development)
 lxc-tests  - Linux Containers userspace tools (test binaries)
 python3-lxc - Linux Containers userspace tools (Python 3.x bindings)
Closes: 857295
Changes:
 lxc (1:2.0.7-2) unstable; urgency=high
 .
   * use bash-completion's pkg-config support and don't move files around
   * ignore lxc-test-cloneconfig if kernel has no overlay support
   * CVE-2017-5985: Ensure target netns is caller-owned (Closes: #857295)
Checksums-Sha1:
 f9290865d7b156c43f4a0d507f7fe5d5c7fd0327 2619 lxc_2.0.7-2.dsc
 08d6f7dfe69514c6710577445a5003adc0756d98 84520 lxc_2.0.7-2.debian.tar.xz
 27ec3524cba3db28f39d41f92766ba436014e07b 7803 lxc_2.0.7-2_source.buildinfo
Checksums-Sha256:
 7ffd186c751e571082005e03735b40e9f643ba4f1a92631759f0b6e66855a60b 2619 lxc_2.0.7-2.dsc
 8ab21fc7805c6c27ac8647bcaacd23b4151c7f5601d824c4e3ecebf06c4544d9 84520 lxc_2.0.7-2.debian.tar.xz
 5e1d6941ea4e911df8485ba1ccc2e88bd0d558f024c84c90cfb0dcdde5ac81cc 7803 lxc_2.0.7-2_source.buildinfo
Files:
 179a233a30cf61537a15cbcbefdb9449 2619 admin optional lxc_2.0.7-2.dsc
 5604ed2d7f44ad3efc7600c016f667b3 84520 admin optional lxc_2.0.7-2.debian.tar.xz
 d38cfe174074a807f5432beb49365be4 7803 admin optional lxc_2.0.7-2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEExXWpV+gZuhi/B+dmobCbQjM5YegFAljDxvgACgkQobCbQjM5
YeiaQRAAtBfPbHhetUrXKR9uAUa/slXNOkTPXXr/JDIxQo6h0pALGhqJKVG1d46v
3Eg8Efuu7EBxU5Vy1qRrz318vnj5HEs9sdlbU9chUO82lXVivCgCE4+75xRBtpKU
mfgTNGsIMWEz1iDQElkZqc/rvXzrA3CY57c0C77FIBKS39058sF2Jga1xvXserDk
xSb3RyMDlfIWtfV8oUmXFk1bBj5u7Y0fA3l/15i4yrxvMvH2jLCCEDFks/oXFVfZ
xnYuL5mnzwA94UmxhrcPAymtvmQDEnwmOm5+8e/kwj/k9oODfwEUqpEm3fm1o2aE
GGy2mOvSoBXO87AiiMEDxh6QBe3pQaG3jmxsR5+VAWeRRc4rlU89TL9kjfZ1R5OA
f8NyXL7fJcSS9wekYM7Ll/USV2LMcbf0Gw2ypOTn3goX1zKRqITSiHNpamP8JlfI
G35CpLI+ugmSE3zmIlOGLL6aum7pDBlIJNbF6tA9Gu1tOP8HtWBkmAFsV0Py2wCF
1l10gksnu/sMSn4BkbCsxIMzjtpBDWX8gxUfO6F2X6ean0ehtlQ85YY/J2eMF7Me
DW5xcbJNfvKmGczUr2Nl2d/c7X345SWahKXOYQpU6Zt925o7mB5mpDum6+bW6gge
ndNgViWk+jEZZr49Upz+r3KtVo9rJkGJlGOFiQJSYC6m1kiI33k=
=AUlS
-----END PGP SIGNATURE-----

Message #22 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: "oss-security@lists.openwall.com" <oss-security@lists.openwall.com>, "857295@bugs.debian.org" <857295@bugs.debian.org>

Cc: Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@ubuntu.com

Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Tue, 14 Mar 2017 12:17:53 -0400

[Message part 1 (text/plain, inline)]

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@canonical.com
To: oss-security@lists.openwall.com
Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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: tyhicks@canonical.com
> To: oss-security@lists.openwall.com
> Stéphane Graber <stgraber@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
>

[Message part 2 (text/html, inline)]

Message #27 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: oss-security@lists.openwall.com

Cc: "857295@bugs.debian.org" <857295@bugs.debian.org>, Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@ubuntu.com

Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Wed, 15 Mar 2017 06:56:19 -0400

[Message part 1 (text/plain, inline)]

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-security@lists.openwall.com <oss-security@lists.openwall.com>, 857295@bugs.debian.org <857295@bugs.debian.org>
Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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: tyhicks@canonical.com
To: oss-security@lists.openwall.com
Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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: tyhicks@canonical.com
> To: oss-security@lists.openwall.com
> Stéphane Graber <stgraber@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
>

[Message part 2 (text/html, inline)]

Message #32 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: 857295@bugs.debian.org

Subject: Re: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)

Date: Fri, 24 Mar 2017 05:03:57 -0400

[Message part 1 (text/plain, inline)]

Fyi, now that lxc 2.0.7-2 landed in jessie-backports, I am getting a new error when trying to start an lxc instance (running jessie as well) using a virtual br0 rather than "plain old" br0 (all of this in unprivileged mode), namely: lxc_delete_network:3028 - Failed to remove interface "vethXJW6PL" from host: Operation not permitted. With "plain old" br0, it still works as expected.

Stiepan

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-------- Original Message --------
Subject: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)
Local Time: 15 March 2017 11:56 AM
UTC Time: 15 March 2017 10:57
From: owner@bugs.debian.org
To: Stiepan <stie@itk.swiss>

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
pkg-lxc <pkg-lxc-devel@lists.alioth.debian.org>

If you wish to submit further information on this problem, please
send it to 857295@bugs.debian.org.

Please do not send mail to owner@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
857295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857295
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[Message part 2 (text/html, inline)]

Message #37 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: Stiepan <stie@itk.swiss>, 857295@bugs.debian.org

Subject: Re: [pkg-lxc-devel] Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)

Date: Fri, 24 Mar 2017 10:17:59 +0100

Hi,

On Fri, Mar 24, 2017 at 05:03:57AM -0400, Stiepan wrote:
> Fyi, now that lxc 2.0.7-2 landed in jessie-backports, I am getting a new error when trying to start an lxc instance (running jessie as well) using a virtual br0 rather than "plain old" br0 (all of this in unprivileged mode), namely: lxc_delete_network:3028 - Failed to remove interface "vethXJW6PL" from host: Operation not permitted. With "plain old" br0, it still works as expected.

Can you alaborate a bit more on your network setup please?
What is a "virtual br0"? How do you you set this up?

My setup uses brctl to setup the bridge and then unpviliged containers
work fine. I guess that is "plain old" for ya?

Regards
Evgeni

Message #42 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: Evgeni Golov <evgeni@debian.org>

Cc: 857295@bugs.debian.org

Subject: Re: [pkg-lxc-devel] Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)

Date: Fri, 24 Mar 2017 10:51:24 -0400

[Message part 1 (text/plain, inline)]

Hi,

Using a bridge set up with libvirt (as in http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29) doesn't work.
Neither does using a bridge set up as indicated in https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net (causes the same errors as with libvirt).
Using a classical / "plain old" / you-name-it bridge, set up as in http://wiki.libvirt.org/page/Networking#Altering_the_interface_config, does work.

By the way, the lxc_delete_network:3028... additional error I was seeing pops up only when /etc/lxc/lxc-usernet is still set to use br0, whilst the LXC container is set to use virbr0 and hence can be ignored, sorry about that. When properly configured (i.e. when both are configured to use virbr0, or lxcbr0), container startup simply fails with a "Failed to create the configured network" error, but still fails, whereas when using classical br0, it works.

So, if your bridge is set up as suggested in https://wiki.debian.org/BridgeNetworkConnections' Manual bridge setup section, using either brctl or /etc/network/interfaces (for a persistent config), we have the same configuration and it works, which is fine. Still, I thought that LXC enabled using lxcbr0 bridges in user mode, as lxc-user-nic's man page suggests is possible. Can you confirm whether this is the case with the current version?

Regards,
Stiepan

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-------- Original Message --------
Subject: Re: [pkg-lxc-devel] Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)
Local Time: 24 March 2017 10:17 AM
UTC Time: 24 March 2017 09:17
From: evgeni@debian.org
To: Stiepan <stie@itk.swiss>, 857295@bugs.debian.org

Hi,

On Fri, Mar 24, 2017 at 05:03:57AM -0400, Stiepan wrote:
> Fyi, now that lxc 2.0.7-2 landed in jessie-backports, I am getting a new error when trying to start an lxc instance (running jessie as well) using a virtual br0 rather than "plain old" br0 (all of this in unprivileged mode), namely: lxc_delete_network:3028 - Failed to remove interface "vethXJW6PL" from host: Operation not permitted. With "plain old" br0, it still works as expected.

Can you alaborate a bit more on your network setup please?
What is a "virtual br0"? How do you you set this up?

My setup uses brctl to setup the bridge and then unpviliged containers
work fine. I guess that is "plain old" for ya?

Regards
Evgeni

[Message part 2 (text/html, inline)]

Message #47 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: Stiepan <stie@itk.swiss>, 857295@bugs.debian.org

Subject: Re: [pkg-lxc-devel] Bug#857295: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)

Date: Sun, 26 Mar 2017 12:17:54 +0200

Hi Stiepan,

On Fri, Mar 24, 2017 at 10:51:24AM -0400, Stiepan wrote:

> Using a bridge set up with libvirt (as in http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29) doesn't work.

Is that what the libvirt package does on Debian out-of-the-box?
If so it works just fine for me on my laptop where I put the containers on the vibr0 created by libvirt.

> Neither does using a bridge set up as indicated in https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net (causes the same errors as with libvirt).

So I just fired a fresh jessie+backports Vagrant box and it worked fine (incl network in the container):

$ vagrant init debian/jessie64
$ vagrant up
$ vagrant ssh

vagrant@jessie:~$ sudo nano /etc/apt/sources.list
deb http://httpredir.debian.org/debian jessie-backports main

vagrant@jessie:~$ sudo apt update

vagrant@jessie:~$ sudo apt install lxc/jessie-backports lxcfs

vagrant@jessie:~$ sudo nano /etc/default/lxc-net
USE_LXC_BRIDGE="true"

vagrant@jessie:~$ systemctl enable lxc-net
vagrant@jessie:~$ systemctl restart lxc-net

vagrant@jessie:~$ ip a s dev lxcbr0
3: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 scope global lxcbr0
       valid_lft forever preferred_lft forever

vagrant@jessie:~$ sudo sysctl -w kernel.unprivileged_userns_clone=1

vagrant@jessie:~$ exit # needed to trigger lxcfs' PAM module

$vagrant ssh

vagrant@jessie:~$ cat /proc/self/cgroup 
8:perf_event:/
7:blkio:/
6:net_cls,net_prio:/
5:freezer:/user/vagrant/0
4:devices:/
3:cpu,cpuacct:/
2:cpuset:/
1:name=systemd:/user/vagrant/0

vagrant@jessie:~$ mkdir ~/.config/lxc/ -p

vagrant@jessie:~$ nano ~/.config/lxc/default.conf 
xc.include = /etc/lxc/default.conf
lxc.id_map = u 0 624288 65536
lxc.id_map = g 0 624288 65536

vagrant@jessie:~$ sudo nano /etc/lxc/lxc-usernet
vagrant veth lxcbr0 10

vagrant@jessie:~$ lxc-create -n jessie -t download -- -d debian -r jessie -a amd64

vagrant@jessie:~$ nano .local/share/lxc/jessie/config 
lxc.network.type=veth 
lxc.network.flags=up 
lxc.network.link=lxcbr0 

vagrant@jessie:~$ lxc-start -n jessie
vagrant@jessie:~$ lxc-ls -f
NAME   STATE   AUTOSTART GROUPS IPV4 IPV6 
jessie RUNNING 0         -      -    -    


> Using a classical / "plain old" / you-name-it bridge, set up as in http://wiki.libvirt.org/page/Networking#Altering_the_interface_config, does work.

I don't see any technical difference between the plain br0 setup with this link and the ones created by lxc-net or libvirt.
Can you point them out please?

> By the way, the lxc_delete_network:3028... additional error I was seeing pops up only when /etc/lxc/lxc-usernet is still set to use br0, whilst the LXC container is 
> set to use virbr0 and hence can be ignored, sorry about that. When properly configured (i.e. when both are configured to use virbr0, or lxcbr0), container startup 
> simply fails with a "Failed to create the configured network" error, but still fails, whereas when using classical br0, it works.

Can you please provide the steps how to setup your setup from a plain jessie or stretch image?

> So, if your bridge is set up as suggested in https://wiki.debian.org/BridgeNetworkConnections' Manual bridge setup section, using either brctl or 
> /etc/network/interfaces (for a persistent config), we have the same configuration and it works, which is fine. Still, I thought that LXC enabled using lxcbr0 bridges 
> in user mode, as lxc-user-nic's man page suggests is possible. Can you confirm whether this is the case with the current version?

lxc-user-nic is to attach a user-namespace-nic to an existing bridge, you can't create a bridge with it.

Message #52 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: Evgeni Golov <evgeni@debian.org>, "857295@bugs.debian.org" <857295@bugs.debian.org>

Subject: Re: [pkg-lxc-devel] Bug#857295: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)

Date: Tue, 28 Mar 2017 05:41:02 -0400

[Message part 1 (text/plain, inline)]

Hi Evgeni,

First of all, thank you for posting the detailed steps you used to reproduce a working config, which is by far the best explanation on how to set up LXC for running Debian 8 on top of Debian 8 I have seen yet.

To answer your questions, yes I've been using Jessie's libvirt package "as is". No idea why it doesn't work. However, by following your explanation, I was able to reproduce a working config, using user-mode networking and lxcbr0, on i386, with only minor adaptations and on ppc64, with one big difference: cgmanager has to be used there (see https://linuxcontainers.org/cgmanager/getting-started/) for LXC to run in unprivileged mode, with or without networking, be it using br0 or lxcbr0. Hence, this, in combination with your explanation, makes it work on both architectures I could test.

About br0 v.s. lxcbr0: the main difference between them is the fact that the latter involves running dnsmasq in the background (and therefore has firewall implications, namely an iptables rule is added) to provide ip masquerading (that is, NAT) to the containers.
Note: containerops.org/2013/11/19/lxc-networking provides in-depth coverage of the subject + also covers linux network namespaces in general.

Regarding how to setup our setups:
I think that the Debian wiki on LXC, https://wiki.debian.org/LXC, should be updated with your simplified method - save for the vagrant part of it - and eventually, my architecture-specific notes as well, as I remember reading in a 2.0.7-1-related post that powerpc compatibility was seen as an issue.

As for your last comment, I agree that bridges, be it br0 or lxcbr0, have to be created by root; I was referring to using them as an unprivileged user.

Last but not least, the security bug I had spotted was most likely equivalent to CVE-2017-5985, as I could not reproduce it now that it works again using a lxcbr0 bridge as well (setting the default route in an unprivileged container using user-mode networking does not affect the host anymore), when running lxc 2.0.7-2 from jessie-backports (which includes the fixes for the aforementioned CVE). I will post an update on oss-security with the security-relevant part of this thread.

Stiepan

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-------- Original Message --------
Subject: Re: [pkg-lxc-devel] Bug#857295: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)
Local Time: 26 March 2017 12:17 PM
UTC Time: 26 March 2017 10:17
From: evgeni@debian.org
To: Stiepan <stie@itk.swiss>, 857295@bugs.debian.org

Hi Stiepan,

On Fri, Mar 24, 2017 at 10:51:24AM -0400, Stiepan wrote:

> Using a bridge set up with libvirt (as in http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29) doesn't work.

Is that what the libvirt package does on Debian out-of-the-box?
If so it works just fine for me on my laptop where I put the containers on the vibr0 created by libvirt.

> Neither does using a bridge set up as indicated in https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net (causes the same errors as with libvirt).

So I just fired a fresh jessie+backports Vagrant box and it worked fine (incl network in the container):

$ vagrant init debian/jessie64
$ vagrant up
$ vagrant ssh

vagrant@jessie:~$ sudo nano /etc/apt/sources.list
deb http://httpredir.debian.org/debian jessie-backports main

vagrant@jessie:~$ sudo apt update

vagrant@jessie:~$ sudo apt install lxc/jessie-backports lxcfs

vagrant@jessie:~$ sudo nano /etc/default/lxc-net
USE_LXC_BRIDGE="true"

vagrant@jessie:~$ systemctl enable lxc-net
vagrant@jessie:~$ systemctl restart lxc-net

vagrant@jessie:~$ ip a s dev lxcbr0
3: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 scope global lxcbr0
valid_lft forever preferred_lft forever

vagrant@jessie:~$ sudo sysctl -w kernel.unprivileged_userns_clone=1

vagrant@jessie:~$ exit # needed to trigger lxcfs' PAM module

$vagrant ssh

vagrant@jessie:~$ cat /proc/self/cgroup
8:perf_event:/
7:blkio:/
6:net_cls,net_prio:/
5:freezer:/user/vagrant/0
4:devices:/
3:cpu,cpuacct:/
2:cpuset:/
1:name=systemd:/user/vagrant/0

vagrant@jessie:~$ mkdir ~/.config/lxc/ -p

vagrant@jessie:~$ nano ~/.config/lxc/default.conf
xc.include = /etc/lxc/default.conf
lxc.id_map = u 0 624288 65536
lxc.id_map = g 0 624288 65536

vagrant@jessie:~$ sudo nano /etc/lxc/lxc-usernet
vagrant veth lxcbr0 10

vagrant@jessie:~$ lxc-create -n jessie -t download -- -d debian -r jessie -a amd64

vagrant@jessie:~$ nano .local/share/lxc/jessie/config
lxc.network.type=veth
lxc.network.flags=up
lxc.network.link=lxcbr0

vagrant@jessie:~$ lxc-start -n jessie
vagrant@jessie:~$ lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6
jessie RUNNING 0 - - -

> Using a classical / "plain old" / you-name-it bridge, set up as in http://wiki.libvirt.org/page/Networking#Altering_the_interface_config, does work.

I don't see any technical difference between the plain br0 setup with this link and the ones created by lxc-net or libvirt.
Can you point them out please?

> By the way, the lxc_delete_network:3028... additional error I was seeing pops up only when /etc/lxc/lxc-usernet is still set to use br0, whilst the LXC container is
> set to use virbr0 and hence can be ignored, sorry about that. When properly configured (i.e. when both are configured to use virbr0, or lxcbr0), container startup
> simply fails with a "Failed to create the configured network" error, but still fails, whereas when using classical br0, it works.

Can you please provide the steps how to setup your setup from a plain jessie or stretch image?

> So, if your bridge is set up as suggested in https://wiki.debian.org/BridgeNetworkConnections' Manual bridge setup section, using either brctl or
> /etc/network/interfaces (for a persistent config), we have the same configuration and it works, which is fine. Still, I thought that LXC enabled using lxcbr0 bridges
> in user mode, as lxc-user-nic's man page suggests is possible. Can you confirm whether this is the case with the current version?

lxc-user-nic is to attach a user-namespace-nic to an existing bridge, you can't create a bridge with it.

[Message part 2 (text/html, inline)]

Message #57 received at 857295@bugs.debian.org (full text, mbox, reply):

From: Stiepan <stie@itk.swiss>

To: oss-security@lists.openwall.com

Cc: "857295@bugs.debian.org" <857295@bugs.debian.org>, Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@ubuntu.com

Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Tue, 28 Mar 2017 06:45:34 -0400

[Message part 1 (text/plain, inline)]

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-security@lists.openwall.com
oss-security@lists.openwall.com <oss-security@lists.openwall.com>, 857295@bugs.debian.org <857295@bugs.debian.org>, Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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-security@lists.openwall.com <oss-security@lists.openwall.com>, 857295@bugs.debian.org <857295@bugs.debian.org>
Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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: tyhicks@canonical.com
To: oss-security@lists.openwall.com
Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@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: tyhicks@canonical.com
> To: oss-security@lists.openwall.com
> Stéphane Graber <stgraber@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
>

[Message part 2 (text/html, inline)]

Message #62 received at 857295@bugs.debian.org (full text, mbox, reply):

From: "Serge E. Hallyn" <serge@hallyn.com>

To: oss-security@lists.openwall.com

Cc: "857295@bugs.debian.org" <857295@bugs.debian.org>, Stéphane Graber <stgraber@ubuntu.com>, serge.hallyn@ubuntu.com

Subject: Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership

Date: Tue, 28 Mar 2017 09:49:04 -0500

On Tue, Mar 28, 2017 at 06:45:34AM -0400, Stiepan wrote:
> 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).

The targeted capabilities wouldn't help here, because in fact
lxc-user-nic requires privilege against the parent namespace.

-serge

Message #67 received at 857295-close@bugs.debian.org (full text, mbox, reply):

From: Evgeni Golov <evgeni@debian.org>

To: 857295-close@bugs.debian.org

Subject: Bug#857295: fixed in lxc 1:1.0.6-6+deb8u6

Date: Sat, 29 Apr 2017 19:32:13 +0000

Source: lxc
Source-Version: 1:1.0.6-6+deb8u6

We believe that the bug you reported is fixed in the latest version of
lxc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 857295@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Evgeni Golov <evgeni@debian.org> (supplier of updated lxc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 11 Mar 2017 10:42:30 +0100
Source: lxc
Binary: lxc lxc-dbg
Architecture: source amd64
Version: 1:1.0.6-6+deb8u6
Distribution: jessie
Urgency: medium
Maintainer: Daniel Baumann <mail@daniel-baumann.ch>
Changed-By: Evgeni Golov <evgeni@debian.org>
Description:
 lxc        - Linux Containers userspace tools
 lxc-dbg    - Linux Containers userspace tools (debug)
Closes: 857295
Changes:
 lxc (1:1.0.6-6+deb8u6) jessie; urgency=medium
 .
   * CVE-2017-5985: Ensure target netns is caller-owned (Closes: #857295)
Checksums-Sha1:
 f62ccb9c9b549dd6a7923965358a3a4f81563654 2096 lxc_1.0.6-6+deb8u6.dsc
 e38eaaff508b0409fe7eadbdcf2f9f5b1fd3a736 40312 lxc_1.0.6-6+deb8u6.debian.tar.xz
 3f92feb5fcfc3ff6d2a8f11f2b5551cf685be972 625298 lxc_1.0.6-6+deb8u6_amd64.deb
 855add20de14eb4230989717e6d3633bf8fb8806 773544 lxc-dbg_1.0.6-6+deb8u6_amd64.deb
Checksums-Sha256:
 2fab944cd9ce01b3c88817da00793dd5ae03c9e36c1116c1bcc992deae57ece4 2096 lxc_1.0.6-6+deb8u6.dsc
 7a34fc42bb07e6627e3591f164d2af28b0abc6c54cfaef43c73cba59f0a8408a 40312 lxc_1.0.6-6+deb8u6.debian.tar.xz
 f9b3772385ec614e08c85bf965c6624ff988bf159cc10b4ba483342121e20182 625298 lxc_1.0.6-6+deb8u6_amd64.deb
 f985a9d245ace202d9d9cece72b0ee96519ee3eb3b78df18a8b7ff4050ca953b 773544 lxc-dbg_1.0.6-6+deb8u6_amd64.deb
Files:
 41f67174489d339fbedd3d11213565d9 2096 admin optional lxc_1.0.6-6+deb8u6.dsc
 891a1c1f4e1a804f00a04cbbfb58a099 40312 admin optional lxc_1.0.6-6+deb8u6.debian.tar.xz
 2b43d53c9b557919a6727e3aa6d13ede 625298 admin optional lxc_1.0.6-6+deb8u6_amd64.deb
 97a3c669a5addb5e67cba4da66024226 773544 debug extra lxc-dbg_1.0.6-6+deb8u6_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEExXWpV+gZuhi/B+dmobCbQjM5YegFAlkEPDgACgkQobCbQjM5
YehxShAA1LxrJ+2WR95eek4YatFSYeQ34Uqvv+R8ekmEI5io1+DaUxWEmfFm8WsZ
uKd0Prz7vuW8DV5u6y+GuYfA2vcZE+djgPComgmiGLY0T+QbQO+YxGxoaUjaC67n
y+ODw9WPtAu6qH8+JNBoeo5DxaVf+impWEPalJVt6FxBejhDrUzuimLSlAS2O7GO
/ow0d0xC2Qu8CKMa5AS4GqZee1CDOMqyTW+3W/fTayWEjMp8SfDmvYEsL0y774+E
gdEb5v4vY1JDxdCXkAKF5gBwGUOuTYJNkojLKuFg3vHMAGDSAhXry7HDgViRr9NM
LsX5PCH4qIZG1u/SZjO5Wxgr0n1KWcq2CR8AIl2R5nYDjy3IrDwRqWg1qNQtKZd+
3h+sLxphu7IzniabbdKTs2Ap+gbor7Jx7/E8eGyfFS2lfw4wCMbUA3njuj4w39d7
+jtX1NZ77IRW8IcxvHbef5LsF55KX4wTXHA8P5H2Spvr174JuGH1DzBQHigdSf5k
F/Km5XTzeM6z/Ft62Ptdgg6on3n3JjV2dddn4YO/N0YAEhF1KlAhfeLv/KeYZBWZ
PjTEcIHVJi1rWLySCpiGaQdaog3JH9Yt5++LyeGGF24e3upuMtTw/dp2MiuDP7e9
0TvdT2NYPDso5vBeUUJ79h+gKXmEwPAtf1tNryI9mhdlO7UeiYg=
=SEAO
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.