Microarchitectural attacks pose a great threat to any code running in parallel to other untrusted processes. Especially in public clouds, where system resources such as caches are shared across several tenants, microarchitectural attacks remain an unsolved problem. Cache attacks rely on evictions by the spy process, which alter the execution behavior of the victim process. Similarly, all attacks exploiting shared resource access will influence these resources, thereby influencing the process they are targeting. We show that hardware performance events reveal the presence of such attacks. Based on this observation, we propose CacheShield, a tool to protect legacy code by self-monitoring its execution and detecting the presence of microarchitectural attacks. CacheShield can be run by users and does not require alteration of the OS or hypervisor, while previously proposed software-based countermeasures require cooperation from the hypervisor. Unlike methods that try to detect malicious processes, our approach is lean, as only a fraction of the system needs to be monitored. It also integrates well into today's cloud infrastructure, as concerned users can opt to use CacheShield without support from the cloud service provider. Our results show that CacheShield detects attacks fast, with high reliability, and with few false positives, even in the presence of strong noise.

Microarchitectural attacks have gained popularity lately for the threat they pose and for their stealthiness. They are stealthy as they only exploit common harmless resources accessible at lowest privilege level, e.g. timed memory and cache accesses. Microarchitectural attacks have proven successful on shared cloud instances across VMs, on smartphones with sandboxing, and on numerous embedded platforms. Further they have shown to have catastrophic consequences such as critical data recovery or memory isolation bypassing. Due to the rise of malicious code, app store operators such as Microsoft, Apple and Google are already vetting apps before releasing them. Microarchitectural attacks however still bypass such detection mechanisms as they mainly utilize standard resources and look harmless. Given the rise of malicious code in app stores and in online repositories it becomes essential to scan applications for such stealthy attacks to prevent their distribution.

Multi-processor systems are becoming the de-facto standard across different computing domains, ranging from high-end multi-tenant cloud servers to low-power mobile platforms. The denser integration of CPUs creates an opportunity for great economic savings achieved by packing processes of multiple tenants or by bundling all kinds of tasks at various privilege levels to share the same platform. This level of sharing carries with it a serious risk of leaking sensitive information through the shared microarchitectural components. Microarchitectural attacks initially only exploited core-private resources, but were quickly generalized to resources shared within the CPU. We present the first fine grain side channel attack that works across processors. The attack does not require CPU co-location of the attacker and the victim. The novelty of the proposed work is that, for the first time the directory protocol of high efficiency CPU interconnects is targeted. The directory protocol is common to all modern multi-CPU systems. Examples include AMD's HyperTransport, Intel's Quickpath, and ARM's AMBA Coherent Interconnect. The proposed attack does not rely on any specific characteristic of the cache hierarchy, e.g. inclusiveness. Note that inclusiveness was assumed in all earlier works. Furthermore, the viability of the proposed covert channel is demonstrated with two new attacks: by recovering a full AES key in OpenSSL, and a full ElGamal key in libgcrypt within the range of seconds on a shared AMD Opteron server.

In this work we show how the Lucky 13 attack can be resurrected in the cloud by gaining access to a virtual machine co-located with the target. Our version of the attack exploits distinguishable cache access times enabled by VM deduplication to detect dummy function calls that only happen in case of an incorrectly CBC-padded TLS packet. Thereby, we gain back a new covert channel not considered in the original paper that enables the Lucky 13 attack. In fact, the new side channel is significantly more accurate, thus yielding a much more effective attack. We briefly survey prominent cryptographic libraries for this vulnerability. The attack currently succeeds to compromise PolarSSL, GnuTLS and CyaSSL on deduplication enabled platforms while the Lucky 13 patches in OpenSSL, Mozilla NSS and MatrixSSL are immune to this vulnerability. We conclude that, any program that follows secret data dependent execution flow is exploitable by side-channel attacks as shown in (but not limited to) our version of the Lucky 13 attack.

Dividing last level caches into slices is a popular method to prevent memory accesses from becoming a bottleneck on modern multicore processors. In order to assess and understand the benefits of cache slicing in detail, a precise knowledge of implementation details such as the slice selection algorithm are of high importance. However, slice selection methods are mostly unstudied, and processor manufacturers choose not to publish their designs, nor their design rationale. In this paper, we present a tool that allows to recover the slice selection algorithm for Intel processors. The tool uses cache access information to derive equations that allow the reconstruction of the applied slice selection algorithm. Thereby, the tool enables further exploration of the behavior of modern caches. The tool is successfully applied to a range of Intel CPUs with different slices and architectures. Results show that slice selection algorithms have become more complex over time by involving an increasing number of bits of the physical address. We also demonstrate that among the most recent processors, the slice selection algorithm depends on the number of CPU cores rather than the processor model.

The cloud computing infrastructure relies on virtualized servers that provide isolation across guest OS's through sand boxing. This isolation was demonstrated to be imperfect in past work which exploited hardware level information leakages to gain access to sensitive information across co-located virtual machines (VMs). In response virtualization companies and cloud services providers have disabled features such as deduplication to prevent such attacks. In this work, we introduce a fine-grain cross-core cache attack that exploits access time variations on the last level cache. The attack exploits huge pages to work across VM boundaries without requiring deduplication. No configuration changes on the victim OS are needed, making the attack quite viable. Furthermore, only machine co-location is required, while the target and victim OS can still reside on different cores of the machine. Our new attack is a variation of the prime and probe cache attack whose applicability at the time is limited to L1 cache. In contrast, our attack works in the spirit of the flush and reload attack targeting the shared L3 cache instead. Indeed, by adjusting the huge page size our attack can be customized to work virtually at any cache level/size. We demonstrate the viability of the attack by targeting an Open SSL1.0.1f implementation of AES. The attack recovers AES keys in the cross-VM setting on Xen 4.1 with deduplication disabled, being only slightly less efficient than the flush and reload attack. Given that huge pages are a standard feature enabled in the memory management unit of OS's and that besides co-location no additional assumptions are needed, the attack we present poses a significant risk to existing cloud servers.

Abstract Software updates and security patches have become a standard method to fix known and recently discovered security vulnerabilities in deployed software. In server applications, outdated cryptographic libraries allow adversaries to exploit weaknesses and launch attacks with significant security results. The proposed technique exploits leakages at the hardware level to first, determine if a specific cryptographic library is running inside (or not) a co-located virtual machine (VM) and second to discover the IP of the co-located target. To this end, we use a Flush+Reload cache side-channel technique to measure the time it takes to call (load) a cryptographic library function. Shorter loading times are indicative of the library already residing in memory and shared by the VM manager through deduplication. We demonstrate the viability of the proposed technique by detecting and distinguishing various cryptographic libraries, including MatrixSSL, PolarSSL, GnuTLS, OpenSSL and CyaSSL along with the IP of the VM running these libraries. In addition, we show how to differentiate between various versions of libraries to better select an attack target as well as the applicable exploit. Our experiments show a complete attack setup scenario with single-trial success rates of up to 90% under light load and up to 50% under heavy load for libraries running in KVM.