Skip to content
October 1, 2014 / Rafal Wojtczuk

Musings on the recent Xen Security Advisories

As all careful readers of this blog certainly know, the Bromium vSentry hypervisor (uXen) has been derived from Xen. It means parts of the codebase are shared between the two projects, and vulnerabilities found in Xen sometimes are relevant for uXen. The two recent Xen Security Advisories, XSA-105 and XSA-108, are not particularly severe (at least for vSentry), but feature interesting details related to generic hypervisor hardening that are worth discussing. One may wish to read the original Xen advisories before proceeding.


The title of advisory is “Missing privilege level checks in x86 HLT, LGDT, LIDT, and LMSW emulation”. The impact (for Xen) is ability of an unprivileged VM usermode to elevate to VM kernel.
In some scenarios when CPU cannot execute an instruction in a VM properly (because e.g. this instruction touches memory-mapped register, and has device-specific side effect) Xen emulates the instruction. The problem is that the code responsible for emulating the above instructions did not check whether CPU was in kernel mode. Particularly LGDT and LIDT are normally available for kernel mode only, as they change the crucial CPU registers. Because of the vulnerability, user process in a VM (even one with very low privileges, e.g. Untrusted integrity level in case
of Windows) could effectively execute LIDT or LGDT and take full control over VM.

Exploitation is straightforward in case of Windows 7, one can just create a fake IDT table in usermode, and kernel will transfer control to attacker’s code (residing in usermode pages) upon the first interrupt. On Windows 8 running on CPU featuring SMEP, attacker needs a bit more work and create a ROP chain in kernel – fortunately for an attacker, at the entry to the [software] interrupt handler, all general-purpose registers are controllable, so it is easy to achieve the stack pivot.

It is remarkable that in fact, no sane OS needs support of emulation of these instructions in normal circumstances. Still, a complete emulator imported into Xen is available throughout VM’s lifetime, resulting in a vulnerability. In the early days of uXen development, it was recognized that the emulator constitutes an attack vector, and a conscious effort was made to reduce the number of supported instructions. Therefore, uXen is not vulnerable – when an exploit is run in a vSetry microVM, the emulation is denied (with a message
(uXEN) c:/br/bld/uxen/xen/uxen/arch/x86/x86_emulate/x86_emulate.c:1383:d187 instruction emulation restricted for twobyte-instruction 0x1
in the logs) and the microVM is killed.

To sum up, Xen users should worry about this vulnerability if they run untrusted code in their VMs (think sandboxed code) and care about privilege elevation within VM. uXen is not affected.


The title of the advisory is “Improper MSR range used for x2APIC emulation”. The impact is that a malicious VM kernel can crash Xen or read up to 3K of its memory, from an address that is not under control of an attacker.

The root cause is that the code responsible for emulation of access to local APIC registers in x2APIC mode supported 1024 registers, but allocated buffer space for 256 registers only. If a write access (by wrmsr instruction) is requested by VM, no harm is done, as only a limited number of known registers are actually emulated. On the other hand, the code implementing read access emulation just reads from the vlapic->regs buffer (that is one page long), at an offset controlled by the attacker (must be less than 16K).
Consequently, memory located up to 12K after the vlapic->regs buffer is read and returned to the VM. More precisely, 4byte-long integers located at 16bytes-aligned addresses can be read. If the virtual addresses adjacent to vlapic->regs buffer are unmapped, this results in Xen crash; if they are mapped, their contents leak to the VM.

The vulnerable code is present in uXen. uXen uses a specialized memory manager (dubbed memcache”), that preallocates a large contiguous virtual memory range for the purpose of mapping VM-related pages. As a result, uXen crash is unlikely, it can happen only when the vlapic->regs buffer is mapped near the end of the memcache.
Similarly, the information leak is somewhat restricted – memcache stores only pages allocated for uXen purposes, therefore (if we neglect the unlikely “end of memcache” scenario) there is no possibility that unrelated host’s kernel memory can leak to the microVM. In the common case, memcache assigns consecutive virtual addresses for mapping of subsequent page allocations. During microVM setup, the order of allocation is such that the three pages allocated
immediately after vlapic->regs allocation store VMCS, VMCS shadow and MSR bitmap pages. Therefore, in the common case, all the atacker can achieve is leaking lower 32 bits of pointers from VMCS, which might help to deduce the ALSR layout of the host kernel. This is not a catastrophic problem in itself, but it can aid in exploitation of another unrelated vulnerability. In a corner case when microVM creation races with heavy map/unmap operations done on other microVM’s memory, this memory would leak to the attacker as well.

