I Attempted to Exploit a Hidden Flaw in my Homelab CPU : CVE-2018–3646

Hello world!
so three years ago, I began documenting my journey into threat hunting with a simple homelab setup:

1x Lenovo mini-PC and a 3COM switch.

What started with 1 Lenovo Mini

Over time, my one Lenovo mini evolved into a full-fledged homelab, now with three Lenovo Mini PCs. Each having their specific role:

- First Mini running an OPNsense as a firewall,
- Second one running a Proxmox for virtualization,
- and the third one just happen to be my dedicated attack box with VMware installed for my self-study purposes. Many cybersecurity labs and tutorials focused on VMware and VirtualBox, so I decided to set up my attack box with VMware to follow along and ease of use.

Turned into 3 Lenovo

So, when I logged into my VMWARE ESXI, I saw this message which caught my attention:“This host is potentially vulnerable to issues described in CVE-2018 – 3646.”

Potentially Vulnerable to CVE-2018–3646

That was all the motivation I needed! This CVE was related to L1 Terminal Fault (L1TF), a vulnerability that can expose data through speculative execution, a part of the Spectre and Meltdown family of CPU vulnerabilities. What better way to start my homelab journey than by testing for this vulnerability on the very machine that hosts everything?

In this article, I’ll share what I learned about Spectre, Meltdown, and L1TF, how modern CPUs work, and how I approached testing the vulnerability. For a more technical breakdown, stay tuned for the YouTube video where I’ll dive deeper into the exact steps.

What’s L1TF?

L1 Terminal Fault, or L1TF, is a vulnerability in the speculative execution feature of modern CPUs. Discovered in 2018, L1TF affects Intel processors, particularly those using hyper-threading. But before we go further into L1TF, let’s take a look at the bigger picture: Spectre and Meltdown.

Understanding Modern CPUs

Modern CPUs are designed to be lightning-fast and highly efficient, thanks to several innovative features:

1. Speculative Execution: CPUs predict which instructions are likely to be needed next and execute them ahead of time. This speeds things up, but if a prediction is wrong, the executed instructions are discarded.
2. Out-of-Order Execution: The CPU doesn’t execute instructions strictly in order. Instead, it performs tasks as resources become available, which maximizes efficiency.
3. Caching: CPUs use various levels of cache memory, especially L1 cache (the closest to the processor), to store frequently used data and instructions.

While these techniques make CPUs incredibly powerful, they also introduce weaknesses that attackers can exploit — especially speculative execution.

What are Spectre and Meltdown?

• Spectre: This vulnerability takes advantage of speculative execution to trick the CPU into accessing data it shouldn’t. Attackers can use timing attacks to read this data, potentially exposing sensitive information. Spectre affects multiple CPU manufacturers, including Intel and AMD.
• Meltdown: Similar to Spectre, Meltdown specifically targets the way Intel CPUs isolate memory between applications and the OS. It can allow malicious applications to read memory they don’t own, essentially breaking the isolation barrier.

What is L1TF, and How Does it Differ?

L1TF is closely related to Meltdown and Spectre but specifically targets data in the L1 cache. In multi-threaded environments, such as virtualized systems, an attacker could potentially read data from other VMs on the same host by exploiting this vulnerability.

What makes L1TF particularly concerning is that it can allow a malicious user to access data on the L1 cache shared by another VM. For homelabs or enterprise environments using virtualization, this opens up risks in ways previous vulnerabilities did not.

Checking if our CPU was affected:

To determine if my homelab’s CPUs were vulnerable to L1TF, I SSHed into the ESXi server and checked if it was prone to the vulnerability, which revealed that my system was indeed susceptible to L1TF.

Installing Necessary Tools and Prepare Test Scripts:
I mainly used two known POC for my attack scenarios below

1. crozone’s Spectre Proof of Concept (PoC), I downloaded basic scripts to test Spectre and Meltdown attacks within the same host.
2. gregvish’s l1tf Proof of Concept (PoC), I downloaded this script to test L1TF in HOST-TO-HOST, HOST-TO-GUEST

