Security Guide should discuss KSM impact

[Robert Clark]

Chapter 40. (Hypervisor Selection) of the security guide describes KSM as a security feature (http://docs.openstack.org/security-guide/content/ch051_vss-intro.html). In actuality it's a memory optimization mechanism performing de-duplication of pages between virtual machines, which has been previously exploited to infer data about virtual machines.

KSM should be described as a security concern, not a security enhancing feature.

[Robert Clark (robert-clark)]

There should also be discussion of TPS on XEN.

[Jeffrey Walton (noloader)]

Great catch Rob.

Here's a paper that is probably of interest: "Fine grain Cross-VM Attacks on Xen and VMware are possible!", http://eprint.iacr.org/2014/248.

The paper provides a brief history of some attacks. The attacks cited against Kernel SamePage Merging (KSM) are [20] and [21]:

[20] SUZAKI, K., IIJIMA, K., YAGI, T., AND ARTHO, C. Mem- ory deduplication as a threat to the guest os. In Proceedings of the Fourth European Workshop on System Security (2011), ACM, p. 1.
[21] SUZAKI, K., IIJIMA, K., YAGI, T., AND ARTHO, C. Software side channel attack on memory deduplication. SOSP POSTER (2011).

The attacks against Transparent Page Sharing (TPS) in XEN are outlined in the paper on page 6. Bernstein's attack is used to carry out recovery of the secret key material in a neighboring VM.

Counter measures are discussed on page 11, and are included below. AES-NI and AES-256 look the most promising counter measures.

**********

6 Countermeasures

It is possible to prevent the data leakage and the resulting cross-vm cache attacks on cloud environment with sim- ple precautions. The countermeasures that we propose are easy solutions to avoid a problem that can be very painful when working with sensitive data.

• AES-NI Setting up the virtual machine on a com- puter with AES-NI support and use AES-NI instruc- tions instead of the software implementation. Us- ing AES-NI mitigates completely the cache side- channel attacks since it does not use the mem- ory. Moreover is nearly 10 times faster than the software implementation [25]. Even though this might seem like an obvious countermeasure, a quick search shows that there are still some VMs offered by popular CSPs that do not have AES-NI hardware support.

• Cache Prefetching Prefetch the tables in to the cache prior to first and last round. When the data is prefetched there is no possibility of attacking ei- ther the first or last rounds. Although this leads to a less noisy environment for a second round attack, the fact that it is much more difficult to implement the second round attack still makes this a viable op- tion. We already know that the OpenSSL developers are aware of the cache attack vulnerability and we encourage them to work with the experimental file that they already implemented and included in the OpenSSL 1.0.1‘ distribution. As for Libgcrypt and PolarSSL a new prefetching scheme for AES should be implemented to provide protection from AES cache attack.

• Using AES-256 Use 256-bit key AES encryption instead of 128-bit and 196-bit versions. This will lead in more rounds, 12 for the 192-bit and 14 for the 256-bit versions, and will introduce more noise to the side channel measurements. We believe that the study samples required to analyze a 256-bit AES key would deem the cache attack impractical and the amount of the key bytes recovered in such case would be drastically low.

• Preventing Cartography As noted earlier in [19] another countermeasure would be making the server cartography harder. If the attacker cannot locate the target, it is possible to prevent the attack before it even begins since the attacker has to be on the same physical machine to perform the attack. Frequent cor...

[Robert Clark (robert-clark)]

Written up some content in a google doc for initial review, once happy I'll push it into the docbook format and into gerrit

https://bugs.launchpad.net/openstack-manuals/+bug/1311204

[Robert Clark (robert-clark)]

Sorry, this was the link I intended to paste https://docs.google.com/document/d/1wX7f5IW4-yVkaER17AQKXVvO6Q5FKLxMhyTapnvk868/edit?usp=sharing

[Andreas Jaeger (jaegerandi)]

Robert, this reads great. I just commented a few nits on the Google document, IMHO it's ready to be pushed into gerrit.

[Bryan D. Payne (bdpayne)]

I have made a few comments in the google doc, but I also agree with Andreas that this should be captured as PR in gerrit at this point.

[Openstack Gerrit (openstack-gerrit)]

Fix proposed to branch: master
Review: https://review.openstack.org/92378

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/92378
Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=0e6ba16aa76a61915811625a4797b664159b368d
Submitter: Jenkins
Branch: master

commit 0e6ba16aa76a61915811625a4797b664159b368d
Author: Robert Clark <email address hidden>
Date: Tue May 6 15:30:29 2014 +0100

    Discuss security impact of Memory Optimization Technologies

    Removed KSM from the list of 'security features' for hypervisor
    technology and added a discussion of KSM and TPS.

    Change-Id: Iaedb90f84f74836ccce24a4a63402f429845635d
    Closes-Bug: #1311204

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/openstack-manuals 15.0.0 release.