privilege escalation via ptrace (CVE-2016-8659)

[Yawning Angel]

Impact
======
bubblewrap 0.1.3 and 0.1.4 fix a security vulnerability. 0.1.5 has some minor improvements but also fixes the tests.

https://github.com/projectatomic/bubblewrap/releases

Test Case
=========
I'm not familiar enough with the code to have a test case for this.

Regression Potential
====================
Low because bubblewrap is currently only used by Flatpak. The Flatpak developers very strongly recommend updating bubblewrap to at least 0.1.4 but 0.1.5 fixes a few more issues.

See LP: #1649330 where there is some interest in using bubblewrap for some snap apps.

Other Info
==========
I just copied the Debian packaging from 0.1.5-1. The Debian packaging only updates debian/copyright and makes improvements to the build tests and autopkgtests.

Original Bug Report
===================

The bubblewrap package in yakkety (16.10) has a local privilege escalation vulnerability that's been fixed in upstream for a while. Debian has moved on to 0.1.3, but they had a 0.1.2-2 for a while that patched the vulnerability at a loss of functionality.

https://github.com/projectatomic/bubblewrap/issues/107
https://packages.qa.debian.org/b/bubblewrap.html

Note: I don't use Ubuntu, but software I maintain depends on bubblewrap, and having old known insecure packages is bad for my users.

[Tyler Hicks (tyhicks)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Jeremy Bícha (jbicha)]

I think it makes sense to just update this to 0.1.4 since 0.1.3 is just the security fix and 0.1.4 is further security fixes related to the same issue (and a few other bugfixes).

But the build tests don't work with 0.1.4 so we either need to patch them or just go with 0.1.5 which fixes the tests and a few more bugfixes.

Well it would be good to have 0.1.5 anyway, but I'm not sure how we want this to work as a security update. I uploaded bubblewrap0.1.5-1~ubuntu16.10.0 to the regular unapproved SRU queue now. What do you think about letting it age for 7 days after being accepted and then pushing it to yakkety-updates and yakkety-security?

Subscribing Security Sponsors for their input.

[Seth Arnold (seth-arnold)]

Thanks Jeremy for working on this; I think you're right, a backport from zesty makes sense. The diff is large and likely important for clients especially in the early stages of a library; backporting 'the fix' alone without the rest may introduce new issues; and tests are always good.

The trick is for this to be a security update, it needs to be built in a PPA with _only_ the -security pocket enabled.

Can you make that happen? I don't know enough about the rest of the SRU framework to know if the packages you've already submitted can be steered that way or if they'd need to be removed and built elsewhere first.

Thanks

[Marc Deslauriers (mdeslaur)]

I asked for the package to be removed from the upload queue. I will build it in the -security pocket, and will push it to -proposed for a week, as requested.

[Marc Deslauriers (mdeslaur)]

Jeremy, the updated package is now in yakkety-proposed. Please comment here when it's tested and you're ready for us to publish it in -security and -updates. Thanks!

[Jeremy Bícha (jbicha)]

Marc, thanks for the upload!

I'd like to get this version of bubblewrap into xenial also. It's needed to get flatpak working there. Similar to how snapd was backported to trusty into the -updates pocket, I think it makes sense for flatpak to land in the -updates pocket. Because bubblewrap is not in xenial at all now, the only ones who have it installed found it from some PPA.

So for xenial, do you want bubblewrap to go in to -security or -updates?

Flatpak doesn't look backportable to trusty so I don't need bubblewrap there. But like I mentioned earlier, it's possible that snap will use it eventually so it would need to be there then.

Anyway, if you upload to xenial (and optionally trusty), you can mention LP: #1649330 for that.

[Jeremy Bícha (jbicha)]

zesty's bubblewrap build-depends on debhelper 10 so we should lower that for xenial (which has dh10 in backports only)

[Marc Deslauriers (mdeslaur)]

For xenial, you need to go through the SRU team. It should go in -updates, not -security.

[William Hua (attente)]

In the context of LP: #1649330, I don't see any regressions from bubblewrap 0.1.5-1~ubuntu16.10.0 in yakkety-proposed, but I've only tested the simple case there within a VM. So:

bwrap --dev-bind / / --dev-bind ~ /snap bash

and then...

ls /snap
touch /snap/whatever
exit

