Skip to content
October 27, 2014 / Rafal Wojtczuk

TSX improves timing attacks against KASLR

Mega biblion mega kakon…

… and similarly a long blog is a nuisance, so I managed to squeeze the essence of it into a single sentence, the title. If it is not entirely clear, read on.

SMEP

A typical privilege escalation exploit based on a kernel vulnerabilit yworks by corrupting the kernel memory in a way advantageous for an attacker. Two scenarios are possible:

  1. arbitrary code execution in kernel mode
  2. data-only; just alter kernel memory so that privileges are elevated (e.g. change the access token of the current process)

Usually, the first method is most straightforward, and most flexible. With SMEP enabled, attacker cannot just divert kernel execution into code stored in usermode pages; more work is needed, a generic method being ROP in kernel body.

Kernel ASLR

Usually, both above methods require some knowledge about kernel memory layout. Particularly, in order to build a ROP chain in kernel body, we need to know the base of the kernel or a driver. In windows 8.1 significant changes were introduced to not give to the attacker the memory layout for free. They affect only processes running with integrity level lower than medium, but it is the most interesting case, as OS-based sandboxes encapsulate untrusted code in such a process. The effectiveness of Windows 8.1 KALSR depends on the type of vulnerability primitive available to the attacker:

  1. If one can read and write arbitrary address with arbitrary contents multiple times, there is no problem, as one can learn the full memory layout.
  2. If one can overwrite arbitrary address with arbitrary content at least twice, then a generic method is to overwrite the IDT entry for interrupt Y with usermode address X (note IDT base can be obtained via unprivileged sidt instruction), and then change the type of page holding X so that it becomes a superuser page (possible because page table entries are at known location). Finally, trigger code execution with int Y instruction. I assume it is message of this post, although they do not discuss how to locate a kernel code pointer (meaning, beat KASLR) that subsequently should be overwritten. In some cases we do not need to know the address of the kernel code pointer, e.g. if it lives in an area that we can overflow or alter under use-after-free condition.
  3. If one can just control a kernel function pointer, then… We can divert execution neither to usermode (because of SMEP) nor to kernelmode (because of KASLR we do not know addresses of any ROP gadget). Any hints?

Recently I played with a vulnerability from the third category, and (at least for me) KASLR provided significant resistance. It can be argued that there is potential for kernel bugs that leak some pointers and thus allow to bypass KASLR, but something more generic would be better.

Timing attacks against KASLR

An excellent paper describes methods to bypass KASLR via timing attacks. One of the discussed methods is: in usermode, access kernel address X, and measure the time elapsed until the usermode exception handler is invoked. The point is that even though usermode access to X throws a page fault regardless whether X is in mapped kernel memory or not, the timings are different. When we recover the list of mapped pages, we can infer the kernel base (or some driver base) and consequently the addresses of useful code snippets in it – all we need to build a ROP chain.

Timing attacks need to take care of the inherent noise. Particularly, on Windows invoking the usermode exception handler requires a lot of CPU instructions, and the difference in timing can be difficult to observe. It would be much better if the probing did not result in the whole kernel page fault handler executing. Any hints?

TSX to the rescue

Haswell Intel CPUs introduced the “transactional synchronization extensions”. It means than only recent CPUs support them; moreover, Intel recommends disabling them via microcode update, as they are apparently not reliable. Yet we may assume that someday they will be fixed and become widespread.

TSX makes kernel address probing much faster and less noisy. If an instruction executed within XBEGIN/XEND block (in usermode) tries to access kernel memory, then no page fault is raised – instead transaction abort happens, so execution never leaves usermode. On my i7-4800MQ CPU, the relevant timings, in CPU cycles, are (minimal/average/variance, 2000 probes, top half of results discarded):

  1. access in TSX block to mapped kernel memory: 172 175 2
  2. access in TSX block to unmapped kernel memory: 200 200 0
  3. access in __try block to mapped kernel memory: 2172 2187 35
  4. access in __try block to unmapped kernel memory: 2192 2213 57

The difference is visible with naked eye; an attack using TSX is much simpler and faster.

Two points as a take-away:

  1. KASLR can be bypassed in an OS-independed way; this post describes how the existing techniques can be improved utilizing TSX instructions.
  2. The attack is possible because of shared address space between kernel and usermode. Hypervisor has a separate address space, and therefore it is not prone to similar attacks.
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.

XSA-105

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.

XSA-108

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:

bashsmah_pic_2

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

[i] http://en.wikipedia.org/wiki/Bourne_shell

[ii] http://en.wikipedia.org/wiki/Bash_(Unix_shell)

[iii] http://en.wikipedia.org/wiki/Apache_HTTP_Server

[iv] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

[v] http://www.alienvault.com/blogs/security-essentials/the-life-of-a-security-researcher

[vi] http://en.wikipedia.org/wiki/Code_injection

[vii] https://lists.debian.org/debian-security-announce/2014/msg00220.html

[viii] http://en.wikipedia.org/wiki/Common_Gateway_Interface

[ix] http://en.wikipedia.org/wiki/Environment_variable

[x] http://shellshock.brandonpotter.com/

[xi] http://www.scmagazine.com/linux-and-os-x-flaw-may-have-greater-impact-than-heartbleed/article/373743/

[xii] http://unix.stackexchange.com/questions/157329/what-does-env-x-command-bash-do-and-why-is-it-insecure

[xiii] http://en.wikipedia.org/wiki/Trust_boundary

[xiv] https://www.owasp.org/index.php/Web_Application_Firewall

[xv] https://bugzilla.redhat.com/show_bug.cgi?id=1141597

[xvi] http://en.wikipedia.org/wiki/Internet_of_Things

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.

 

 

Follow

Get every new post delivered to your Inbox.

Join 40 other followers