infoguard-cyber-security-blog-cve-2019-11184-security-vulnerability-intel-cpu

CVE-2019-11184 – an Intel CPU vulnerability following 6 months of research

In the course of the thesis for my master's degree, which I received from the VUSec Group (the System & Network Security Group at Vrije University of Amsterdam) we managed to uncover a CPU vulnerability. This vulnerability meant that it was possible to read sensitive data over the network, so it is far from innocuous. In this blog post, I am reporting back on the findings in my master's thesis, reactions to them and their effects on cyber security.

infoguard-cyber-security-michael-kurth-netcat-enLet's start with the good news: the vulnerability was acknowledged by Intel and fortunately for me and my research colleagues a bug bounty was paid out. I was also delighted that the master's thesis which came out of this was peer-reviewed and accepted by the IEEE Symposium on Security and Privacy. What does that mean? In May 2020 we will be presenting our results in San Francisco at the conference under the same name and, as if that were not enough, we also presented our results at the Chaos Communication Congress (36C3), which took place at the end of December. 

Cache-side-channel attacks – a very real threat

The vulnerability that we discovered (CVE-2019-11184) demonstrates that network-based cache-side-channel attacks are a real threat. Cache attacks are traditionally used to steal confidential data in a local environment. In doing so, it makes use of shared hardware resources. An example would be from one virtual machine controlled by an attacker to another virtual machine sharing CPU cache on a cloud platform. With CVE-2019-11184, this threat is extended across the network, i.e. a machine's cache activity can be read throughout the network. Thus, the confidentiality of an SSH session can be breached from a third party machine without there being any malware present on the client or server. The main source of the vulnerability is a new Intel feature called DDIO, which allows network devices and other peripherals to access the CPU cache. DDIO is activated by default on all Intel server CPUs since 2012. Despite the fact that it was originally intended to enhance performance, our research showed that DDIO presents serious security risks and it can expose servers in local networks to remote side-channel attacks.

Intel has acknowledged that this is a significant security vulnerability and has recommended limiting direct access from untrusted networks to servers with DDIO and RDMA (Remote Direct Memory Access). This basically means that DDIO and/or RDMA should be disabled in untrustworthy network environments.

But what exactly is DDIO?

Data Direct I/O DDIO for short is a performance-enhancing technology installed on current Intel server processors. Instead of reading slow RAM, DDIO gives peripherals access to the faster computer cache.

In traditional architectures where the network card uses Direct Memory Access (DMA), memory latency itself quickly turns into a bottleneck. This can happen with network cards as low as 10Gb/s. Intel introduced DDIO to overcome this bottleneck as an architecture where peripherals can use direct cache access to the CPU's last level cache. The following diagram illustrates the difference between direct cache access (orange) and direct memory access (blue).

infoguard-netcat-cpu-intel-breach-michael-kurth-1-en



So what is CVE-2019-11184 then?

We demonstrated that with CVE-2019-11184 the vulnerability we discovered it is possible to breach the confidentiality of an SSH session from a third computer without running malware on the remote server or client. The attacker does this just by sending network packets to the remote server.

More accurately speaking, CVE-2019-11184 allows the arrival time of each network packet from an SSH session to be read from a remote cache-side-channel. Why is this a good idea? In an interactive SSH session, network packets are directly transmitted every time a key is pressed. Consequently, with CVE-2019-11184, every time a user enters a character on the keyboard within an encrypted SSH session, the arrival time can be read from the corresponding network packet. People have different typing patterns, so letters can be extracted directly from the arrival time. As an example, entering "s" directly after "a" is faster than entering "g" after "s". This allows a static analysis of the arrival times of packets from what is known as a keystroke timing attack using the data obtained from the remote side-channel attack. This makes it possible to find out what information was entered or transmitted in the private SSH session. This means that the complete attack path is relatively complex. As a result, we not only found a vulnerability, but we also wrote a study on how to reconstruct whole words from the arrival time of network packets. The next diagram illustrates how a user types the word "because" and by way of comparison, how we were able to reconstruct the arrival times from the remote cache.

infoguard-netcat-cpu-intel-breach-michael-kurth-3-en


infoguard-netcat-cpu-intel-breach-michael-kurth-2-enIn our attack, we exploited the fact that the DDIO-enabled application server has a shared resource (the last level cache) between the CPU and the network card. Our team subsequently "reverse-engineered" important features of DDIO, or to put it another way analysed and reconstructed them. This allowed us to understand how the cache is shared with DDIO. We used this knowledge to read sensitive information from the application server cache via the network using a cache-side-channel attack. To facilitate the attack, we used Remote Direct Memory Access (RDMA) technology. RDMA enabled our exploit to control the relative location of network packets on the target server.

This diagram illustrates our target topology, which is standard in data centres. The attacker controls a computer that communicates with an application server via RDMA. CVE-2019-11184 showed that an attacker can remotely spy with success on peripheral devices like network cards.

 

 

 

CVE-2019-11184 in the media

Shortly after the public disclosure, which happened on September 10, 2019, there were numerous reports in the media, including prestigious technology news sites such as Ars Technica, ZDNet and Heise as well as on twitter.

You can find a proof-of-concept video here, and more information on the attack and all the research work here:

More about our research work

 

Image source (No. 1; Michael Kurth): https://media.ccc.de/v/36c3-10884-practical_cache_attacks_from_the_network_and_bad_cat_puns

<< >>

Cyber Security , Cyber Risks

Michael Kurth
About the author / Michael Kurth

InfoGuard AG - Michael Kurth, Senior Cyber Security Analyst, Investigations & Intelligence

More articles from Michael Kurth


Related articles
The year of Emotet, Ryuk & co. – our look back over cyber security in 2019
The year of Emotet, Ryuk & co. – our look back over cyber security in 2019

2019 was an eventful year for cyber security, and so our teams were also kept pretty busy. It's no wonder [...]
SAP security ‒ security for standardised ERP software is possible [Part 2]
SAP security ‒ security for standardised ERP software is possible [Part 2]

The SAP system is often one of the most important applications in the entire company. You can use certain SAP [...]

Exciting articles, the latest news and tips & tricks from our experts on all aspects of Cyber Security & Defence.

Blog update subscription
Social Media
infoguard-cyber-security-phishing-poster-en