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-
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->th
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
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
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
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 not
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
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
# 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
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 q
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 des
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
12 matches
Mail list logo
