{"id":3553,"date":"2020-03-10T21:58:00","date_gmt":"2020-03-10T20:58:00","guid":{"rendered":"https:\/\/webdev.atsec.us\/?p=3553"},"modified":"2024-07-25T22:02:13","modified_gmt":"2024-07-25T20:02:13","slug":"meltdown-attack-2-years-later","status":"publish","type":"post","link":"https:\/\/webdev.atsec.us\/meltdown-attack-2-years-later\/","title":{"rendered":"Meltdown Attack: 2 Years Later"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

by Richard Fant<\/font>

Meltdown Attack:  2 years later<\/strong>
In February 2017, independent security researchers discovered a catastrophic security flaw in the cache design for processors developed by Intel Corporation. After embargoing the information for almost a year while working on a fix, Intel publicly announced in January 2018 the security flaw known as the Meltdown Attack.

At a high level, the Meltdown Attack allows a user application to read data stored inside kernel level memory. In other words, it \u201cmelted down\u201d the security boundary between the user and the kernel.

How can a user program read data stored in restricted memory?<\/strong>
To reduce execution time, most modern processors implement a strategy called speculative execution (a.k.a. Out of Order Execution). While the details are proprietary, the basic idea is that by looking at the history of the most recently executed CPU instructions, the processor can \u201cspeculate\u201d what the user\u2019s code will do in the future. In the anticipation that its prediction will be true, the processor will pre-fetch data from memory and have it ready in cache and registers for those future instructions.

If the processor correctly predicts what data an instruction will need, the data can be fetched from the cache instead of main memory. And since cache access is orders of magnitude faster than memory accesses, the overall execution time is greatly reduced. On the other hand, if a processor\u2019s predictions about future instructions turns out to be false, the processor will simply clean up any registers and memory used in the speculation and continue execution.

This is the source of the vulnerability: the designers neglected to also clean up the \u201cdirty\u201d cache left behind after a failed speculation.

To illustrate this, consider the pseudo code below:<\/p>\n\n\n\n

for i=1 to 100
\u00a0\u00a0\u00a0 if (i==99) then
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 break;
\u00a0\u00a0\u00a0 else
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 array [i] += array [i] * 2;<\/code><\/p>\n\n\n\n

In this snippet, the processor notices that for the first 98 iterations, the \u201celse\u201d branch has been taken. It would be reasonable for the processor to predict that for the 99th iteration, the \u201celse\u201d branch will be taken once again. Because of this, the processor will pre-fetch the data at array [99] from memory and store it in cache. However, in this example, the 99th iteration in fact causes the for-loop to break out. However, the data stored in array [99] has already been stored in cache. Since the processor didn\u2019t flush the cache after its failed speculation, the cache is now \u201cdirty\u201d with data that should have been removed.

How is this flaw exploited?<\/strong>
A sophisticated attacker could set up a program where a user level request to kernel memory could be speculatively executed by the processor. Even though the kernel would eventually reject such a request, it has been publicly demonstrated that the user program can still read the \u201cdirty\u201d cache even after the speculation failed and the kernel rejected the access request. This is the basis for an ongoing race-condition between the speculative execution and the rejection of the request: if the request is rejected first, then there will be no speculation. If the speculation happens first, then the cache will already be dirty by the time the rejection happens. There are several published algorithms that can speed up the speculation and delay the rejection. This leads to dirty caches happening more often.

This means a malicious programmer could read all of kernel memory by methodically exploiting this flaw, byte by byte, using a dirty cache. This attack is especially devastating because the victim wouldn\u2019t even know the Meltdown Attack had occurred.

Who does this effect?<\/strong>
Speculative Execution was introduced on Intel processors in 1995. In December 2017, Intel and OEMs began releasing firmware & software fixes. The actual design flaw itself wasn\u2019t addressed in hardware until October 2018. This means that potentially any Intel processor manufactured between 1995 and 2018 is at risk. In addition, any Intel CPU implemented in a virtual machine could also have this vulnerability.

Where are we now, 2 years later?<\/strong>
As of today, there have been no published reports of any successful Meltdown Attacks in the real world. This doesn\u2019t mean these attacks haven\u2019t happened, just that they weren\u2019t reported (or possibly not even discovered by their victims). There have also been several variants of the Meltdown Attack discovered in the last two years which use the same flaw of a dirty cache with speculative execution.

Intel stated in October 2018 that their 9th-generation processor family would include additional protection against Meltdown. Of course, no details were provided since that could provide too much information for an attacker. Other companies like Apple and Microsoft have released applications that can determine if your processor is vulnerable to the Meltdown Attack.

Final Thoughts<\/strong>
Keep Calm and Carry On:\u00a0 if you have an Intel processor built in 2018 or earlier, you\u2019re probably at risk. Download any firmware or software updates that are recommended by your computer manufacturer. If your processor was built in 2019 or later, you should be safe from attacks of this kind.<\/p>\n","protected":false},"excerpt":{"rendered":"

by Richard Fant Meltdown Attack:  2 years laterIn February 2017, independent security researchers discovered a catastrophic security flaw in the cache design for processors developed by Intel Corporation. After embargoing the information for almost a year while working on a fix, Intel publicly announced in January 2018 the security flaw known as the Meltdown Attack. […]<\/p>\n","protected":false},"author":3,"featured_media":3554,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[7,9,1],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3553"}],"collection":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/comments?post=3553"}],"version-history":[{"count":1,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3553\/revisions"}],"predecessor-version":[{"id":3555,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3553\/revisions\/3555"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media\/3554"}],"wp:attachment":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media?parent=3553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/categories?post=3553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/tags?post=3553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}