then...

ls ~

still works.

I haven't tested to see that the CVE is fixed though, is there a short list of steps I can try to confirm the hostname can be changed?

[Alexander Larsson (alexlarsson)]

There is no easy way to test the CVE without changes to bwrap, because it involves ptracing the process tree while racing startup. When i tested the fix i inserted a sleep in the code and attached to it with strace to verify that it was possible to ptrace at that point. You can test it in a similar way i guess.

But basically, with 0.1.5 you should not be able to ptrace the setup code at all, even when using user namespaces (--unshare-user), and thus you can't hijack the code to make it do something weird.
Additionally, even if you were to ptrace the unprivileged part of the setup code you now can't ask for a hostname change unless a namespace for that was requested, so its even harder to test the CVE...

[William Hua (attente)]

Hi, I'm not sure what I've done wrong here, but I've added the sleep at line 1707 after the drop_caps call and tried to strace the child process without success.

This is the output I got:

strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf

But since it isn't clear how to confirm the new release doesn't contain the CVE anyways, could we mark this as verification-done and accept it into Ubuntu Yakkety?

[Jeremy Bícha (jbicha)]

I verified the non-security part of this update with flatpak since that's the only thing that uses bubblewrap.

With Ubuntu (Unity) 16.10:
sudo apt install flatpak
wget https://people.gnome.org/~alexl/keys/gnome-sdk.gpg
flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome http://sdk.gnome.org/repo/
flatpak --user install gnome org.gnome.Platform 3.22
flatpak --user remote-add --gpg-import=gnome-sdk.gpg gnome-apps http://sdk.gnome.org/repo-apps/
flatpak --user install gnome-apps org.gnome.Clocks stable

After I installed the updated bubblewrap, I also ran
flatpak --user install gnome-apps org.gnome.Todo stable

I logged out and logged back in for Unity to update its list of updated apps.

The Todo app has OnlyShowIn=Gnome; set so I used
flatpak run org.gnome.Todo

Both the GNOME Clocks app and the Todo app work. I'm marked this fix verified.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bubblewrap - 0.1.5-1~ubuntu16.10.0

---------------
bubblewrap (0.1.5-1~ubuntu16.10.0) yakkety-security; urgency=medium

  * SECURITY UPDATE: privilege escalation via ptrace (LP: #1643734)
    - Fixed in new upstream release 0.1.3
    - 0.1.4 further protects against possible ptrace attacks by dropping
      setcaps support and working around the Linux kernel allowing ptrace
      in user namespaces
    - CVE-2016-8659
  * Backport 0.1.5-1 from zesty for minor packaging improvements

bubblewrap (0.1.5-1) unstable; urgency=medium

  * New upstream release
    - drop all patches, applied upstream
    - debian/copyright: update for build system additions

bubblewrap (0.1.4-2) unstable; urgency=medium

  * d/tests/*: only run tests on a real or virtual machine, not in a
    container. bubblewrap is effectively already a container, and
    nesting containers doesn't work particularly well.
    Unfortunately this means the tests won't work on ci.debian.net,
    which uses LXC.

bubblewrap (0.1.4-1) unstable; urgency=medium

  * New upstream release
  * d/p/test-run-be-a-bash-script.patch,
    d/p/test-run-don-t-assume-we-are-uid-1000.patch,
    d/p/Adapt-tests-so-they-can-be-run-against-installed-binaries.patch,
    d/p/Fix-incorrect-nesting-of-backticks-when-finding-a-FUSE-mo.patch:
    improve the upstream tests
  * d/tests/upstream: run the upstream tests as autopkgtests
  * d/rules: Do not enable setuid mode at configure time. If we do, we
    can't run the build-time tests, and it no longer makes any difference
    to the actual code. Make the executable setuid via Debian packaging
    instead.

bubblewrap (0.1.3-1) unstable; urgency=medium

  * New upstream release
    - bring back --set-hostname, the upstream fix for CVE-2016-8659
      makes it no longer a vulnerability

bubblewrap (0.1.2-2) unstable; urgency=high

  * Revert addition of --set-hostname as a short-term fix for
    CVE-2016-8659 (Closes: #840605)

 -- Jeremy Bicha <email address hidden> Wed, 21 Dec 2016 12:43:27 -0500