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
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-
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 t
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=r
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 becau
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
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/ar
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
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
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
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 i
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
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 norma
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
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
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 esc
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
** 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 p
22 matches
Mail list logo
