In the ebuild, you give virtfs-proxy-helper certain capabilities: if use virtfs && [ -n "${softmmu_targets}" ]; then local virtfs_caps="cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_setgid,cap_mknod,cap_setuid" fcaps ${virtfs_caps} /usr/bin/virtfs-proxy-helper fi 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 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=183dd7394703b49c7af441a9c4227b4b91453510 and CVE request at https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=183dd7394703b49c7af441a9c4227b4b91453510
2nd URL should be http://seclists.org/oss-sec/2015/q4/483 Maintainers, please advise when ready to stabilize
Was assigned CVE-2015-8556 here: http://seclists.org/oss-sec/2015/q4/497
(In reply to Kristian Fiskerstrand from comment #1) > 2nd URL should be http://seclists.org/oss-sec/2015/q4/483 > > 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.
(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.
fixed with 2.4.1-r2. fine for stable. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75d0202d68b81bc06d451b574670d8374751789f i've also cleaned the logic from all the ebuilds in the tree: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=359bcd793b5d0507b496cfb4125eaea0c0137de5
amd64/x86 stable Maintainer please cleanup
cleanup done by vapier
Arches and Maintainer(s), Thank you for your work. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201602-01 at https://security.gentoo.org/glsa/201602-01 by GLSA coordinator Kristian Fiskerstrand (K_F).
