{"id":48229,"date":"2023-05-19T10:31:04","date_gmt":"2023-05-19T14:31:04","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=48229"},"modified":"2023-05-19T10:31:04","modified_gmt":"2023-05-19T14:31:04","slug":"transient-cpu-eflags","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/transient-cpu-eflags\/48229\/","title":{"rendered":"New hardware vulnerability in Intel processors"},"content":{"rendered":"

Researchers at both the University of Maryland in the U.S. and Tsinghua University in China have published a scientific paper<\/a> documenting a new side-channel attack method that exploits a previously unknown hardware vulnerability in Intel processors. Although the vulnerability seems to affect the chipmaker\u2019s latest processors, it\u2019s most effective in attacking older models that are also exposed to the Meltdown<\/a> vulnerability. The paper would likely be purely of scientific interest were it not for one aspect: attackers steal sensitive information by changing flag register<\/a> data.<\/p>\n

In English, please<\/h2>\n

Hardware processor vulnerabilities linked to speculative execution of instructions have been the subject of much research for more than five years<\/a>. To simplify as much as possible, all the proposed attacks can be summed up as follows: the CPU is somehow forced to read data that user should not have access to. Imagine this theoretical scenario: the attackers\u2019 program doesn\u2019t have access to the encryption key used to protect sensitive data. If we instruct the CPU to \u201cread the encryption key at a certain address\u201d, the instruction simply won\u2019t be followed. Help arrives (to the attacker) in the form of speculative execution<\/a> of instructions \u2013 an important feature of modern CPUs, which has been around for almost three decades: to speed things up, instead of waiting for one instruction to finish, the processor executes the next in parallel.<\/p>\n

If the first instruction checks access rights to sensitive information, it should in theory not allow execution of the following instruction to read this information. But it\u2019s too late: the following instruction is being executed speculatively. Note that we don\u2019t yet have access to this data \u2013 but the CPU does. In the case of known vulnerabilities such as Spectre<\/a>, data is temporarily loaded into the CPU\u2019s cache, but it can\u2019t be read just like that. However, it can be read through side channels; for example, by repeatedly executing an instruction \u2013 the processing time of which varies depending on the data in the cache. Repeating such an operation many (thousands of!) times allows attackers to recover data just by watching how quickly or slowly some seemingly harmless command is executed.<\/p>\n

We realize that this \u201csimple\u201d description still sounds complicated. The new paper is even more perplexing, especially since the authors decided not to spend time on a detailed description of the attack. The diagram below outlines it in full:<\/p>\n

\"Overview

Overview of transient execution timing side-channel. Source<\/a>.<\/p><\/div>\n

Let\u2019s try to figure it out. EFLAGS is a flag register in the Intel processor that keeps track of the CPU\u2019s operating status. It can store<\/a> the result of calculations, in particular if this is equal to zero (the so-called zero flag or ZF). Next comes the magic: imagine a colleague of yours thinks of a number from 1 to 10 and is told to keep it to themselves. You keep calling out the numbers 1 through 10 (looking for whatever signs could give your colleague away), but they don\u2019t want to share the correct answer with you, and respond each time with the word \u201cchrysanthemum\u201d. However, when you utter the correct number, they take a little longer to say \u201cchrysanthemum\u201d compared with other times.<\/p>\n

Something similar happens in this new attack: we perform numerous calculations with sensitive data. All these calculations are done speculatively. The result is written to the ZF flag (equal or not equal to zero). We can\u2019t directly know the status of this flag. But then we execute a rather useless JCC instruction (specifically the JZ instruction \u2013 \u201cjump if zero\u201d), which runs a little slower if we guessed right! And it\u2019s this measurable delay in the response that constitutes the vulnerability.<\/p>\n

Not yet a problem<\/h2>\n

The most interesting aspect of this attack is that it doesn\u2019t work by itself. To ensure that speculative execution of the required instructions is possible, the bad guys need to exploit one more vulnerability. The paper we\u2019re discussing uses the Meltdown<\/a> vulnerability, discovered in 2018, which happily provides access to information that\u2019s off-limits to outsiders. As a result, sensitive data was read with 100% reliability on all old CPUs affected by this vulnerability (the study used sixth and seventh-generation Intel Core i7). Although the experiment failed on tenth-generation CPUs, they too experience some delay when executing a certain instruction from the JCC set.<\/p>\n

In reality, even more versatile types of attacks like Spectre, which steal information from the CPU\u2019s cache, have a rather narrow application. But at least in their case it was obvious that something had to be done with them: the likelihood of an advanced attack targeting critical data was non-zero. As for the new paper, we\u2019re dealing more with an idea that, if it works at all, it applies to older Intel processors.<\/p>\n

But the news itself is significant: there\u2019s now a new side-channel mechanism for extracting data using the flag status register. It can\u2019t be ruled out that in the future this approach, combined with some other vulnerability, will impact new CPUs as well. Or maybe it will all be resolved before we see a new attack: after all, dependence of the instruction execution time on the data is quite a serious issue. There\u2019s an entire subdiscipline of cryptography that deals with protection of encryption algorithms from timing attacks<\/a>.<\/p>\n

In any case, research into the specifics of modern CPUs is ongoing. Fortunately, executing attacks on hardware vulnerabilities is just as difficult as understanding them. And although we\u2019ve yet to see anything that could be applied on a massive scale, infosec officers in companies that handle highly sensitive data would be wise to factor in such threats and, at a minimum, monitor their evolution.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

A brief, plain-language explanation of an advanced method of data theft using features of modern CPUs. <\/p>\n","protected":false},"author":665,"featured_media":48231,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051],"tags":[3116,4351,268],"class_list":{"0":"post-48229","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-cpu","10":"tag-processors","11":"tag-vulnerabilities"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/transient-cpu-eflags\/48229\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/transient-cpu-eflags\/25691\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/transient-cpu-eflags\/21110\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/transient-cpu-eflags\/28346\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/transient-cpu-eflags\/25991\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/transient-cpu-eflags\/26367\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/transient-cpu-eflags\/28862\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/transient-cpu-eflags\/35326\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/transient-cpu-eflags\/20650\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/transient-cpu-eflags\/21345\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/transient-cpu-eflags\/30181\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/transient-cpu-eflags\/26296\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/transient-cpu-eflags\/31998\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/transient-cpu-eflags\/31686\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/vulnerabilities\/","name":"vulnerabilities"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/48229","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=48229"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/48229\/revisions"}],"predecessor-version":[{"id":48235,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/48229\/revisions\/48235"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/48231"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=48229"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=48229"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=48229"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}