Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 568226 (CVE-2015-8556) - <app-emulation/qemu-2.4.1-r2[virtfs]: Local Privilege Escalation due to filesystem caps/setuid access with /usr/bin/virtfs-proxy-helper (CVE-2015-8556)
Summary: <app-emulation/qemu-2.4.1-r2[virtfs]: Local Privilege Escalation due to files...
Alias: CVE-2015-8556
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa cve]
Depends on:
Reported: 2015-12-14 12:54 UTC by Kristian Fiskerstrand (RETIRED)
Modified: 2016-02-04 09:34 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-12-14 12:54:06 UTC
In the ebuild, you give virtfs-proxy-helper certain capabilities:

        if use virtfs && [ -n "${softmmu_targets}" ]; then
                fcaps ${virtfs_caps} /usr/bin/virtfs-proxy-helper

No other distributions set these capabilities, and for a good reason:
it's extremely dangerous to do so. There are dozens and dozens of ways
an unprivileged user can get root privileges if virtfs-proxy-helper
has these capabilities.

For example, in virtfs-proxy-helper.c, proxy_socket(path, owner,
group) is called from the main() function using user-supplied
parameters. The proxy_socket() function goes on to make sure the path
does not already exist, creates a unix socket and binds it -- thereby
creating a file at that user supplied location:


app-emulation/qemu: critical security fix
The virtfs-proxy-helper program is not a safe binary to give caps.
The following exploit code demonstrates the vulnerability:

~=~=~=~= snip ~=~=~=~=

/* == virtfshell ==
 * Some distributions make virtfs-proxy-helper from QEMU either SUID or
 * give it CAP_CHOWN fs capabilities. This is a terrible idea. While
 * virtfs-proxy-helper makes some sort of flimsy check to make sure
 * its socket path doesn't already exist, it is vulnerable to TOCTOU.
 * This should spawn a root shell eventually on vulnerable systems.
 * - zx2c4
 * 2015-12-12

Public at and CVE request at
Comment 1 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-12-14 12:58:48 UTC
2nd URL should be

Maintainers, please advise when ready to stabilize
Comment 2 Jason A. Donenfeld gentoo-dev 2015-12-15 01:06:53 UTC
Was assigned CVE-2015-8556 here:
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2015-12-15 04:46:52 UTC
(In reply to Kristian Fiskerstrand from comment #1)
> 2nd URL should be
> Maintainers, please advise when ready to stabilize

You guys did the bump. Maintainers weren't involved. I'd say you guys go with the stabilization.
Comment 4 SpanKY gentoo-dev 2015-12-15 05:35:26 UTC
(In reply to Doug Goldstein from comment #3)

except Jason didn't actually update all the ebuilds, just did a revbump for the ones that had stable versions.  so all the others remain vulnerable including the latest ~arch.

i'm also not sure why the commit message is filled with the PoC.  if you want verbose data, link to the bug report/upstream URL, don't fill the log with data that's going to be dead in a month.
Comment 5 SpanKY gentoo-dev 2015-12-15 05:56:02 UTC
fixed with 2.4.1-r2.  fine for stable.

i've also cleaned the logic from all the ebuilds in the tree:
Comment 6 Agostino Sarubbo gentoo-dev 2015-12-16 08:54:16 UTC
amd64/x86 stable
Maintainer please cleanup
Comment 7 Agostino Sarubbo gentoo-dev 2015-12-18 17:06:47 UTC
cleanup done by vapier
Comment 8 Yury German Gentoo Infrastructure gentoo-dev 2015-12-21 17:19:07 UTC
Arches and Maintainer(s), Thank you for your work.

Added to an existing GLSA Request.
Comment 9 GLSAMaker/CVETool Bot gentoo-dev 2016-02-04 09:34:52 UTC
This issue was resolved and addressed in
 GLSA 201602-01 at
by GLSA coordinator Kristian Fiskerstrand (K_F).