RIDL (Rogue In Flight Data Load)

Leave a Comment / Malware, Cryptography, cryptojacking, Cyber Attack, Cyber Security, General-Security, HTTP Headers, Management, Web Security / By

RIDL stands for Rogue In-Flight Data Load. RIDL is also known to use MFBDS in addition to MLPDS to acquire data. Attackers can execute code using cloud resources, malicious websites or advertisements and can steal data by breaking any security barriers. RIDL (Rogue In-Flight Data Load) shows attackers can exploit MDS vulnerabilities to mount practical attacks and leak sensitive data in real-world settings. By analyzing the impact on the CPU pipeline, we developed a variety of practical exploits leaking in-flight data from different internal CPU buffers (such as Line-Fill Buffers and Load Ports), used by the CPU while loading or storing data from memory.

What is MFBDS?

CVE-2018-12130 – Microarchitectural Fill Buffer Data Sampling (MFBDS): Fill buffers are used when an L1 data cache miss occurs. This allows the system to continue operation while the data is loaded from higher levels of cache. Sometimes a stale data in the fill buffer gets forwarded to load operations which can be captured by an attacker. Also, two threads on the same physical core share the fill buffer without any partitioning. Here, if one of the applications running on the thread is malicious, it can be used to access the data through fill buffers.

RIDL can be used to leak data from the vulnerable CPU’s various internal buffers (portions of allocated memory used to store or load data). The researchers’ proofs of concept demonstrated how RIDL can be used in a Linux environment to leak root passwords, kernel data, and a string of information from another process.

The researchers noted that RIDL can let hackers steal data from other programs running on the same system. This could range from other applications/software, the operating system’s kernel, cloud-based or virtual machines, and even Intel processor’s enclaves. RIDL reportedly affects devices fitted with Intel chips from as early as 2008.

RIDL and Fallout are similar to the Spectre vulnerability from 2018, that is they take advantage of how a processor manages tasks by speculating what calculation the os will need next and discarding the wrong one. Think about when you used to play Choose-Your-Own-Adventure books and you would cheat by looking at the outcome of your choices then picking the page that looked best and forgetting the others. That is how Intel processors can be one step ahead, the downside is attacks like Spectre and now RIDL and Fallout can be successful.

INTRODUCTION OF RIDL (Rogue In-Flight Data Load):

CPU’s have various security domains such as line-fill buffers, load ports, and multiple buffers, RIDL allows malicious code to leak information across those security domains. You can then use this attack to read information from other applications, over a trusted execution environment and most worryingly you can read information from other virtual machines. It will be interesting to see how cloud providers such as AWS, Azure, etc deal with this type of attack.

What is the RIDL attack?

Researchers from VUSec – the Systems and Network Security Group at Vrije University in Amsterdam, and from the Helmholtz Center for Information Security (CISPA) have developed the RIDL (short for Rogue In-Flight Data Load) attack.

Here’s how in-flight buffers work and how sensitive data can flow to the attacker’s process:

After rummaging through CPU patent specifications, VUSec found that leaks from CPU buffers were possible. The researchers say that only Intel CPU’s.

Mitigating For RIDL

The response to the disclosure of speculative execution attacks has so far been the deployment of spot mitigation in software before mitigation’s become available in hard-ware. For example, for Meltdown, the first deployed software mitigation (i.e., KPTI) was the separation of address spaces between user space and kernel space by the operating system. While effective, on top of increasing complexity in the kernel, KPTI has been shown to have performance penalties under certain workloads. We now describe how this spot mitigation approach is not well-suited for RIDL.
Since sensitive information can be leaked from sibling hardware threads, we strongly recommend disabling SMT to mitigate RIDL. Intel suggests RIDL can also be mitigated by ensuring that
only trusted code is ever executed in sibling threads. However, this strategy introduces non-trivial complexity, as it requires scheduler modifications as well as synchronization at system call entry points. It is also insufficient to protect sandboxes applications or SGX enclaves. Worse, it is still possible to leak sensitive information from another privilege level within a single thread (as some of our exploits demonstrated), including information from internal CPU systems such as the MMU.
To protect sensitive information in the kernel or in a different address space, the kernel needs to flush the LFBs and other in-flight buffers before returning to the userland, similarly to the L1 flush in the Foreshadow mitigation. Similarly, the hypervisor needs to flush the buffers before switching to VM execution. In the case of hardware-based components such as SGX or the MMU, the flushing cannot be easily done in software. Intel’s published mitigation involves updated microcode, which allows the software to flush several types of in-flight buffers (LFBs, load ports, and store buffers) using the view instruction.
After performing this flush (e.g., when returning from a system call), a fence or other speculation barriers are required to prevent code from speculatively executing across security boundaries before the buffers are cleared. The updated microcode also flushes these buffers when flushing the L1 cache and when leaving/exiting SGX. Note that this cannot preclude leakage of internal CPU data (e.g., from the MMU). Moving forward. In this paper, we primarily focused on speculation done on LFB entries.
However, we have also shown there are other sources of in-flight data and believe there are likely more—especially given decades of performance optimizations in the CPU pipeline. Furthermore, as discussed in this section, because these optimizations are applied deeply in the CPU pipeline, spot mitigation’s will likely be complex and expensive. Moving forward,
we see two directions for mitigating these issues:
  1. As Intel could release a microcode update that mitigated SSB by completely disabling speculative store forwarding, we believe it should make similar mitigation possible for all possible sources of speculation when applying micro-optimizations. It will then be up to system software to decide which optimizations to turn off until hardware mitigations become available.
  2. Finding all instances of RIDL will likely take a long time due to the complexity of these micro-optimizations. Hence, rather than spot mitigations that are often ineffective against the next discovered attack, we need to start the development and deployment of more fundamental mitigations against the many possible classes of speculative execution attacks.

Leave a Comment

Your email address will not be published. Required fields are marked *

nine − seven =

Protect your system, protect the future of your business.

Let's Talk