[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Here's some reproduction code you can use to see the difference between glibc and raw system calls: https://gist.github.com/1084042 If you're wondering about Linux and non-glibc distributions using qemu, Alpine is one particular answer to that question (so the affected Linux distributions is non-zero). -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Regarding the threads having different privilege level, I have isolated that to being related to my grsecurity configuration (more specifically, chroot_findtask will block it). While it's still an issue on older glibc where the setuid/setgid code does not enforce it across all threads, it may not be high priority since fixing it would be a lot more effort. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Actually, from a quick google perhaps ensuring all threads run after chroot / dropping privileges might be a good idea. - http://wiki.freebsd.org/Per-Thread%20Credentials - http://www.cocoabuilder.com/archive/cocoa/33107-cthread-fork.html though it looks like you might need to put in effort into getting per- thread uid's for freebsd/macosx when they make that available, and you're assuming they're running a recent glibc. Depending on complexity, it can't hurt to ensure you're not going to hit into per-thread uid/gid's. I'm of two minds about glibc doing this. This was a particular favourite bug class of mine :) It seems that there is a linux distro which uses uclibc, which does not emulate the glibc behaviour: http://dl-4.alpinelinux.org/alpine/v2.2/main/x86/ -- has qemu packages. we can use http://paste.pocoo.org/raw/438497/ to emulate qemu's behaviour # ./test [main] my [ug]id is 100/100 [thread] my [ug]id is 0/0 ^-- the qemu thread would be running as root running the same code under glibc (without grsecurity chroot_findtask), and it will drop privileges as you'd expect on recent glibc. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
It does create threads before chroot/setgid/setuid, see https://bugs.launchpad.net/qemu/+bug/807893/comments/10. That process was created with following options: -enable-kvm -runas -chroot -m -kernel -append -drive -net nic,model=virtio, -net tap,ifname=xxx -serial none -serial unix:.. -serial file: ... -monitor unix:... -daemonize -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
with some grepping of parent callers, looks like the cpu is probably my
issue
static void qemu_kvm_start_vcpu(CPUState *env)
{
env-thread = qemu_mallocz(sizeof(QemuThread));
env-halt_cond = qemu_mallocz(sizeof(QemuCond));
qemu_cond_init(env-halt_cond);
qemu_thread_create(env-thread, qemu_kvm_cpu_thread_fn, env);
/* init the dynamic translator */
cpu_exec_init_all(tb_size * 1024 * 1024);
.. etc
6613 clone(child_stack=0xa75df454,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xa75dfbd8, {entry_number:6, base_addr:0xa75dfb70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}, child_tidptr=0xa75dfbd8) = 16615
.. etc
16615 ioctl(4, KVM_CREATE_VCPU, 0) = 7
16615 ioctl(3, KVM_GET_VCPU_MMAP_SIZE, 0) = 12288
16615 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0xa6ddc000
16615 ioctl(7, KVM_SET_VAPIC_ADDR, 0xa75de1a4) = 0
later on it does chroot/setgid/setuid
--
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
000: eb48 9000 .H..
010:
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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
# ps axwu ... qemu00 29957 0.5 9.8 480568 405228 ? Sl Jul12 7:41 /usr/bin/qemu-system-x86_64 -runas ... ... # ps axwu -L ... qemu00 29957 29957 0.23 9.8 480568 405228 ? Sl Jul12 2:49 /usr/bin/qemu-system-x86_64 -runas ... root 29957 29959 0.33 9.8 480568 405228 ? Sl Jul12 4:47 /usr/bin/qemu-system-x86_64 -runas ... root 29957 29960 0.03 9.8 480568 405228 ? Sl Jul12 0:00 /usr/bin/qemu-system-x86_64 -runas ... ... # cat /proc/29957/task/29959/status Name: qemu-system-x86 State: S (sleeping) Tgid: 29957 Pid:29959 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: 999 ... Threads can have their own uid/gid set. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
correction: s/other distro's/other operating systems/g -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Once you have code execution in the process, you can modify the others threads execution (if required) to execute your own code. With full capabilities, it would be trivial to escape from a chroot on a normal Linux kernel (grsecurity with appropriate kernel chroot restrictions enabled would reduce the avenues available for escaping.). I seem to recall other distro's handle thread privileges differently. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Hello Stefan, I was explaining the threads / uids per thread issue, in case it wasn't obvious of what the impact was, or how to exploit that issue (in case someone was wondering about that). It was not directed at Chris in any shape or form, nor was it about libvirt. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Yep, that fix looks fine. RedHat should have a CVE number for this issue. -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
or any other linux vendor that has an interest in qemu :) -- 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 000: eb48 9000 .H.. 010: 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
[Qemu-devel] [Bug 807893] [NEW] qemu privilege escalation
Public bug reported: 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 000: eb48 9000 .H.. 010: 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) ** Affects: qemu Importance: Undecided Status: New ** Tags: escalation groups privilege security -- 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: New 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 000: eb48 9000 .H.. 010: 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
