Guest written by: James Lyne, Head of Research and Development, SANS Institute
Last week, the IT industry discovered two flaws, dubbed Spectre and Meltdown. The first impacts a huge range of processors, potentially cloud and mobile, Macs and PCs. The second has been patched on most platforms – IF people apply the patch. Spectre is really hard to mitigate and will require lots of specific work in individual programmes. That means a very long tail of changes, or disabling a feature that will hit performance extremely hard on modern devices.
These aren’t hardware flaws per se at the level of silicon in a computer processor, but rather at the low level of the architecture of a computer – the huge number of transistors and logic gates that work to execute the complex instructions that make up the majority of what your computer does. These work with software, layers of complexity upon layers of complexity to achieve the marvel of a modern computer.
The Meltdown flaw allows computer programmes to violate access restrictions and access protected memory. Segregating memory prevents processes tampering with each other, or with the operating system of the computer, but breaking down these walls allows one process to peer inside another. This opens up the possibility of privilege escalation or information leakage of a most severe kind.
Thankfully patches for Meltdown are already forthcoming which build a more robust wall around the kernel, the most sensitive and crucial part of a computer’s memory. Meltdown primarily impacts Intel (a broad range of chips) but is relatively easily mitigated. As per usual this will depend on people applying patches in a timely fashion. Note that some cloud providers are already releasing updated platforms, such as the Amazon Cloud Linux images.
Things are more complicated for Spectre and the phrase “it depends” will be deployed more heavily depending on the environment of attack. Spectre works a little differently and impacts a broader range of processors and architectures – including in some conditions cloud environments or even mobile phones. Modern computers are incredible. When you run a programme did you know that the CPU speculatively executes the code in the programme that is not yet needed?
The extra capacity in a modern processor enables it to skip ahead and do work (that it might never need and may just throw away) in case you trigger that branch of code just to speed it all up. This all happens without you knowing and far below the peeking eyes of most software developers, until something like Spectre comes along. Unfortunately, that very desirable performance optimisation enables attackers, in the right conditions, to trick a programme into exposing sensitive protected memory.
Spectre, whilst extremely low level in a computer’s architecture, has a proof of concept that shows using JavaScript, a highly common web language used frequently in web browsers, to trigger the defect. There are specific configuration options that make Spectre exploitation tougher, such as the ‘site isolation’ feature in Google Chrome. Though this is not the default and many won’t enable it. We are likely to see a flurry of different implementations and exploit examples developed atop Spectre in the coming days and weeks.
The primary risk of Spectre exploitation is local, as in on your computer, rather than over the network remotely. This doesn’t prevent Spectre being used as a part of an attack to great effect but its more probable use cause is local privilege escalation once an attacker has already established a beachhead.
Patching Spectre, unlike Meltdown, is much more challenging. The authors of the paper detailing the techniques note that there are numerous mechanisms or checks and balances that could be inserted to prevent Spectre, but inserting these would have a notable performance impact.
Also, legacy applications would be a significant challenge as they would have to be re-built. It is also not sufficient to just patch sensitive/security related code in applications as other seemingly non-critical code could be used as the basis of attack. We can expect a much longer tail of Spectre impact than Meltdown through 2018.
What about preventing this kind of thing in future? In the land between low-level software development and hardware, careful co-ordination and common understanding is crucial to avoid defects such as this. Such flaws bypass the most fundamental security models of computers at a level few developers and security researchers ever touch.
The industry at large became aware of this flaw after patches for Meltdown were introduced to open source software, principally Linux, which raised alarms for the upcoming announcement. Patching open source software against such flaws without anyone noticing was always going to be pretty much impossible.
This flaw is an excellent reminder that we cannot rest on our laurels and that as security researchers we can’t just focus on high level flaws, such as the litany of web application attacks used by cyber criminals hourly. The modern computer is a miracle of co-ordination, high speed operations, logic and design that achieves incredible tasks for you. Stacked in the many layers of complexity there are always opportunities for new techniques and flaws.
I doff my cap to the incredible research behind these flaws and the extremely detailed research paper documenting them. This is a fine example of why security researchers need low-level skills and should study how processors, memory and other such concepts really work. SANS courses like 660/760 exist for this very reason – looking at low level flaws and developing detailed low level security researchers are important as this flaw that sits below a level most developers would ever touch or even know existed
In the wake of patches and progressive mitigations against Meltdown and Spectre we will see some significant performance hits to a vast array of computing devices and architectures. Whilst the more local exploitation nature of the flaw prevents this having the dambusteresque impact of WannaCry and its associated government developed exploit, we are likely to see this flaw raise its head many times over the next year. This will be one to watch in the coming weeks as more implementations come forth.”
