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.

Attacks/Breaches

1/5/2018
02:00 PM
Andrew Mayo
Andrew Mayo
Commentary
50%
50%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
SchemaCzar
50%
50%
SchemaCzar,
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. 
REISEN1955
50%
50%
REISEN1955,
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.
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-5285
PUBLISHED: 2019-11-15
Null pointer dereference vulnerability exists in K11_SignWithSymKey / ssl3_ComputeRecordMACConstantTime in NSS before 3.26, which causes the TLS/SSL server using NSS to crash.
CVE-2009-5047
PUBLISHED: 2019-11-15
Jetty 6.x before 6.1.22 suffers from an escape sequence injection vulnerability from two different vectors: 1) "Cookie Dump Servlet" and 2) Http Content-Length header. 1) A POST request to the form at "/test/cookie/" with the "Age" parameter set to a string throws a &qu...
CVE-2013-4584
PUBLISHED: 2019-11-15
Perdition before 2.2 may have weak security when handling outbound connections, caused by an error in the STARTTLS IMAP and POP server. ssl_outgoing_ciphers not being applied to STARTTLS connections
CVE-2013-7087
PUBLISHED: 2019-11-15
ClamAV before 0.97.7 has WWPack corrupt heap memory
CVE-2013-7088
PUBLISHED: 2019-11-15
ClamAV before 0.97.7 has buffer overflow in the libclamav component