[Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU

[Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU

[Red Hat Product Security]

 Hello Gerd,

On Thu, 28 Aug 2014 07:57:17 GMT, kraxel@redhat.com wrote:
> In case the memory area happens to hit unmapped pages qemu segfaults.
> => DoS
>
> The guest can't modify host memory though, so I don't think this can be
> used by the guest to compromise the host.

I was finally able to reproduce the issue on a rhel-7 machine. Looking through
the stack trace, the SIGSEGV occurs while doing memset(2) in
red_create_surface() routine of the spice-server library. That is host memory
write instigated from a guest. Here the length value is consistent: 35389440.
Nonetheless, it is not very clear how & where did that value come from. Upon
starting the reproducer from Laszlo, it creates 5 threads. One(or all) of them
calls

red_worker_main
-> worker->watches[i].watch_func(worker->poll_fds[i].fd, events,
worker->watches[i].watch_func_opaque);

-> void dispatcher_handle_recv_read(Dispatcher *dispatcher) ->
dispatcher_handle_single_read(dispatcher)
-> msg->handler(dispatcher->opaque, (void *)payload); ->
handle_dev_create_primary_surface(void *opaque, void *payload)
-> dev_create_primary_surface(worker, msg->surface_id, msg->surface);
-> red_create_surface (worker, 0, surface.width, surface.height, ...)

There is a gap in the sequence above wherein it's not clear which function is
invoked by - watch_func(...), which in turn calls
dispatcher_handle_recv_read().

Could the memset(2) length argument controlled by an end application in the
guest? If so, that could be used to write/set arbitrary memory bytes on the
host, without crashing the Qemu, as the crash requires it to hit an unmapped
memory area.

Could an unprivileged user/process on the guest trigger this crash in Qemu?
---
Prasad J Pandit / Red Hat Product Security

Re: [Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU

[Gerd Hoffmann]

  Hi,

> There is a gap in the sequence above wherein it's not clear which function is
> invoked by - watch_func(...), which in turn calls
> dispatcher_handle_recv_read().

(gdb) thread apply all bt

Thread 2 (Thread 0x7fa703fff700 (LWP 25303)):

This is the spice worker thread, reading messages / instructions from a
socket

#0  0x00007fa7230d006d in __memset_sse2 () from /lib64/libc.so.6
#1  0x00007fa723e04f6f in dev_create_primary_surface.isra.92 ()
from /lib64/libspice-server.so.1
#2  0x00007fa723e050cf in handle_dev_create_primary_surface ()
from /lib64/libspice-server.so.1
#3  0x00007fa723df3463 in dispatcher_handle_recv_read ()
from /lib64/libspice-server.so.1
#4  0x00007fa723e16ff5 in red_worker_main ()
from /lib64/libspice-server.so.1
#5  0x00007fa7259d1df3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fa72313c3dd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fa728364a40 (LWP 25299)):

This is the qemu main thread, processing a display update here.

#0  0x00007fa7259d825d in read () from /lib64/libpthread.so.0
#1  0x00007fa723df31a4 in read_safe () from /lib64/libspice-server.so.1
#2  0x00007fa723df3657 in dispatcher_send_message ()
from /lib64/libspice-server.so.1
#3  0x00007fa723df46f0 in red_dispatcher_create_primary_surface_sync ()
   from /lib64/libspice-server.so.1

Has sent a request to the spice worker thread, awaiting answer.

#4  0x00007fa72859160b in qemu_spice_create_host_primary ()
#5  0x00007fa7285918a8 in qemu_spice_display_switch ()
#6  0x00007fa72858c302 in dpy_gfx_replace_surface ()
#7  0x00007fa7285d3303 in vga_update_display ()

Display update in vga mode.  Display resizes are processed in the update
function (triggered by a timer), not as direct response to register
writes.  That function will look at the vbe registers
(VGACommonState->vbe_regs) which are updated in vbe_ioport_write_data().

> Could the memset(2) length argument controlled by an end application in the
> guest? If so, that could be used to write/set arbitrary memory bytes on the
> host, without crashing the Qemu, as the crash requires it to hit an unmapped
> memory area.

User application can't do this, requires root privileges within the
guest.

Wading through the code I've noticed one special spice thing.  There is
a fixed buffer, size 16MB, presented to spice-server as video memory,
which is the actual backing store for the primary surface in case qxl is
in vga mode (and also when using non-qxl video cards with spice).  It is
allocated in qemu_spice_display_init_common().

So, that is the one we are overflowing when using spice, and it can be
written to indirectly (spice-server uses it as storage for the display
content).  I think the memset() does actually save us here:  Due to the
memory block being quite big it gets allocated with mmap(), with
unmapped pages before and after it.  So if the guest makes the screen
resolution too big the memset will crash qemu before the guest has the
chance to do something evil.

For the non-spice case the analysis from my previous mail is correct.

cheers,
  Gerd

[Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU

[Red Hat Product Security]

 Hello Gerd, Laszlo,

Thank you so much for the detailed analysis and explanations, appreciate it.

On Thu, 28 Aug 2014 07:57:17 GMT, kraxel@redhat.com wrote:
> How to go forward with this? Ok to post the patches for review in
> public (aka qemu-devel)? Or do we have a CVE with embargo?

Please use 'CVE-2014-3615' for the information disclosure and potential memory
corruption issue. When you submit patches upstream include this in the commit
log. Please include me in the CC list when you send patches upstream.

Thank you.
--
Prasad J Pandit / Red Hat Product Security