Meltdown and Spectre have created quite a major wave in the media. One of the most important questions that kept users as well as datacenter operator up at night is the question as to how much impact the remediating patches would have. The question why and to what extent performance got priority over security has been raised – and it is not an easy one to answer.
Many reports point out the fact that CPU designs have undergone little or no change since the nineties, which is about right. To improve the performance of CPUs, models such as speculative execution were developed and used by Intel, AMD as well as Cyrix. The model offers several advantages when compared to how older processors used to work, especially in the area of performance.
When you talk about dealing with the hardware itself, you are automatically stepping outside the software-based realm that most of us live in. Almost everything we do, we do in software. A CPU, however, can do very little with software indeed when on its own. The reason for this is that a most software is written in a „higher“ programming language (e.g. C, C++, C#, Java etc.) which is human-readable and better comprehensible for humans. A processor on the other hand speaks an entirely different language called „micro code“. The “vocabulary” of this language is stored in a dedicated area of the CPU. This area of memory can be editable in order to optimize certain routines or to correct flaws. Other than in older-style CPUs, such as the 8 bit processor MOS 6502, the instruction sets were hard-wired into the chip’s design and could not be changed later on. This makes troubleshooting and bug remediation excruciatingly difficult during the development phase. And if a flaw was discovered after sales, one of the ways to address it was to issue a costly product recall and replacement of the entire CPU.
Right up until the eighties and into the early nineties, many programs used to be written in Assembler, since other programming languages had either not been invented yet or were not performant enough for the intended purpose. Assembler, on the other hand, is close enough to the actual hardware, which helped performance, while still being human-readable. Assembler instructions can usually be translated directly into micro code.
Making use of updateable micro code made it a lot easier to design new CPUs: circuits did not have to be redrawn, which lowered costs, saved time and offered a boost in performance.
The fact that one might use some software trickery to access the CPU’s internal memory where critical information is stored, was never considered to be a risk factor. For one, doing this requires expert knowledge about the processor’s internal workings. Also, the attacks which are now described are not trivial. As a theoretical and academical construct, this type of attack has existed for a while – but that was about it.
The problem is: all modern threat scenarios initial were of a more theoretical or even academic nature – until someone actually put them into practice.
Chip makers have learned another lesson with Meltdown and Spectre: internal communications within a CPU require adequate security. The fact that this has apparently not happened yet can of course be held against manufacturers, but doing this would be a little too easy.
It would imply that error-free hardware can be developed which does not require further improvement. This, however, is not and has never been the case in practice. There a many similar examples for this from other industries. Let’s take aviation, for instance: people never second-guessed certain things because up to a point they always worked and never posed a problem. It is only later that they were found to pose a risk, which requires changes. Of course, hindsight is always 20/20.
One example would be this:
there is a good reason why airplanes have more or less round windows, or at least rounded edges around those windows, which goes back to the de Havilland Comet, one of the first commercial passenger gets of the post-WWII era. Initially, it had large square windows, just as those that everyone had been familiar with for decades from their use in cars, trains and older aircraft. It was therefore safe to assume that square windows were the way to go, because there was no contraindication. After several fatal crashes, however, it turned out that square windows were problematic in aircraft with pressurized cabins (which were relatively new at the time). Extensive tests revealed that the pressure differences caused increased stress and metal fatigue in the corners of windows and doors, which was exacerbated over time with frequent pressurization cycles. The material in the stressed areas degraded over a certain time until it failed - the result was a sudden rapid decompression which fatally affected the structural integrity of the entire aircraft.
The problems were discovered and remedied in all future aircraft. Today, the rounded corners in aircraft windows are perfectly normal. Similar cases like this are not only the reason for today’s shapes in aircraft windows. They were also the reason that most passenger aircraft are required by law to have a “black box” recorder on board (which, despite its name, is not black, but usually painted in bright orange). There are countless other examples, such as the CAN bus in automobiles, which was never designed with a “connected” world in mind. The principle is the same: Things that were thought to be non-critical in the beginning turned out to be problematic, changes were made and the development moved on.
It will be the same with Meltdown and Spectre. By the way, those two are not the fist bugs which were discovered in processors and subsequently reported. For instance, there was the so-called F00F bug, which made the round in the mid-1990s. Back then, the bug could also be worked around by changes in the operating system. Without the required patch, an affected machine would crash, making data loss practically inevitable.
When it comes to updating microcode, manufacturers need to tread carefully. Backwards compatibility underpins many thing in the development process. This is all the more important when thinking about hardware in components of critical infrastructures. A hastily developed and deployed patch which breaks other things is the last thing both customers as well as manufacturers want. The planned micocode updates are likely going to experience another delay anyways - Intel has very recently announced that they are revoking one of the "Spectre" patches as it has caused random reboots in some systems.
It can be assumed that your devices have the security flaw. It affects basically all CPUs made after 1995. Mitigation is currently limited to installing the updates which were provided for the operating systems.
In order to be able to react to future incidents of a similar nature, it is important for businesses to develop a sustainable patch management strategy. This is vital to support the timely deployment of critical updates in a company network
Users as well as administrators should make sure that updates are only installed from trusted sources. By now, malware has surfaced which attempts to cash in on the insecurity of users by disguising itself as a Spectre/Meltdown patch. In fact, it turns the computer it is run on into a bot net client.
Thinking with a long-term strategy in mind is crucial for businesses.
Intel may have promised to provide microcode updates from CPUs made after 2013. It also stands to reason that future processor designs are reworked to address the flaws. The question remains, though, how susceptible future CPU designs are going to be for attacks.
Nowdays, many companies process data from external sources. This should be borne in mind, because malicious code can be hidden in such data. Therefore, organizations should always check whether known security issues exists in newly acquired hardware, and if so, install available patches. This is especially important since public interest in a security flaw like Meltdown wanes relatively quickly and runs the risk of falling off the map.
Whenever external data is processed, a decision must be made as to how far you trust the source of the data and how to ensure that any manipulation does not have far-reaching consequences.
Manipulating a system through data it processes is not a new idea either: this has been attempted successfully with DNA sequencing machines which processed a specially crafted sample. This particular attack scenario has no practical relevance (yet?), but it has been proven that it is possible. As mentioned earlier: all those attacks are initially a theoretical construct until someone decides to put it into practice.
We now provide a tool which you can use to check, whether your computer is suscpetible to the Spectre and Meltdown attacks.
The tool is free of charge, is compatible with any installed security solution and can be downloaded directly from our website.