{"id":52996,"date":"2025-02-10T11:01:16","date_gmt":"2025-02-10T16:01:16","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=52996"},"modified":"2025-02-10T11:01:16","modified_gmt":"2025-02-10T16:01:16","slug":"slap-flop-attacks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/slap-flop-attacks\/52996\/","title":{"rendered":"SLAP and FLOP: Complex vulnerabilities in Apple CPUs"},"content":{"rendered":"

Researchers from universities in Germany and the U.S. recently showcased<\/a> an interesting attack \u2014 or rather, two attacks \u2014 exploiting two different vulnerabilities in Apple CPUs. Picture this: someone sends you a link in a chat. When you click it, nothing looks suspicious at first. It doesn\u2019t ask for your work email password, doesn\u2019t try to get you to download a sketchy file. The page might even contain something fun or useful. But while you\u2019re busy browsing it, hidden code is secretly harvesting data from another browser tab \u00a0\u2014 checking your location, recent online purchases, and even stealing your emails.<\/p>\n

The description of the attack seems simple enough, but in reality, we\u2019re talking about a very complex attack that exploits the features of so-called speculative execution by the CPU.<\/p>\n

Wait a minute! Haven\u2019t we heard this before?<\/h2>\n

You just might have. The core idea of the new attacks resembles various Spectre-type attacks that exploit other, albeit somewhat similar, vulnerabilities in Intel and AMD CPUs. We\u2019ve covered those attacks before. In 2022, four years after the first Spectre vulnerability was discovered, we concluded<\/a> that there was no realistic, easy, or effective way to exploit those vulnerabilities. Although exploiting these new Apple chip vulnerabilities isn\u2019t straightforward either, the difference this time is that the researchers have already provided fairly realistic attack scenarios and proved their feasibility. To see just how dangerous these vulnerabilities are, let\u2019s briefly recap the basic principles behind all such attacks without getting bogged down in complicated research.<\/p>\n

Exploiting speculative execution logic<\/h2>\n

Speculative execution refers to a situation where the processor executes the next instruction without waiting for the previous one to finish. Let\u2019s draw a somewhat odd yet helpful analogy here with a car. Imagine your car starts the engine automatically every time you approach it. If you\u2019re just passing by, the engine stops (as such, the operation is unnecessary). But if you\u2019re about to set off driving, it\u2019s ready to go as soon as you get in.<\/p>\n

Similarly, a CPU can decide to run an operation in speculative execution mode. And by the time the previous computation is complete, the program\u2019s logic might have changed, making this operation unnecessary; in this case it\u2019s discarded. CPU designers utilize a variety of techniques to improve branch-predictor capability to forecast instructions that are most likely to be executed next. To accomplish this, they gather instruction execution statistics: if a certain code segment is always invoked under particular conditions, it\u2019s probable that it will be invoked under the same conditions again.<\/p>\n

Such a computation may involve rather sensitive operations such as accessing protected memory areas containing secret data. The issue lies in the fact that even if a program shouldn\u2019t have access to such data, it can still potentially \u201ctrain\u201d the speculative execution algorithm to access it.<\/p>\n

Before the Spectre attack was discovered in August 2018, it wasn\u2019t considered to be a data leakage risk. Secret information, such as encryption keys and private user data, is stored in the restricted-access CPU cache. However, the researchers who discovered Spectre found that cached data could be extracted indirectly \u2014 by performing hundreds and thousands of read operations and measuring the execution time of these instructions. They found that one could \u201cguess\u201d cached values that way: if the guess is correct, the instruction would execute fractions of a second faster.<\/p>\n

So, there are two crucial components to a Spectre-like attack. One is the ability to trick the speculative execution algorithm into accessing a forbidden memory area. The other is the capability to read this data indirectly through a side channel.<\/p>\n

SLAP and FLOP attacks on Apple CPUs<\/h2>\n

The researchers from Germany and the U.S. wrote two separate papers at once \u2014 because they\u2019d discovered two different vulnerabilities in Apple CPUs. One issue was found in the Load Address Predictor. This is one of many speculative execution systems that predicts the RAM address that a running program will most likely access. The second vulnerability was found in the Load Value Predictor system. This additionally attempts to anticipate the actual value that will be retrieved from RAM.<\/p>\n

The researchers named the two attacks \u201cSLAP\u201d and \u201cFLOP\u201d: short for \u201cSpeculative Load Address Prediction\u201d and \u201cFalse Load Output Prediction\u201d. Although both attacks have a common principle and result in a similar outcome, the methods of exploiting these vulnerabilities differ significantly \u2014 hence the two different studies. In the former case, the researchers demonstrated how the Load Address Predictor could be exploited to read restricted data. In the second case, while no data was actually read, the system\u2019s accurate prediction of what would be read could again expose sensitive information.<\/p>\n

How dangerous are SLAP and FLOP attacks?<\/h2>\n

Nearly all Spectre-type attacks are subject to numerous limitations that hinder their practical use for malicious purposes:<\/p>\n

    \n
  • The \u201cmalicious code\u201d exploiting a vulnerability in the speculative execution system must be running on the same CPU core as the targeted process.<\/li>\n
  • The ability to steal data often depends on the presence of code with certain features in the OS kernel or other software that the attacker has no control over.<\/li>\n
  • Carrying out a remote attack over a network or through a browser is extremely difficult because measuring the instruction execution time to obtain data through a side channel becomes a lot more complicated.<\/li>\n<\/ul>\n

    Therefore, all previous attacks could be categorized as very complex, and only applicable for attempts to access highly valuable data, which means the attacker needed considerable resources to develop such an attack. All in all, that\u2019s good news, as patching certain hardware vulnerabilities in production CPUs is either virtually impossible or associated with a substantial decrease in performance.<\/p>\n

    SLAP and FLOP open up a different perspective. They affect the latest processors made by Apple. The Load Address Predictor was introduced on desktop computers and laptops with the Apple M2 CPU model, and mobile devices with the Apple A15. The more advanced Load Value Predictor first appeared in the Apple M3 and A17, respectively.<\/p>\n

    Implementing these attacks is still a challenge. However, a key difference in this study compared to previous ones is that it immediately both proposed and verified the feasibility of practical attacks. The researchers demonstrated how SLAP and FLOP can be used to bypass multiple security layers both in the CPU and the Safari browser to gain access to sensitive data.<\/p>\n

    This alone might not be enough reason for cybercriminals to develop functional malware targeting Apple devices; however, there are other reasons why attempts to use SLAP and FLOP could be made in the wild.<\/p>\n

    Apple devices are rather well protected. Exploits allowing one to bypass an iPhone\u2019s security system and gain access to the owner\u2019s private data command exorbitant prices on the gray and black markets. Thus, it\u2019s reasonable to assume that a hardware vulnerability that\u2019s highly likely to remain at least partially unfixed will be exploited in targeted attacks when particularly valuable data is sought. It\u2019s therefore not out of the question that we\u2019ll see such vulnerabilities exploited in targeted attacks on Apple devices.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

    New research demonstrates for the first time how hardware vulnerabilities in modern CPUs can be exploited in practice.<\/p>\n","protected":false},"author":665,"featured_media":52997,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051,3052],"tags":[14,3116,1226,268],"class_list":{"0":"post-52996","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-apple","11":"tag-cpu","12":"tag-hardware","13":"tag-vulnerabilities"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/slap-flop-attacks\/52996\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/slap-flop-attacks\/28555\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/slap-flop-attacks\/23794\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/slap-flop-attacks\/28667\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/slap-flop-attacks\/39027\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/slap-flop-attacks\/28796\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/slap-flop-attacks\/34621\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/slap-flop-attacks\/34249\/"}],"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\/52996","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=52996"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/52996\/revisions"}],"predecessor-version":[{"id":52998,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/52996\/revisions\/52998"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/52997"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=52996"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=52996"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=52996"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}