[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
According to Stefan, this problem has been fixed by this commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc4662f9642995c78
... so let's close this bug ticket now.
** Changed in: qemu
Status: Confirmed => Fix Released
--
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:
Fix Released
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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Mike, the issue is solved for Linux hosts with a modern glibc. Andrew explained that uclibc or non-Linux hosts may still be affected if they do not apply set*id() to all threads in the process. The safe way to solve this universally is to perform -runas before creating threads. -- 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
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
I think I verified this issue on lastest qemu steps: 1./configure make 2.start qemu-kvm process with -runas nobody ./qemu-system-x86_64 -m 2G -smp 4 -cpu qemu64,+x2apic -usbdevice tablet -drive file=/home/win2003-32-new.raw,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none,format=raw -device ide-drive,bus=ide.0,unit=0,bootindex=1,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device rtl8139,netdev=hostnet0,mac=76:0E:40:3F:2F:3F -boot dc -uuid cc5aee77-d631-41d4-92a0-4e59c3b5cb6c -rtc-td-hack -monitor stdio -name win2k3-32-serial -vnc :10 -device virtio-balloon-pci,id=balloon0 -runas nobody 3# cat /proc/25996/status Name: qemu-system-x86 State: R (running) Tgid: 25996 Pid:25996 PPid: 28206 TracerPid: 0 Uid:99 99 99 99 Gid:99 99 99 99 Utrace: 0 FDSize: 256 Groups: 99 4# cat /proc/25996/task/25996/status Name: qemu-system-x86 State: R (running) Tgid: 25996 Pid:25996 PPid: 28206 TracerPid: 0 Uid:99 99 99 99 Gid:99 99 99 99 Utrace: 0 FDSize: 256 Groups: 99 Based on above ,I think this bug has been fixed ald. Best Regards, Mike -- 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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths 807...@bugs.launchpad.net wrote: 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. Wow, just learnt something new that glibc does behind our backs :). I see it uses SIGRTMIN+1 to signal threads and get them to do the set*id system calls. I'm glad it does this because although most QEMU threads should be started after command-line parsing, I can think of instances where we might start a thread before -runas is completed. Stefan -- 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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
On Thu, Jul 14, 2011 at 12:46 PM, Andrew Griffiths 807...@bugs.launchpad.net wrote: 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. Good point about other OSes and distros. QEMU does not create any threads before -runas processing AFAICT. It's a nasty problem in general though because shared libraries could... Stefan -- 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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
On Thu, Jul 14, 2011 at 2:00 PM, Andrew Griffiths 807...@bugs.launchpad.net wrote: with some grepping of parent callers, looks like the cpu is probably my issue The -runas processing doesn't happen until os_setup_post() right before entering the main loop. It is too late at that point because threads may have been spawned. My mistake was to think -runas processing happens in os_parse_cmd_args(). Stefan -- 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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
On Wed, Jul 13, 2011 at 11:12 AM, Andrew Griffiths 807...@bugs.launchpad.net wrote: 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. Hi Andrew, I think what Chris meant is that libvirt does not use -runas at all. It drops privileges (including initgroups(3)) itself *before* invoking QEMU. So I think his statement is simply that libvirt (commonly used in KVM deployments) is not affected. Stefan -- 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
Re: [Qemu-devel] [Bug 807893] Re: qemu privilege escalation
On Wed, Jul 13, 2011 at 11:50 AM, Andrew Griffiths 807...@bugs.launchpad.net wrote: 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. I see. Thanks for the clarification. Stefan -- 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] Re: qemu privilege escalation
This bug is being tracked as CVE-2011-2527 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2011-2527 -- 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
Requesting CVE. Tools like libvirt deprivilege themselves before launching qemu as an unprivileged user (no use of -runas), so aren't vulnerable. -- 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
** Changed in: qemu Status: New = Confirmed ** Changed in: qemu Assignee: (unassigned) = Stefan Hajnoczi (stefanha) -- 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
