Bug 736038 (CVE-2011-3346)

Original 1st comment from Paolo
-------------------------------

Description of problem:
A buffer overflow is present in QEMU's SCSI subsystem.  hw/scsi-disk.c
tries to zero a user-provided number of bytes in a fixed-size buffer.

#define SCSI_DMA_BUF_SIZE    65536
...
typedef struct SCSIRequest {
    SCSIDevice *dev;
    uint32_t tag;
    /* ??? We should probably keep track of whether the data trasfer is
       a read or a write.  Currently we rely on the host getting it right.  */
    /* Both sector and sector_count are in terms of qemu 512 byte blocks.  */
    int64_t sector;
    int sector_count;
    /* The amount of data in the buffer.  */
    int buf_len;
    uint8_t dma_buf[SCSI_DMA_BUF_SIZE];
    BlockDriverAIOCB *aiocb;
    struct SCSIRequest *next;
} SCSIRequest;
...
int32_t scsi_send_command(SCSIDevice *s, uint32_t tag, uint8_t *buf, int lun)
{
...
    command = buf[0];
    r = scsi_new_request(s, tag);
    outbuf = r->dma_buf;
    switch (command >> 5) {
...
    case 4:
...
        len = buf[13] | (buf[12] << 8) | (buf[11] << 16) | (buf[10] << 24);
        cmdlen = 16;
...
    }
...
    case 0x9e:
        /* Service Action In subcommands. */
        if ((buf[1] & 31) == 0x10) {
            DPRINTF("SAI READ CAPACITY(16)\n");
            memset(outbuf, 0, len);

Version-Release number of selected component (if applicable):
xen-3.0.3-132.el5
qemu-kvm-0.12.1.2-2.171.el6

How reproducible:
100%

Steps to Reproduce:
1. Under RHEL5 Xen, create a RHEL6 guest that has a SCSI CD-ROM.
2. Install sg3_utils in the guest.
3. Log into the guest from the VNC console as an unprivileged user.
4. Check with getfacl (e.g. "getfacl /dev/sr0" for RHEL5 Xen) that the
user got read-write access to the device.
4. Send the following CDB to the device using sg_raw (READ CAPACITY 16,
allocation length = 0x040000):

     9E 10 00 00 00 00 00 00 00 00 00 04 00 00 00 00

Actual results:
qemu crashes

Expected results:
Either the CDB is rejected with an ILLEGAL REQUEST sense code, or it
works successfully

Additional info:
The reproduction steps require ConsoleKit for the user to gain access to
the CD-ROM devices. For this reason, they do not work when logging in
via ssh. Similarly, RHEL5 and earlier guests are not as vulnerable
because they do not use ConsoleKit: only privileged users can send CDBs
to SCSI devices under RHEL5 and earlier.

The bug is minor because the user cannot control the data that is
written to the buffer. Petr Matousek gave it AV:L/AC:H/Au:N/C:N/I:N/A:C
in private IRC discussion.

RHEL5 KVM does not support SCSI devices at all. RHEL6 KVM supports USB
disks (which are SCSI), but not USB CD-ROMs. Hence, unless root manually
changes permissions or ACLs, the bug cannot be exploited by an
unprivileged user.  We may still want to patch it.

Beware of bug 735993.  Until it is fixed, in order to create sda as a
SCSI CD-ROM you should instead add a dummy *sde* disk like

  disk = [ "file:...:hda,w", "file:...:sda,r", "file:...:sde:cdrom,r" ]

Statement:

This issue only affects qemu as shipped with Red Hat Enterprise Linux 5 xen packages. The versions of the qemu/kvm as shipped with Red Hat Enterprise Linux 5 are not affected.

Paolo, could you please post link to the upstream patch?

Yes, it just got committed.  A simpler patch is possible, but I prefer to wait:

https://github.com/bonzini/qemu/commit/103b40f51e4012b3b0ad20f615562a1806d7f49a
https://github.com/bonzini/qemu/commit/7285477ab11831b1cf56e45878a89170dd06d9b9

5.8 patch posted.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:1401 https://rhn.redhat.com/errata/RHSA-2011-1401.html