qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 786209] [NEW] Information leak in IDE core


From: Nelson Elhage
Subject: [Qemu-devel] [Bug 786209] [NEW] Information leak in IDE core
Date: Sat, 21 May 2011 15:33:33 -0000

*** This bug is a security vulnerability ***

Public security bug reported:

When the DRQ_STAT bit is set, the IDE core permits both data reads and
data writes, regardless of whether the current transfer was initiated as
a read or write.

Furthermore, the IO buffer is allocated via a qemu_memalign but not
initialized or cleared at device creation.

This potentially leaks uninitialized host memory into the guest, if,
before doing anything else to an IDE device, the guest begins a write
transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead
of writing to it. The IDE core will happily return the uninitialized
contents of the buffer to the guest, potentially leaking offsets that
could be used as part of an attack to get around ASLR.

** Affects: qemu
     Importance: Undecided
         Status: New

** Visibility changed to: Public

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/786209

Title:
  Information leak in IDE core

Status in QEMU:
  New

Bug description:
  When the DRQ_STAT bit is set, the IDE core permits both data reads and
  data writes, regardless of whether the current transfer was initiated
  as a read or write.

  Furthermore, the IO buffer is allocated via a qemu_memalign but not
  initialized or cleared at device creation.

  This potentially leaks uninitialized host memory into the guest, if,
  before doing anything else to an IDE device, the guest begins a write
  transaction (e.g. WIN_WRITE), but then *reads* from the IO port
  instead of writing to it. The IDE core will happily return the
  uninitialized contents of the buffer to the guest, potentially leaking
  offsets that could be used as part of an attack to get around ASLR.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]