Originally, this bomb was to be publicized only this week - or more precisely, defused and then made public in order to minimize the damage potential. These vulnerabilities are known to the processor manufacturers such as Intel, AMD, ARM already since summer 2017, one had only waited, because one wanted to deliver countermeasures. Gaps in the confidentiality agreements had led to unrest and massive information these days.
Spectre and Meltdown the two scenarios
Spectre and Meltdown are not about "bugs" or "vulnerabilities", but about hacks in the very classic sense. In principle, hardware and software work perfectly as intended by the developer. However, beyond the specified mode of operation, they also offer possibilities that even developers were not aware of until now. And each one of them allows potential attackers to call up and then read out data they neither call nor read out according to the nominal program flow.
What's behind it technically?
Modern CPUs require several clock cycles for their calculations, so there is inevitably between successive instructions to waiting times. For this reason, since the first Pentium from Intel all x86 CPUs (including those of other manufacturers) Out of Order (OoO). This means nothing else than that the processors themselves and not the software determine the order of instruction execution. In addition, the CPUs may prefer to avoid individual tasks, to permanently relieve computing units.
Second pillar is Speculative Execution, an extension that almost all OoO CPUs use. By being equipped with a (leap) prediction unit, they can not only execute already commissioned instructions, but also speculatively execute entries in the program code. Here, a CPU decides here itself due to relatively primitive analysis, which instructions could probably be called next. However, if speculative execution would have to wait for complex information and too slow system processes, then it could not provide any speed advantage. This behavior is also no problem for the nominal program flow. If an instruction is not called later, the result is rejected by the processor and the software does not learn anything about the entire process. The speed of the "computation" of the CPU arises only when the prediction is done correctly.
For the understanding of the following description is still the mention of Privilege Levels important. We are talking about Kernel-Space and User-Space. Each process works in its own virtual address space without any contact with other programs than the operating system. This separates part of the address space for system processes, that is the kernel space. In turn, application programs generally work in user space and only have access to the kernel space in approved exceptional cases. This is done via a syscall, which the operating system has to request from the CPU and wait for approval.
This security feature at the CPU level is provided by Privilege Level. And that means that for certain commands, in particular access to protected operating system data in kernel space, the CPU must first be put into the most privileged mode by the operating system.
Thus, an application process from the user space can never directly access data outside of its space, unless the operating system explicitly supports it. If it is still attempted, exceeding the privilege level ensures that the process is terminated prematurely prior to a data exchange.
This somewhat more prominent attack exploits a property previously proven only for Intel processors. Among other things, indirect memory accesses speculatively execute prior to its being called by a process; especially before the privilege level check has been completed. This means nothing else than that the accesses to the kernel space can be performed speculatively even if the program code belongs to a process of the user space.
If an attacker now additionally ensures that the logical program flow never actively calls the instruction, then even the privilege monitoring would not even protect because the processor would simply discard the supposedly undesired instruction. From the perspective of the software, this also ensures data security.
Spectre also tries to get illegitimate data access into the cache before it is aborted. But unlike Meltdown, Spectre does not work in its own address space, trying to melt the boundary between kernel and user space. In contrast, the work of foreign processes is used purposefully. These processes also regularly perform various types of dependent and indirect memory accesses; of course on memory addresses, which you may also use. The CPU also tries to accelerate these accesses speculatively using their branch prediction. The Achilles heel here is that the latter does not have the time to distinguish between ongoing processes. Frankly speaking, from a performance perspective, this is not desirable at all, because many operations run the same way in different programs and can thus benefit from the same optimization.
Now Spectre provides codeframes of the attacked process in its own user space and thus trains the jump prediction to a predefined target by the attacker. Later, when the target process starts its copy of the code, the trained jump prediction will erroneously perform a speculative execution based on the attacker's trained parameters. This procedure can now be used again to initiate specific charging patterns depending on actually unattainable information. In the simple case (Spectre 1), this is done by passing security checks of the target itself and allowing subsequent safety-related instructions to be executed speculatively in an abusive manner. In the more complex case (Spectre 2) this is done by provoking an indirect jump to any (load) instruction desired by the attacker.
What does that mean as potential danger?
The positive aspect is that both attack scenarios can only perform read-only access. The manipulation of data, the encryption of hard disks or data or the transfer of entire computers are not possible. However, all data, such as passwords and credentials, whether they are stored in password managers or entered manually, can potentially be eavesdropped.
Since the technology described has existed since Intel's Pentium I and many other CPU manufacturers also use the technology, the vulnerable processors have been used in a variety of devices for years. This can be desktop computers as well as laptops, smartphones, tablets, automotive on-board computers, streaming boxes, just to name a few. Equally fatal are the "things of Internet" devices (kitchen appliances, smart home devices, etc.), because all should react as possible in real time and thus have a high probability one of the vulnerable processors. Affected are, among other things, all Intel Core processors until the year 2008 and a variety of ARM Cortex CPUs. Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 processors are susceptible to at least one of the variants and Cortex-A75.
On the other hand, according to the current state of knowledge, AMD processors are in fact at least susceptible to one of the three attack scenarios (Spectre 1). AMD assumes that AMD processors are not vulnerable to Spectre 2 because of their architecture.
Which operating systems are affected?
Since this is a hardware issue, all operating systems are affected. So Windows as well as Linux (all distributions), Apple's macOS, FreeBSD and the smartphone systems Android and iOS.
What protection is there against?
Although security updates are urgently recommended, they can not fix the processor gaps. This would require the replacement of newly developed processors, combined with the appropriate motherboards and, of course, complete new installations.
Nevertheless, the already rolled out updates should urgently be installed and, above all, applications such as the Firefox browser or Chrome, not to mention the Windows browser, and drivers must be secured. Because malicious software can gain access to these vulnerabilities through these applications.
Are Meltdown and Spectre also a remote threat?
Is there any impact of updates on performance?
After the performance-enhancing functionality of the CPUs is the problem and software updates close the gap, there will inevitably be a loss of performance. However, how much the performance loss will be quantified depends entirely on the usage scenario.
Normal users running processors from the Intel Core i-6000 series (Skylake) are unlikely to feel the braking effect of the patches because they are in the single-digit percentage range. That let at least Microsoft already announced. By contrast, users from older processors to the Haswell Generation Core i-4000 will notice a drop in system performance. At least, benchmarks have already shown a significant slowdown. Thus, the older the processor and the operating system are, the more noticeable the braking effects become.
By contrast, high performance reductions are likely to be noticed by server farm and cloud service operators, who generally expect a high number of I / O operations.