Reported to QEMU @ 1 July 2020
Fixed @ 10 Aug 2020
Reply from the vendor:
I was able to reproduce the said OOB issue in ui/console.c with
$ ./bin/qemu-system-x86_64 -enable-kvm -m 2048 -chardev vc,id=`perl -e 'print "A" x 1025'`,width=640,height=480 \
-mon chardev=`perl -e 'print "A" x 1025'` -nographic /var/lib/libvirt/images/f27vm.qcow2
==301314==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffd690 at pc 0x5555566ad82a bp 0x7fffffffd560 sp 0x7fffffffd550
READ of size 1 at 0x7fffffffd690 thread T0
#0 0x5555566ad829 in vc_chr_write ui/console.c:1109
#1 0x5555566b45e3 in text_console_do_init ui/console.c:2193
#2 0x5555566b2f38 in init_displaystate ui/console.c:1863
#3 0x555555fe1c8f in qemu_init qemu/softmmu/vl.c:4395
#4 0x555556962bf6 in main qemu/softmmu/main.c:48
#5 0x7ffff6834041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#6 0x555555d7e78d in _start (/bin/qemu-system-x86_64+0x82a78d)
* Considering that the said OOB access issue in ui/console.c occurs during console initialisation,
as seen above, it does not seem to have a security impact.
* Stack contents are revealed to the user starting QEMU process, which he/she can see via other means too.
This OOB access issue is best fixed as regular non-security bug.
======================================
The vulnerability is in ui/console.c.
chr->label is the id specified by the startup parameter of qemu. The following snprintf's return value is the actual length required to write the msg, so if the length of chr->label and "console \r\n" is greater than 128, len will also be greater than 128. The following vc_chr_write outputs msg[x] to console, x is a length of 0~len-1. As a result, the contents of the stack buffer will be accessed out of bounds.
static void text_console_do_init(CharDriverState *chr, DisplayState *ds)
{
..... if (chr->label) {
char msg[128];
int len;
s->t_attrib.bgcol = QEMU_COLOR_BLUE;
len = snprintf(msg, sizeof(msg), "%s console\r\n", chr->label);
vc_chr_write(chr, (uint8_t *)msg, len);
s->t_attrib = s->t_attrib_default;
}
Simplest PoC:
qemu --enable-kvm -hda /home/leonwxqian/exdisk/disk.qcow2 -m 2048 -chardev
vc,id=a123456789a123456789a123456789a123456789a123456789a123456789a1234567
89a123456789a123456789a123456789a123456789a123456789a123456789a123456789a1
23456789,width=640,height=480 -mon chardev=a123456789a123456789a123456789a
123456789a123456789a123456789a123456789a123456789a123456789a123456789a1234
56789a123456789a123456789a123456789a123456789
Fix Advice:
len = snprintf(msg, sizeof(msg), "%s console\r\n", chr->label);
+ if(len > sizeof(msg))
+ len = sizeof(msg);
Reported to QEMU @ 22 April 2020
Fixed @ 7 July 2020
Reply from the vendor:
But considering that the issue depends on an administrator hot
plugging/unplugging a drive image, it is more of a non-security bug. Not a CVE
issue.
======================================
Overview
======================================
The "opaque" object in scsi_dma_restart_bh can be used after free.
The operation qemu_bh_delete(s->bh); will use the freed "opaque (s)" object directly.
Freed "s (opaque)" can be occupied by other data, so the s->bh can point to arbitrary address and freed by qemu_bh_delete later:
void qemu_bh_delete(QEMUBH *bh){
g_free(bh);
}
I believe this is not related to system version or hardware architecture. Here's the environment I used to test:
Host: Ubuntu 16.04 x86_64
Guest: Ubuntu 18.04 x86_64
Qemu: 4.2.0 (I checked the commit between 4.2.0-5.0.0 and I believe 5.0.0 has the same problem)
libvirt: 6.0.0
with KVM enabled
The root cause of the vulnerability
=======================================
1. Whenever there's a SCSI device add/plugged into the guest, the callback scsi_dma_restart_cb will be added.
2. When there's a state change in guest, callback scsi_dma_restart_cb will be called and scheduled bottom half: scsi_dma_restart_bh with opaque=s if the guest is not in the shutdown process.
3. In the main IO thread, there's a loop of glib_pollfds_poll, when fd is ready, AIO operations will be called and then scsi_dma_restart_bh is called. (The 'USE' part)
4. Meanwhile, the attacker could write something to IOPORT to unplug the device, and in another thread, will trigger acpi_pcihp_eject_slot, then device_unparent and will free the related memory to the device. (The 'FREE' part)
5. Step (3) (4) could cause a race condition, if (4) is called before (3), there's a UAF.
Related code:
hw/scsi/scsi-bus.c:scsi_dma_restart_cb, scsi_dma_restart_bh
hw/acpi/pcihp.c:acpi_pcihp_eject_slot
Different Ways To Trigger the UAF
=======================================
a. If the guest system could be suspended (paused), here's a simple way to test:
1. Know the slot number of the disk X being attached. (By finding the next available slot number from lspci)
2. Do not attach disk X now, start a program in the guest. That program will *infinitely* write (2 << slot) to the IOPORT of the bus, try to release disk X.
3. Pause the guest and attach disk X.
4. Resume the guest. Now bh callback and the IOPORT write should run at the same time, and cause UAF by chance. If it is not succeeded, repeat steps 3-4.
b. If your guest system cannot be paused, you can try (I haven't tested this yet, I think there could be some chance to do this but I'm not very sure about that. Meant for reference only.):
1. Know the slot of the disk X being attached.
2. Build a custom system kernel, IOPORT writes in the last time before the machine is rebooted.
3. Attach disk X.
4. Reboot the guest machine. If it is not succeeded, repeat steps 3-4.
I have committed my sqlite3_shadow_table_fuzzer to Chromium base, the code can be found here:
Commit:
https://chromium.googlesource.com/chromium/src/third_party/sqlite/+/4bdcad26cbde7791d53cf7f15715b2805fddf889
Code:
https://chromium.googlesource.com/chromium/src/third_party/sqlite/+/4bdcad26cbde7791d53cf7f15715b2805fddf889/fuzz/shadow_table_fuzzer.cc
So far, a bunch of bugs or vulnerabilities were found in chromium, some of those issues IDs are
1. Issue 1028722: sqlite3_shadow_table_fuzzer: Heap-buffer-overflow in sqlite3Fts3GetVarint
2. Issue 1029002: sqlite3_shadow_table_fuzzer: ASSERT: pWriter || bIgnoreEmpty
3. Issue 1029027: sqlite3_shadow_table_fuzzer: Heap-buffer-overflow in sqlite3Fts3GetVarint
4. Issue 1029210: sqlite3_shadow_table_fuzzer: Heap-buffer-overflow in sqlite3Fts3Incrmerge
5. Issue 1029506: sqlite3_shadow_table_fuzzer: Use-of-uninitialized-value in fts3IncrmergeHintPop
6. Issue 1030709: sqlite3_shadow_table_fuzzer: Integer-overflow in fts3ChecksumIndex
7. Issue 1035663: sqlite3_shadow_table_fuzzer: Heap-buffer-overflow in fts3IncrmergeHintPop
8. Issue 1035710: sqlite3_shadow_table_fuzzer: Heap-buffer-overflow in sqlite3Fts3GetVarint32
9. Issue 1037786: sqlite3_shadow_table_fuzzer: Undefined-shift in fts3BestSnippet
10. Issue 1038213: sqlite3_shadow_table_fuzzer: Out-of-memory in sqlite3_shadow_table_fuzzer (OOM in SQLite)
11. Issue 1049131: sqlite3_shadow_table_fuzzer: Integer-overflow in fts3SegmentIsMaxLevel
12. Issue 1057441: sqlite3_shadow_table_fuzzer: Use-of-uninitialized-value in fts3ScanInteriorNode
13. Issue 1062965: sqlite3_shadow_table_fuzzer: Integer-overflow in fts3IncrmergeOutputIdx
14. Issue 1204066 in chromium: sqlite3_shadow_table_fuzzer: Integer-overflow in fts3SelectLeaf