hardware vulnerability in Apple processors
The big news last week was the announcement of a scientific paper by researchers from a number of US universities demonstrating the GoFetch hardware vulnerability in Apple M1 and M2 processors (
project, myself
detailed
in an Ars Technica article). The vulnerability makes it possible for a third-party channel attack on data encryption algorithms with subsequent theft of private keys. To do this, it is necessary to run malicious code on the victim’s computer that can control the algorithm. The attack itself takes from one to several hours, and right now it does not pose a threat to users. The consequences of discovering the vulnerability, however, will be: the problem in the system for loading data into the cache memory can only be closed programmatically, in specific implementations of encryption algorithms, which will lead to a decrease in performance.
The vulnerability was discovered in the context-sensitive data prefetcher (data memory-dependent prefetcher, or DMP). This is a fairly new technology, introduced so far only in the latest Apple chips and Intel processors starting from the 13th generation (in the latter, the mechanism works differently and this attack is not relevant for them). DMP is part of a set of optimizations aimed at improving computing performance: in general, such technologies have repeatedly become a source of problems in the past. The attack was demonstrated on laptops running Mac OS with Apple M1 and M2 processors. The latest M3 chips also contain this vulnerable optimization, but they include instructions to disable DMP for cryptographic calculations. For earlier processors, you will have to update the code using more complex methods to eliminate side-channel leaks.
The study builds on previous
2022, which studied the operation of DMP technology. At that time, the possibility of data leakage using a data prefetch mechanism was demonstrated, but it was not brought to the level of a practical attack. The job of any data prefetch mechanism is to find the appropriate commands in the executing code. When a pointer to a specific area of RAM is detected, data from there is loaded into the processor cache in advance, which speeds up program execution. DMP can be simplistically described as an additional optimization to this process that allows preloading of a dataset in complex cases. Classic prefetch mechanisms only work on specific memory access instructions. DMP analyzes the data itself, looking for what might be a pointer. This means that in some cases application data (in the case of cryptography, private encryption keys) can be mistakenly interpreted as commands to load data from memory.
As a result, a situation is created where access to a certain section of RAM “reveals” the data processed by the encryption algorithm. This breaks the main security principle of cryptographic algorithms, known as constant-time programming. Any encryption algorithm tries to eliminate the situation when the progress of calculations depends on the input data. A potential attacker works with the encryption algorithm as a “black box”: the specifics of its operation are unknown to him. But it can input arbitrary data to the algorithm that needs to be encrypted. If the speed of the algorithm changes depending on the incoming data, this allows in some cases to extract a private key that should remain a secret. In the case of DMP, a similar situation occurs: the malicious program does not see the data processed by the encryption algorithm. Likewise, it does not see data that is incorrectly accessed by the prefetch mechanism. But reading data from the processor cache is faster than from RAM, and it is this side channel that leaks secret information.
In practice, the attack looks like this. A malicious program with standard privileges on the system accesses the encryption algorithm and creates conditions for data leakage. The data that needs to be encrypted is shaped in a specific way to trigger the DMP optimization. Optimization creates conditions for data leakage, which over time makes it possible to reconstruct the private encryption key. Since we are dealing with a third-party channel, there should be a lot of such requests. Leaking a 2048-bit encryption key using the RSA algorithm takes about an hour; in the case of the Diffie-Hellman algorithm, with the same key length, the attack will take two hours. It is noteworthy that the attack works even with the latest encryption algorithms that are protected from quantum computing. For the Kyber-512 algorithm, the attack will also take an hour, but reconstructing the key for the Dilithium-2 algorithm will take about 10 hours. This data is for the Apple M1 processor, and only the time spent collecting the necessary data is taken into account. Their subsequent processing will also require time, for example another 4.5 hours for Dilithium-2. Another small limitation: the attacking program must be executed on the same cluster of processor cores with the encryption algorithm. In the Apple M1, productive and energy-efficient cores are grouped into separate clusters.
The researchers did not have the task of “putting the attack to work,” that is, creating conditions under which a stolen encryption key could be used to access other private data or generally cause any damage to the victim. Obviously, running arbitrary code on the attacked computer is in itself a problem for the user; in such a scenario, it is not at all necessary to exploit this particular vulnerability. The attack is similar in concept to previously discovered Specter vulnerabilities. All of these hardware vulnerabilities can be considered in the context of processing particularly sensitive data. They are also more dangerous in virtual environments where clients have the ability to run arbitrary code in their own sandbox. In the case of consumer (rather than server) Apple devices, potential harm could include access to private encrypted data (stored both in the operating system itself and in applications). But the practical feasibility of this type of attack still needs to be demonstrated.
As in the case of Specter, developers of cryptographic algorithms (the work, for example, examined implementations for the Go programming language and the OpenSSL library) will have to update the code to eliminate the possibility of such an attack. This is the only way to get rid of vulnerability. It will not be possible to patch this hardware problem for all algorithms at once. One solution is to obfuscate the data processed by the algorithm when stored in RAM. Obviously, this will lead to a drop in performance. In the case of methods to counteract Specter family vulnerabilities, performance drops in some tests ranged from 3 to 17 percent. It is not yet clear how laptops with Apple M1 and M2 processors will slow down. For non-specialized user applications, such as a browser, the slowdown is unlikely to be noticeable. In general, such a drop in performance usually plays a role on a large scale, when we are talking about tens of thousands of servers. For personal Apple devices, this logic is unlikely to apply. However, there remains a small chance of a truly dangerous attack, carried out, for example, in a browser.
The vulnerability is conditionally “closed” in Apple M3 processors. DMP optimization works the same way for them, but for developers of encryption algorithms there is a special flag that disables the ability of this technology to work. We'll likely learn more about the practical implications of this issue as relevant patches for Mac OS begin to appear. In the meantime, Apple, in its traditional style, refrains from commenting and does not disclose, unlike Intel and AMD, its own assessment of this hardware vulnerability.
What else happened
Latest publication by Kaspersky Lab experts
typical types of malware for Android devices.
Researchers found new method carrying out a DoS attack on basic network services (TFTP, DNS, NTP). More than 300 thousand servers are vulnerable.
Extremely interesting study security of Dormakaba's Saflok door locks used in hotels and opened using RFID technology. In the proposed attack scenario, the attacker checks into a hotel, receives a key card for his room and, based on data from it, creates a universal key that opens all the locks in the hotel.
Researchers from the American University of Colorado found serious problems in tracking devices for commercial vehicles and trucks. Communication with these devices over Wi-Fi and Bluetooth is virtually unsecured, and this problem can even be used to spread malware from device to device.
