* Stefan Hajnoczi (stefa...@linux.vnet.ibm.com) wrote:
> @@ -199,6 +200,11 @@ static void change_process_uid(void)
> fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
> exit(1);
> }
> + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
> + user_pwd->pw_name, user_pwd->pw_gid);
> + exit(1);
> + }
Does initgroups need access to /etc/group? How does this combine w/
-chroot?
Added bonus...this will fail when the initial user is not privileged
_and_ is the same user as -runas user (probably not what a user intended,
but would've worked before). Something like:
[doh@laptop qemu]$ qemu -runas doh
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/807893
Title:
qemu privilege escalation
Status in QEMU:
Confirmed
Bug description:
If qemu is started as root, with -runas, the extra groups is not
dropped correctly
/proc/`pidof qemu`/status
..
Uid: 100 100 100 100
Gid: 100 100 100 100
FDSize: 32
Groups: 0 1 2 3 4 6 10 11 26 27
...
The fix is to add initgroups() or setgroups(1, [gid]) where
appropriate to os-posix.c.
The extra gid's allow read or write access to other files (such as
/dev etc).
Emulating the qemu code:
# python
...
>>> import os
>>> os.setgid(100)
>>> os.setuid(100)
>>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ)
sh-4.1$ xxd /dev/sda | head -n2
0000000: eb48 9000 0000 0000 0000 0000 0000 0000 .H..............
0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
sh-4.1$ ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Jul 8 11:54 /dev/sda
sh-4.1$ id
uid=100(qemu00) gid=100(users)
groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/807893/+subscriptions
