Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:00 PM
Andrew Mayo
Andrew Mayo

The Nightmare Before Christmas: Security Flaws Inside our Computers

How an Intel design decision with no review by industry security consultants led to one of the biggest vulnerabilities in recent history.

Towards the middle of last year, some researchers at the University of Graz published a paper in which they proposed a new mitigation for a software vulnerability associated with something called ASLR. They called this mitigation KAISER.

ASLR – Address Space Layout Randomization – is a widely-used technique for ensuring that malware can’t easily find out where critical data is loaded into a running process, and subsequently exploit this. Effectively the various pieces of a process are loaded into randomly chosen memory locations, which change each time the process is loaded.

ASLR is only one defense, of course, and it isn’t perfect. Attacks on ASLR have been known for a long time. Consequently, it was rather surprising that, not long after this, the Linux kernel team, Microsoft, and Apple, all started working on patches ostensibly to implement KAISER. The changes were non-trivial and would have significant performance overheads. Not only this, but unexplained maintenance shutdowns were scheduled for Azure and AWS early in the New Year.

We now know that a small number of privileged insiders had knowledge about a much more serious security vulnerability. Unlike most vulnerabilities, this one was intrinsic to the very hardware on which software runs, specifically, Intel CPUs. Worse, this problem could not be resolved with a simple microcode update. It was intrinsic to the design of the CPU chip itself. Software workarounds were complex and imposed significant performance penalties.

So what did these insiders know? It’s believed the flaw lies in the way Intel processors handle access to data in memory.

When a user task requests access to a location in memory, its privileges must be checked. If the task doesn’t have the right privileges, it will not be allowed to read the memory location. But before data from memory is handed back to the requesting task, it is first placed in one of the caches built into the CPU. Caches are just special blocks of very fast memory, intended to ensure that if the same data is requested again, it’ll be right there when it’s needed.

Intel decided to design their CPU so that data is placed in the cache regardless of the requesting task’s privileges. They then checked the permissions of the task after doing this. If the task lacked the required permissions, then it would not receive the requested data and a fault operation would be raised.

But Intel’s design decision had a serious consequence. It is possible for malware to use so-called side-channel attacks to determine the contents of cache memory, even though the malicious software has no direct access to the cache. For example, by measuring how long it takes to retrieve requested data, malicious software can infer what’s cached. That’s a serious problem, because apart from sensitive operating system data, including things like encryption keys, virtualized environments often support multiple tenants – some of whom may be entirely separate organizations. Suddenly, concrete walls become glass walls.

We don’t yet know the performance overheads of the (forthcoming) Windows patch. We do, however, know that the Linux patch has been shown to impose nearly a 25% overhead on database accesses. This is not surprising given the extensive changes that had to be made to work around the problem. These changes negate many of the performance improvements that have been made in recent years, but they are necessary because without them, every Intel-powered computer is fundamentally insecure.

At the time of writing, three proof-of-concept attacks have been demonstrated. These have been grouped into two categories; Meltdown and Spectre. Meltdown is the issue to be concerned over. Spectre is a more limited attack and far less important, and it’s also difficult to exploit.

So now we have a real headache. Every virtualized environment has to be patched, along with physical devices. Anything running an older Linux kernel where legacy line of business software is installed, is now a potential security vulnerability. In many cases it may be far cheaper to simply migrate these systems to AMD-based servers, which are not vulnerable. This is because AMD processors do check privileges before caching data, although researchers haven't totally shut the door on ARM and AMD processors and note that it's "unclear" whether they are being affected.  

If your organization is still running older versions of Windows, this will be yet another wakeup call to upgrade to Windows 10 as soon as possible. Of course, we don’t yet know what overheads this fix will impose. Along with this, mobile devices may have significantly poorer battery life. Unfortunately there’s no real alternative. The problem is intrinsic to the CPU design and cannot be patched in microcode.

For Intel, this comes after a terrible year where major security flaws with the inbuilt Management Engine component were exposed, culminating in a demonstration at Black Hat Europe where arbitrary code was loaded into the engine and made to persist after device reboot.

Once again this is also a reminder that security through obscurity is no defense. Indeed, it is innately a vulnerability. When Intel made their design decisions they did so internally, with no review by industry security consultants. As has been shown time and time again, this guarantees something will be overlooked.

It’s also interesting that this vulnerability has probably been around for a decade or more. Of course, we can’t know for sure that someone – a nation state, for example – didn’t already know all about this, and possibly even have a weaponized exploit. Indeed – as has happened several times recently – it may be that such an exploit has inadvertently reached the public domain.

Hopefully over the next few days and weeks, we’ll learn more. At present, leading industry commentators, including Linus Torvalds, Alex Ionescu, and Mark Russinovich have been fairly tight-lipped over the issue. This is probably not surprising considering how high the stakes are. But for now this is probably the biggest security flaw discovered for a very long time – and 2018 has only just begun!

Related Content:




Andrew Mayo has been involved in IT, both in software and hardware roles, for enough years to have worked through the tail-end of the punched card and paper tape era, and the subsequent invention of the PC. Currently he's working on the evolution of 1E's Tachyon solution, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
1/8/2018 | 10:26:07 AM
Obscurity is extremely valuable for defense in depth
While otherwise an informative article, the author pillories "security by obscurity" as if there were an explicit decision to base an entire security architecture on concealing a vulnerability.  This is not the case with the Intel microprocessor vulnerabilities and muddies the importance of defense in depth and obstructing the visibility of target points.  Every minute you cost an attacker in finding out the place to attack costs him money and adds to your window for detecting and defeating the attack. 
User Rank: Ninja
1/5/2018 | 3:29:11 PM
What disturbs me is
The sheer length of time it took for this to be known ---- and it has been a design feature for many years now.  Why the silence and, by the same token, since we are all SCREAMING ABOUT IT ---- Are not the hackers doubling down on their exploits NOW before it is at least partly patched???    Methinks we should too much sometimes.
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
PUBLISHED: 2021-01-15
Docker Desktop Community before on macOS mishandles certificate checking, leading to local privilege escalation.
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, the REST UserResource endpoint performs a security check to make sure that only administrators can list user details. However for the `/users/` endpoint there are no security checks enforced so it is possible to retrieve ar...