The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Detecting the Presence of Virtual Machines Using the Local Data Table
------------------------------------------------------------------------
SUMMARY
This paper describes a method for determining the presence of virtual
machine emulation in a non-privileged operating environment. This attack
is useful for triggering anti-virtualization attacks and evading analysis.
We then discuss methods for mitigating this risk for malware analysts.
This method was demonstrated using the Windows series of operating
systems.
DETAILS
Introduction
The SIDT mechanism as implemented by Tobias Klein [1] and separately by
Joanna Rutkowska [2] is a method for detecting the presence of a virtual
machine environment. While the test is by no means thorough, it is an
effective test for the presence of an emulated CPU environment on a
single-processor machine. There are various problems with the
implementation, however. If a multi-core CPU is used, the interrupt
descriptor table can change significantly when the process is run on
different cores. Furthermore if two or more physical processors are
present the same implementation issues apply.
The Interrupt Descriptor Table (IDT) is an internal data structure used by
the operating system in processing interrupts. Devices use the IDT to
process events in the operating system. The IDT is a data structure often
exploited by rootkits. [4] By subverting the IDT, the attacker can point
critical items such as the keyboard interrupt to a different function.
Using this method an attacker can then insert malicious code to be
executed when certain interrupts are run.
The Redpill and scoopy_doo mechanisms use the SIDT assembly operation to
retrieve the interrupt descriptor table from the CPU. This data is
available at unprivileged operating levels. By providing this key
information a non-privileged (non-OS level) process can then query this
information. This is bad for a number of reasons. First this
exposes a small level of detail regarding the operating state of the
underlying OS. Second, this information can be used to ascertain the
operating environment of the OS. Malicious software can then determine the
presence of a virtual machine. This can allow the program to terminate
itself, or implement specific exploits to escape from the virtual machine.
To read the full paper :
<http://www.offensivecomputing.net/files/active/0/vm.pdf>
http://www.offensivecomputing.net/files/active/0/vm.pdf
ADDITIONAL INFORMATION
The information has been provided by <mailto:valsmith@metasploit.com>
valsmith.
The original article can be found at:
<http://www.offensivecomputing.net/?q=node/172>
http://www.offensivecomputing.net/?q=node/172
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
