Meltdown, Spectre and related exploits

From Embedded Lab Vienna for IoT & Security
Jump to: navigation, search

Summary

First disclosed in 2018, Meltdown and Spectre are hardware leveled exploits. They both apply so-called side channel attack strategies and speculative execution to gather access to otherwise protected data. While Meltdown (which mostly affected Intel hardware) grants attackers access to Kernel-level information from a user-level point of entry, Spectre allows attackers to access data from different users or programmes running on the same hardware (and affected basically every modern computer system). While read access is slow, applying these exploits in a cloud environment poses a huge threat: A program observing information and data running on the same physical device (but on different virtual machines) can slowly but surely gather confident information. Developers of the most prominent hardware and operating systems had been informed before the disclosure of the exploits, and as such, both exploits have since been fixed. It should be noted, however, that first patches were, although almost immediate, far from final and were highly criticized - performance issues and spontaneous reboots were among the most overtly criticized issues. As speculative execution is both a way to speed up processing tasks as well as it by design poses a certain uncertainty, follow-up exploits applying similar strategies still appear from time to time. Especially noteworthy is Netspectre, which does not even require local execution of malicious code. Hence, while private end users not in the cloud are not the primary target group, the theoretical destructive potential of such exploits is still very present.

Requirements and notes

  • Basically all Intel CPUs manufactered between 1995 and 2018 are vulnerable to both Spectre and Meltdown, as well as regular modern operating systems BEFORE early 2018 (which is when patches have been released).
  • AMD CPUs are not suspectible to Meltdown, but they are vulnerable to Spectre. They too have since been patched.
  • Patching has been done both on the level of operating systems as well as with CPU developers themselves issuing BIOS update patches.
  • As mentioned before, while all operating systems and CPU brands were affected, the biggest threat lured in a cloud environment - a double hit for cloud computing companies, as the patches usually cost some performance - a hefty price for a business model based on selling performance, but one they had to pay given the severity of danger in a clouded environment with these exploits unfixed.
  • It almost goes without saying, but in order for these exploits to actually amount to anything, the systems to be compromised must be connected to the internet in some way - while you theoretically could spread the malicious code among retro-enthusiasts via 3,5" floppy disks, the secretive data gathered would never leave the system in that scenario.

Historical background

The exploits were disclosed in January 2018, and the research as well as the publication was handled by Google Project Zero, Cyberus Technology and the Technical University Graz. As developers of the largest CPU brands and operating systems had been contacted as mid 2017, the fist sets of patches were issued simultaneously, although developers of smaller Linux branches complained about receiving second-class security information. First patches seemed to come with terrible performance implications, especially for Intel systems, and in general Intel's statements around that time caused some distrust from people such as Linus Torvald. Some operating systems (or its iterations) and some hardware devices, in both cases mostly old variations, never saw any patches being deployed.

Netspectre was first documented in the late summer of 2018.

All of these exploits were disclosed without a definite account on damages already caused - they were merely the result of researchers coming to the conclusion that the existing architecture could be abused in such ways. Companies are not exactly known to disclose all the issues of their own hardware they are aware of, and neither are people who make a living off compromising other people's security, so it is unknown how many more exploits exist and how many more are currently even being employed in the wild. The most recent similar exploit at the time of this writing (early 2021) is Platypus.

Description of how Spectre works

Spectre gets its name from an abuse of the SPECulative execution present in basically any modern computer: Before it is even ensured that an operation is legitimate, the CPU will - based on "experience" - potentially "speculatively" execute it immediately. The legitimacy of a command may depend on what the follow up command is, and to potentially save time once the execution proves legit, "experience" is applied to guess if that is even likely. Such "experience", of course, can be misleading if the attacker decidedly trains the branch predictor to assume as it is desirable for them. Of course, if the operation eventuall proves illegitimate, the operation itself will not be executed. However, when trying to access a restricted set of data, the results of the SPECULATIVE execution alone are reflected in the cache. The content of said cache can then be gathered using a side channel attack - piece by piece accessing data outside of the legitimate range of an object, and checking if the data is present immediately (= it is cached) or if it takes time (= it will THEN be cached).

There are two versions of Spectre - one focuses on Branch Target Injection, which can be used to execute malicious code out of order, and one on the Bounds Check Bypass, which is the bypassing of security restrictions described above.

Spectre attacks are very slow in gathering data and require local execution of malicious code in the first place. They do, however, grant read-access to data out of the current user's range of permissions.

Sample code for Spectre variant 1: Bounds Check Bypass (CVE-2017-5753):

if (x < array1_size)
	y = array2[array1[x] * 4096 ];

Here, the range of an array is breached, and as a consequence, data from an entirely different address space accessed.

Sample code for Spectre variant 2: Branch Target Execution (CVE-2017-5715):

\begin{lstlisting}
	class Shape {
	 public:
	  virtual void Draw() = 0;
	};
	class Circle : public Shape {
	 public:
	  void Draw() override { … }
	};

	Shape* obj = new Circle;
	obj->Draw();

This uses polymorphism to "mislead" the machine to resolve the relevant address space where to store data on the fly: As it is not sure which type of object will be created at the time of compilation (due to polymorphism), this requires - again - speculative execution and addressing.

Description of how Meltdown works

Somewhat misleading, Meltdown ALSO applies speculative execution. It does, however, also apply Intel-only escalation of privilege to "melt down" security barriers. This distinction is impactful mostly on the "internal" side, the result is however still data that data which should be confidential can be accessed by attackers. The difference as far as this goes is that Meltdown allows access of Kernel level information from a user level.


Sample code for Meltdown (CVE-2017-5754):

char val = *(char *)0xAAAAA;

As can be seen, the actual principle of the attack does NOT differ fundamentally from the one of Spectre's Bound Check Bypass: A restricted address value is accessed, this request is speculatively executed, then denied, then nonetheless accessed indirectly. Meltdown attacks, too, are very slow in gathering data and require local execution of malicious code in the first place.

Description of how Netspectre works

Netspectre has the big distinction of NOT requiring local execution of malicious code, and instead may even target servers, which then in turn become "complicit" in gathering data for the attacker. It, again, exploits speculative execution and a "mistraining" of branch prediction. Cache accessing is performed via paket flushing the machine.

References