Attack scenarios and the outcome:

Guests/Testbed for attack

I haven’t included how they were/were not SUCCESSFUL as I will be demonstrating the attack on my YouTube channel

Scenario 1: Host-Only Spectre/Meltdown Test

This test examined whether a Spectre/Meltdown attack was feasible within a single host environment.

• Execution: Using the Spectre PoC, I executed the exploit in an isolated environment within the same ubuntu VM.
• Outcome: Successful. The PoC confirmed that L1 cache could be probed under certain conditions, which allowed minor data leakage.

Scenario 2: Host-to-Host Communication

This test explored whether two virtualized environments on the same physical machine could interfere with each other’s L1 caches through the hypervisor.

• Execution: Using the l1tf-poc and adapting cache timing to explore possible interference.
• Outcome: Limited data leakage due to security features in the hypervisor. Although some cache timing differences were observed, the leakage was minimal, showing that hypervisors offer reasonable protection against direct L1TF exploitation.

Scenario 3: Host-to-VM Vulnerability Testing

In the final scenario, I examined if an exploit from the host could access data within a VM or use cache-timed attacks.

• Execution: Running ESXi on one box, I attempted to probe the VM environment from the host side.
• Outcome: Some data leakage from VM to host was observed, but VM-to-host attacks were unsuccessful due to ESXi’s strict isolation controls.

Lessons Learned and Implications

1. Security Strengths of ESXi
   ESXi shows strong resilience against speculative execution attacks, with built-in mitigations that effectively isolate VM processes. However, its restrictive environment limits kernel-level experimentation, making it less suitable for deep security testing compared to more open hypervisors.
2. ESXi Limitations in Security Research
   While ideal for stable production use, ESXi’s closed system restricts memory and cache-level tests. For homelab users focused on exploring exploits or advanced CPU vulnerabilities, KVM/QEMU provides greater flexibility.
3. Speculative Execution Trade-offs
   Exploring L1TF highlights the performance vs. security trade-off in speculative execution. Configuring hyper-threading and applying mitigations, though they will reduce the performance, provide vital protections.

Remediation

If your infrastructure shows susceptibility to L1TF or speculative execution vulnerabilities, there are a few effective ways to mitigate risk:

1. Disable Hyper-Threading: Disabling hyper-threading reduces the likelihood of data leaks across logical processors by ensuring that CPU cache lines aren’t shared between threads. This step can limit performance in multi-threaded applications but significantly reduces vulnerability to these types of attacks.
2. Update or Replace CPUs: Upgrading to CPUs with built-in hardware mitigations against speculative execution vulnerabilities (typically newer generations post-2019) offers the most secure long-term solution. These CPUs address speculative execution attacks at the hardware level and provide improved security without compromising hyper-threading.
3. Apply Hypervisor and Firmware Updates: Regularly apply the latest patches and firmware updates from VMware and CPU manufacturers. These updates often include software-based mitigations specifically designed to reduce vulnerability to speculative execution attacks, including L1TF.

By implementing these steps, you can reduce the security risks posed by speculative execution vulnerabilities in virtualized environments.

Personally, I won’t be implementing these remediation steps in my homelab environment. Since I don’t have sensitive data on these VMs, and they aren’t accessible from the outside world, the risks are minimal.

This setup is primarily for educational purposes, so I’m comfortable proceeding without making hardware or configuration changes.

Conclusion

Though technically susceptible to L1TF and speculative execution vulnerabilities like Spectre and Meltdown, we were unable to exploit ESXi for host-to-host or host-to-guest attacks.

This outcome is largely due to the hypervisor’s robust isolation mechanisms and the complex nature of ensuring the CPU accesses overlapping cache regions in these controlled environments. These protections make it exceptionally challenging to mount practical attacks on VMs or the host itself.