To sum up, this vulnerability has potential for crashing the whole hypervisor or leaking limited amount of data from hypervisor.. This is not very severe impact, although if one runs multiple VMs of different origin on the same host and is very serious about possibility of leaking data (even small amount from an location not controlled by an attacker) from one VM to another, prompt patching is justified. Interestingly, there was quite some concern in the media about this vulnerability, but it was clearly overhyped.

Interestingly, vSentry microVMs use xAPIC mode, not in x2APIC mode. The vulnerability can be exploited only in x2APIC mode. It means that an attacker needs to enable x2APIC mode first. However, this results in microVM OS being unable to use APIC, and hang in IPI processing. In order to exploit this vulnerability repeatedly for more than a few seconds, attacker would need to patch VM OS to use APIC in x2APIC mode, which is far from trivial, yet imaginable.
It also means we missed a generic hardening opportunity – we should support only a single APIC mode. There is still room for improvement, but considering that since the release of the first vSentry version there was no vulnerability in Xen allowing for escape from VM that would affect us, it looks we have done a fairly decent job.

September 26, 2014 / Jared DeMott

The Mysterious Life of Benjamin Bash

In a time of shaggy beards, thick glasses, and bell bottomed trousers, was Bourne[i] a way to command the beasty called Unix.  But as is always the way with humans, enough is never enough.  As such, a fancier champion Bashed[ii] onto the scene.  And for many years, Mr. Benjamin Bash served rich and poor alike, in the kitchens of Apache[iii] and countless other dens[iv].

Now as always, dragon slayers[v] comb our lands, searching for kingdom weaknesses.  And of course, our faithful Mr. Bash was never considered a fault.  But his obscure injection[vi] wouldn’t lie dormant forever.  Nay!  One brave warrior, Sir Chazelas[vii], discovered that when ye place an order with lovely CGI[viii] maids, one can also pass an environment[ix] note, which causes Mr. Bash to do unexpected things.  Indeed, in vulnerable establishments, Bash will do whatever ye ask[x].  Even hand over the keys to the castle!  Aye, it’s a sad affair, with grave consequences[xi].

But take heart laddie, and listen up.  We’ve vital information.  Examine the following attack:


The smart student would note that for the agent of doom to achieve its nefarious function[xii], some key bits must transfer across our moat[xiii].  The evil parts of the message are the letters “() {“.  I say, our border guards[xiv] should be informed about the matter.  And better yet, we should hastily patch[xv] Mr. Bash to insure he acts properly, and ignores such outsider suggestions.  Sadly some of our smaller holds[xvi] may not receive the message for some time, if ever.

So, with this unsavory matter behind, the mysterious life of Mr. Bash goes on.  But the enemy forces are wily.  They’re schemin’ and plotting as always.  I say let’s do a thorough run down of our defenses, check the checkers, and make sure we’re ready when next our dastardly foo return.


Protip: Article best read aloud with a pint and a thick Irish or Scottish accent

















September 16, 2014 / Vadim Kotov

Pirates of the Internetz: The curse of the waterhole

Pirates of the Internetz

Last week the Bromium Labs team was contacted by a Fortune 1000 customer that detected an interesting attack via one of their installed LAVA sensors. We get such events frequently from our customers; however this attack was a bit different. The attack was a classic waterhole attack targeting potential viewers of a technology startup in the Oil and Gas sector. Interestingly, this attack occurred days after the company announced a sizable funding grant. It’s likely that the attackers were expecting more traffic to the website and hoped to increase their chances of a successful infection. The names of the companies involved are redacted and they have confirmed that the infection has been remediated and both have confirmed that no sensitive information was leaked.

Attacks on the ONG sector are not new and attacks targeting companies in this sector might be premeditated. Bromium Labs is working with the target and we’ll update the blog if there’s any significant development.

The event we received was dated 09/04/2014. The alert produced the following malware graph which confirms the infection, at a glance (click to enlarge):

LAVA Graph

After analyzing the captured forensic evidence, we found some interesting traits.

Read more…

August 11, 2014 / Rafal Wojtczuk

Black Hat USA 2014 talk about hypervisor security

This week I presented at Black Hat USA. The talk is titled “Poacher turned gatekeeper: lessons learned from eight years of breaking hypervisors”. The main points were:

  • Describe the attack surface of Type 1 and Type 2 hypervisors
  • Show that despite not being 100% bulletproof, hypervisors are still the best usable way to isolate potentially malicious code
  • Describe a few generic methods to harden a hypervisor
  • Discuss four new VirtualBox vulnerabilities
  • Discuss DMA attacks against DeepSafe

The whitepaper is here, enjoy.

July 31, 2014 / Tom Sutcliffe

Remote code execution on Android devices

Tom Sutcliffe and Thomas Coudray

You walk into a coffee shop and take a seat. While waiting for your coffee, you take out your smartphone and start playing a game you downloaded the other day. Later, you go to work and check your email in the elevator. Without you knowing, an attacker has just gained a foothold in your corporate network and is steadily infecting all your colleagues’ smartphones too.

Wait, what?

We don’t talk about Android much here on the Bromium Labs Blog, but now and again we like to tinker. Recently my colleague Thomas Coudray and I have been looking at an Android remote code execution vulnerability to see how much of a problem it is in real-world usage.

While privilege-escalation techniques are common on Android (and form the basis for the common practice of ‘rooting’ a device), remote code execution is a rarer and much more dangerous type of vulnerability. It allows an attacker to run code of their choosing on a user’s device without their knowledge or permission. This bug was particularly interesting because it appeared to still be exploitable even on a fully-patched latest-model Android device, a full 18 months after it was fixed. We wanted to see if this was true and if so, how much effort was required to exploit it. We found that the scenario described above is an all-too-real possibility.

Read more…

July 22, 2014 / Br Labs

H1 2014 Endpoint Exploitation Trends

The Bromium Labs team got together and came up with a summary of notable exploitation trends that we observed in the first 6 months of 2014. There were some interesting takeaways:

- Internet Explorer took the cap for historic high number of security patches in over a decade, and that feat was accomplished in the first 6 months of 2014!

- As timelines to the next version of the latest Internet Explorer shrink, time to the next security patches have also shrunk. Expect more to come.

- In 2013, Oracle Java was labeled as the notorious king for malware authors and zero day attacks, exploit kits had a field time with it. Notably, there were no reported zero day exploits targeting Java in H1 2014.

- Adobe Flash continued to be exploited by zero days and also providing attackers with newer avenues to exploit the browser (Internet Explorer).

-  Attackers developed novel ways to attack browsers leveraging ‘Action Script Spray’ to bypass ASLR. This was used by several zero day exploits in the wild.


It’s evident that attackers continue to shift focus in between ubiquitous internet facing applications, but there’s a common theme throughout – attacking the end users. Will Java attacks continue to decline this year? Would attackers continue to focus on exploiting Internet Explorer? We’ll soon find out.


The full report is available to download here.



June 10, 2014 / Br Labs

Chrome dances with wolves

  ” Lasker does not play chess, he plays dominoes. ” – David Janowski, 1910

Alice sees her “browser” as the computer, not the network or operating system. This trend will only get stronger as BYOD takes hold. We’re in a brave new world, where traditional security models based on clear boundaries break down. Modern browsers’ cornerstone security approach, same-origin policy, entails significant complexity and controls only a limited subset of cross-domain interactions. Highly granular isolation within this context ends up breaking existing web-apps. In an odd way, one can see flashbacks and parallels to the old MS-DOS era.

Google Chrome is tipped for primacy as the definitive web-browser. They were among the first to deploy separate protection domains that made it more difficult, and perhaps more exciting, for Eve. Chromium architecture assigns the browser kernel to interact with the underlying OS on behalf of the user. It’s rendering engine deals with “the web” via a high-quality sandbox. Thus, historically high-risk components such as the HTML parser, the JavaScript virtual machine, and Document Object Model (DOM) became more difficult to leverage. Overall, Google’s browser is a strong candidate for secure browsing.

However, the state of the art in exploitation is now more dominoes than chess. Eve can bypass the sandbox via techniques ranging from kernel exploits to plugins to get to Alice. We now take a look at what happens with just a few tricks from an evergreen bag.

Let’s install the latest:


Alice then confidently proceeds to browse to her favorite videos. Unfortunately, Eve has compromised the site and planted an exploit with a custom payload. Conventional layers of defense including AV, sandboxes and firewalls fail to stop the attack:


If Alice was protected by vSentry, the attack would have been captured within a micro-VM. Her SOC team would then be able to trace Eve’s tracks via LAVA:


Perhaps, Chrome should dance with Bromium.


Get every new post delivered to your Inbox.

Join 39 other followers