qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| qemu (Debian) |
Confirmed
|
Unknown
|
||
| qemu (Ubuntu) |
High
|
Christian Ehrhardt | ||
| Trusty |
Undecided
|
Ubuntu Security Team | ||
| Xenial |
Undecided
|
Ubuntu Security Team | ||
| Bionic |
High
|
Ubuntu Security Team | ||
| Cosmic |
High
|
Christian Ehrhardt |
Bug Description
[Impact]
* Backport upstream CVE fix (applies as-is)
* This will ensure that the seccomp rules apply to all threads.
Without that the security benefit that seccomp provides can be avoided
by an attacker.
[Test Case]
* Run qemu on Bionic, and enable the seccomp feature (not yet default on
in Bionic, but in Cosmic). In qemu this is called "sandbox"
$ qemu-system-x86_64 -sandbox on -nographic & pid=$!; sleep 2s;
echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; kill -9 $pid
That will report something like
PID 23230
Seccomp: 2
Seccomp: 0
And the two lines should match.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* This was discussed for other releases e.g. Xenial, but back then the
approach to seccomp was different and regression risk would be too
high.
----
The Qemu changes are public, so nothing to hide here IMHO, but leaving that to the security team.
Copy from the related Debian bug that I commented on:
"
The following vulnerability was published for qemu.
CVE-2018-15746[0]:
seccomp: blacklist is not applied to all threads
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:/
https:/
[1] https:/
[2] https:/
"
In addition I think that:
- it is available (built in since all still supported releases)
- it is default enabled with qemu 2.11 (Bionic)
- with libvirt >4.3 (Cosmic) more of the filters are set
That in my bad security severity guessing capability makes it
- Medium prio <Bionic
- High prio >=Bionic
OTOH, when checking the upstream reproducer with a qemu 2.11 I see nothing being used - so maybe all of it is a red herring (checked on Bionic):
$ for pid in $(pidof qemu-system-
PID 10817
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
PID 10657
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
PID 438
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
Seccomp: 0
CVE References
Christian Ehrhardt (paelzer) wrote : | #1 |
Christian Ehrhardt (paelzer) wrote : | #2 |
Upstream commit [1]
This will bump the need for libseccomp to >=2.2 which has an update to the configure script [2].
Furthermore I think that the old (whitelist) approach might be able to trigger issues if extended to the other threads (which would be correct but might regress people).
Therefore again pre Bionic qemu needs double checks and consideration.
I'm not entirely sure on severity/priority and implications I'd leave X/T for the consideration of the security Team.
I think we can and should fix Cosmic for sure and I'd start on that now.
I have another Qemu SRU Prepped that I could bundle to unify uploads and testing.
I'll spawn tasks according to that assigning clearly who would work on what.
[1]: https:/
[2]: https:/
Changed in qemu (Ubuntu Trusty): | |
assignee: | nobody → Ubuntu Security Team (ubuntu-security) |
Changed in qemu (Ubuntu Xenial): | |
assignee: | nobody → Ubuntu Security Team (ubuntu-security) |
Changed in qemu (Ubuntu Bionic): | |
assignee: | nobody → Christian Ehrhardt (paelzer) |
Changed in qemu (Ubuntu Cosmic): | |
assignee: | nobody → Christian Ehrhardt (paelzer) |
Changed in qemu (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in qemu (Ubuntu Cosmic): | |
status: | New → In Progress |
importance: | Undecided → High |
Changed in qemu (Ubuntu Bionic): | |
importance: | Undecided → High |
Christian Ehrhardt (paelzer) wrote : | #3 |
Subscribed James Page as FYI for cloud archive.
So far I only found qemu version related "be careful" things (like the assumption that the whitelist approach might regress when applied to all threads). But we might spot something more for Xenial which might be important for the UCA builds there - so subscribed for awareness of the discussions here.
Changed in qemu (Debian): | |
status: | Unknown → Confirmed |
Christian Ehrhardt (paelzer) wrote : | #4 |
Cosmic:
PPA: https:/
Diff: https:/
Upgraded a system to the new qemu:
The following packages will be upgraded:
qemu-kvm qemu-system-ppc
2 upgraded, 0 newly installed, 0 to remove and 45 not upgraded.
Need to get 8421 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://
Get:2 http://
Fetched 8421 kB in 2s (3411 kB/s)
(Reading database ... 142908 files and directories currently installed.)
Preparing to unpack .../qemu-
Unpacking qemu-kvm (1:2.12+
Preparing to unpack .../qemu-
Unpacking qemu-system-ppc (1:2.12+
Setting up qemu-system-ppc (1:2.12+
Setting up qemu-kvm (1:2.12+
Processing triggers for man-db (2.8.4-2) ...
Manual check:
$ qemu-system-ppc64 -sandbox on -nographic & pid=$!; sleep 2s; echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; kill -9 $pid
[2] 31359
[2]+ Stopped qemu-system-ppc64 -sandbox on -nographic
PID 31359
Seccomp: 2
Seccomp: 2
Seccomp: 2
Libvirt started guest (with extended blakclist like -sandbox on,obsolete=
$ virsh list
Id Name State
-------
2 b running
[1]+ Killed qemu-system-ppc64 -sandbox on -nographic
$ for pid in $(pidof qemu-system-ppc64); do echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; done
PID 31445
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Running regression tests on that PPA now which is slightly more interesting to set up than usual as we also need glibc from proposed to be installable ...
Christian Ehrhardt (paelzer) wrote : | #5 |
cosmic containers are sort of dead today due to bug 1789627 - so this takes a while
information type: | Private Security → Public Security |
Seth Arnold (seth-arnold) wrote : | #6 |
My opinion on how this could go:
- integrate changes for cosmic soon, deploy the blacklist variant as soon as practical. Beg and cajole people to test and report results. (Does this require a feature freeze exception bug?)
- handle bionic and earlier via SRU process -- this feels like a significant regression risk, and the consequences of it could be pretty severe for our users. Not all kernels will log seccomp denials either, making it extremely difficult to track down the root cause of potential regressions.
- we might not want to turn on even the blacklist variant by default in bionic and earlier due to the risk of regressions. We can always turn it on after cosmic has shipped and seen wider use.
Thanks
Christian Ehrhardt (paelzer) wrote : | #7 |
Hi Seth,
thanks for your thoughts!
Splitting my answers per Release:
== Cosmic ==
For cosmic it needs no FFe IMHO, for already having the Blacklist variant and using it for quite a while. We only extend it to the threads that were missing - in that scope it is only a bug fix.
- There the fix is ready and now also tested in various combinations
stage0-
stage1-
stage2-
stage3-
stage0-
stage1-
stage2-
stage3-
stage0-
stage1-
stage2-
stage3-
The only two fails we see have existed before.
Given all that looks good and we were using it already I'll push that for Cosmic.
== Bionic ==
Bionic is different as I outlined and you also emphasized further.
First of all I'd NOT want to turn on blacklist filtering by default at all there.
But OTOH being not used by default means the only few that use it are those that want to rely on its function. So they would most likely want the fix to be in?
Bionic at least using the blacklist approach already makes this safer than in older relases.
So for Bionic I'd agree to the "prep something and cajole people that are using it already for testing of their cases".
I'll make a PPA ready for that.
The fact that not all kernels log seccomp denials is what makes me feel unsure. That would really be hard to debug.
If we want to go on further than this PPA and actually push something into Bionic depends on
a) positive test feedback
b) feedback at all that the feature is used
c) your security severity estimation if that is needed is high enough
If not a+b+c then I'd keep Bionic untouched.
Would you be able to "cajole the people" once I have a PPA to try?
== Xenial/Trusty ==
Still using the whitelist approach plus risk due to the obvious backport noise and older kernels behaving different makes this too much of a risk IMHO.
So I...
Changed in qemu (Ubuntu Trusty): | |
status: | New → Won't Fix |
Changed in qemu (Ubuntu Xenial): | |
status: | New → Won't Fix |
Changed in qemu (Ubuntu Bionic): | |
assignee: | Christian Ehrhardt (paelzer) → Ubuntu Security Team (ubuntu-security) |
Christian Ehrhardt (paelzer) wrote : | #8 |
I have made a Bionic version with the fix available for testing in [1].
I'd ask people to test this. Since it changes behavior of a default disabled feature this call applies almost exclusively to people that have set up qemu with "-sandbox=..." or configured libvirt to do so with seccomp_sandbox = 1 in /etc/libvirt/
@Seth - might I ask you to do a nicely worked call for testing since you so nicely coined it "cajole people to test and report results"?
Depending on the feedback to that we can make a Bionic decision then.
Note: there are plenty of qemu SRUs in flight (one in -proposed, one waiting) this PPA is ahead to all of them to be useful for a while - none of the other changes affect seccomp execution in any way.
[1]: https:/
Launchpad Janitor (janitor) wrote : | #9 |
This bug was fixed in the package qemu - 1:2.12+
---------------
qemu (1:2.12+
* d/p/ubuntu/
ensure that the seccomp blacklist is applied to all threads (LP: #1789551)
- CVE-2018-15746
-- Christian Ehrhardt <email address hidden> Wed, 29 Aug 2018 08:50:36 +0200
Changed in qemu (Ubuntu Cosmic): | |
status: | In Progress → Fix Released |
Christian Ehrhardt (paelzer) wrote : | #10 |
Call for testing submitted to ubuntu-devel and ubuntu-server.
=> https:/
=> https:/
IMHO We have three possible outcomes:
1. people actually use -sandbox in Bionic and verify -> SRU it
2. people actually use -sandbox in Bionic and found it broken -> good that we called for testing
3. people don't use it -> SRU it (not affecting a lot of people and fixing those who are unaware)
lets give this some time to generate feedback (or not)
Simon Déziel (sdeziel) wrote : | #11 |
$ for pid in $(pidof qemu-system-
PID 21066
Seccomp: 2
Seccomp: 0
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
$ sudo apt-get update && sudo apt-get dist-upgrade -V
...
The following packages will be upgraded:
qemu-block-extra (1:2.11+
qemu-kvm (1:2.11+
qemu-
qemu-system-x86 (1:2.11+
qemu-utils (1:2.11+
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
...
$ for pid in $(pidof qemu-system-
PID 29666
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Simon Déziel (sdeziel) wrote : | #12 |
From https:/
> Starting with libseccomp 2.2.0 and kernel >= 3.17, we can use
> seccomp_
> on all threads.
== Xenial ==
Since Xenial fulfills those requirements, I'd think the QEMU patch would be backportable without too much effort. I haven't look at the code so take this with a grain of salt.
== Trusty ==
Trusty doesn't meet the requirements so addressing it there would probably be more involved and maybe not worth the time investment and the stability risks.
Christian Ehrhardt (paelzer) wrote : | #13 |
Thanks Simon for your checks, yeah I also set X/T to Won't Fix already.
Did you see my poll: https:/
Since you tested Bionic might I ask - are you an example of a real user of that feature on Bionic?
Simon Déziel (sdeziel) wrote : | #14 |
Yes, I've been using "-sandbox on" since at least Trusty and filled a few bugs about this feature in the past. I've replied to the "call for testing" email you sent but maybe my response is being delayed somehow.
I agree with you that Trusty should be "won't fix" but I would have hope that Xenial would be easier/less risky to fix ;)
Christian Ehrhardt (paelzer) wrote : Re: [Bug 1789551] Re: qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads | #15 |
On Wed, Sep 5, 2018 at 4:31 PM Simon Déziel <email address hidden>
wrote:
> Yes, I've been using "-sandbox on" since at least Trusty and filled a
> few bugs about this feature in the past. I've replied to the "call for
> testing" email you sent but maybe my response is being delayed somehow.
>
Thanks, I have seen the reply now.
Having feedback so fast is great and an indicator that we really want to
tackle Bionic.
I agree with you that Trusty should be "won't fix" but I would have hope
> that Xenial would be easier/less risky to fix ;)
>
No Xenial isn't easy either :-/
The big change was to switch from a whitelist (which often had issues with
uncommon setups) to a blacklist based approach.
And that change in terms of Ubuntu Releases was Xenial->Bionic.
So my current stance would be, give the ML some time if more people show
up, but considering the Bionic fix more likely to eventually take place.
Christian Ehrhardt (paelzer) wrote : | #16 |
So to summarize:
- our own testing on Bionic was good
- we had user feedback that it is actually used
- we had positive user test feedback
- further review of the suggested changes did not find issues (as long as the blacklist approach is used as in Bionic)
So I'll prep this for SRU to Bionic.
Christian Ehrhardt (paelzer) wrote : | #17 |
Also we had it a few more days in cosmic now with slowly testers/early adopters picking up and no one hit any issue (and remember in cosmic it is default on).
Added SRU Template and prepared the packaging of the changes to Bionic.
description: | updated |
Christian Ehrhardt (paelzer) wrote : | #18 |
Thank you all for your participation in the discussions and checks around this.
Uploaded to Bionic-unapproved for SRU Team review
An upload of qemu to bionic-proposed has been rejected from the upload queue for the following reason: "The SRU itself is good but currently the .changes file comes with 2 bugs that se".
Łukasz Zemczak (sil2100) wrote : | #20 |
Hello , or anyone else affected,
Accepted qemu into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in qemu (Ubuntu Bionic): | |
status: | Triaged → Fix Committed |
tags: | added: verification-needed verification-needed-bionic |
Christian Ehrhardt (paelzer) wrote : | #22 |
Tested prior to update:
PID 4732
Seccomp: 2
Seccomp: 0
Update:
$ sudo apt install qemu-block-extra qemu-kvm qemu-system-common qemu-system-x86 qemu-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
grub-pc-bin
Use 'sudo apt autoremove' to remove it.
Suggested packages:
samba vde2 ovmf
The following packages will be upgraded:
qemu-block-extra qemu-kvm qemu-system-common qemu-system-x86 qemu-utils
5 upgraded, 0 newly installed, 0 to remove and 68 not upgraded.
Need to get 6782 kB of archives.
After this operation, 8192 B of additional disk space will be used.
Get:1 http://
Get:2 http://
Get:3 http://
Get:4 http://
Get:5 http://
Fetched 6782 kB in 1s (7023 kB/s)
(Reading database ... 86373 files and directories currently installed.)
Preparing to unpack .../qemu-
Unpacking qemu-utils (1:2.11+
Preparing to unpack .../qemu-
Unpacking qemu-system-common (1:2.11+
Preparing to unpack .../qemu-
Unpacking qemu-block-
Preparing to unpack .../qemu-
Unpacking qemu-kvm (1:2.11+
Preparing to unpack .../qemu-
Unpacking qemu-system-x86 (1:2.11+
Setting up qemu-block-
Setting up qemu-utils (1:2.11+
Processing triggers for man-db (2.8.3-2) ...
Setting up qemu-system-common (1:2.11+
Setting up qemu-system-x86 (1:2.11+
Setting up qemu-kvm (1:2.11+
After the update:
PID 5482
Seccomp: 2
Seccomp: 2
Also worked with bigger configurations, setting verified.
tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
Launchpad Janitor (janitor) wrote : | #23 |
This bug was fixed in the package qemu - 1:2.11+
---------------
qemu (1:2.11+
[ Christian Ehrhardt ]
* Add cpu model for z14 ZR1 (LP: #1780773)
* d/p/ubuntu/
ensure that the seccomp blacklist is applied to all threads (LP: #1789551)
- CVE-2018-15746
* improve s390x spectre mitigation with etoken facility (LP: #1790457)
- debian/
- debian/
[ Phillip Susi ]
* d/p/ubuntu/
less than keys over vnc when using en_us kemaps (LP: #1787267).
-- Christian Ehrhardt <email address hidden> Wed, 29 Aug 2018 11:46:37 +0200
Changed in qemu (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Qemu 2.12 on Cosmic
for pid in $(pidof qemu-system-ppc64); do echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; done
PID 158126
Seccomp: 2
Seccomp: 0
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Seccomp: 2
Hmm, why isn't this on by default in Bionic as I expect it ...
Anyway, as I thought the feature existed back then as well and users could have turned it on like
"-sandbox on..."
I checked with that 2.11 in Bionic is also affected.
There is a useful one line reproducer:
$ qemu-system-x86_64 -sandbox on -nographic & pid=$!; sleep 2s; echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep Secc; done; kill -9 $pid
That will report something like
PID 23230
Seccomp: 2
Seccomp: 0
And the two lines should match.