Applications, operating systems, and firmware all need to be updated to defeat Meltdown and protect against Spectre, two attacks that exploit features of high-performance processors to leak information and undermine system security. The computing industry has been scrambling to respond after news of the problem broke early a few days into the new year.
But that patching is proving problematic. The Meltdown protection is revealing bugs or otherwise undesirable behavior in various drivers, and Intel is currently recommending that people cease installing a microcode update it issued to help tackle the Spectre problem. This comes as researchers are digging into the papers describing the issues and getting closer to weaponizing the research to turn it into a practical attack. With the bad guys sure to be doing the same, real-world attacks using this research are sure to follow soon.
Back when initially releasing its Windows patch, Microsoft acknowledged incompatibilities with some anti-virus software. To receive the Meltdown and Spectre fixes, anti-virus software on Windows is required to create a special registry entry indicating that it’s compatible. Without this entry, not only are these patches blocked, but so too are all future Windows patches. Most anti-virus vendors should now have compatible versions of their products, but users with stale anti-virus software—expired trials or end-of-lifed products—are at this point much better off removing the third-party software entirely and using the built-in protection in Windows 8.1 and Windows 10.
As the industry continues to grapple with the Meltdown and Spectre attacks, operating system and browser developers in particular are continuing to develop and test schemes to protect against the problems. Simultaneously, microcode updates to alter processor behavior are also starting to ship.
Since news of these attacks first broke, it has been clear that resolving them is going to have some performance impact. Meltdown was presumed to have a substantial impact, at least for some workloads, but Spectre was more of an unknown due to its greater complexity. With patches and microcode now available (at least for some systems), that impact is now starting to become clearer. The situation is, as we should expect with these twin attacks, complex.
To recap: modern high-performance processors perform what is called speculative execution. They will make assumptions about which way branches in the code are taken and speculatively compute results accordingly. If they guess correctly, they win some extra performance; if they guess wrong, they throw away their speculatively calculated results. This is meant to be transparent to programs, but it turns out that this speculation slightly changes the state of the processor. These small changes can be measured, disclosing information about the data and instructions that were used speculatively.
Since its inception, Skype has been notable for its secretive, proprietary algorithm. It’s also long had a complicated relationship with encryption: encryption is used by the Skype protocol, but the service has never been clear exactly how that encryption was implemented or exactly which privacy and security features it offers.
That changes today in a big way. The newest Skype preview now supports the Signal protocol: the end-to-end encrypted protocol already used by WhatsApp, Facebook Messenger, Google Allo, and, of course, Signal. Skype Private Conversations will support text, audio calls, and file transfers, with end-to-end encryption that Microsoft, Signal, and, it’s believed, law enforcement agencies cannot eavesdrop on.
Presently, Private Conversations are only available in the Insider builds of Skype. Naturally, the Universal Windows Platform version of the app—the preferred version on Windows 10—isn’t yet supported. In contrast, the desktop version of the app, along with the iOS, Android, Linux, and macOS clients, all have compatible Insider builds. Private Conversations aren’t the default and don’t appear to yet support video calling. The latter limitation shouldn’t be insurmountable (Signal’s own app offers secure video calling). We hope to see the former change once updated clients are stable and widely deployed.
Withdrawing or suspending delivery of Windows Updates is not uncommon; while there is some testing done by Microsoft, releasing things to a wider audience does from time to time unearth incompatibilities or bugs within the update. What is uncommon is that Microsoft is not merely suspending this update; the company has also outlined why. Specifically, Microsoft writes that:
After investigating, Microsoft has determined that some AMD chipsets do not conform to the documentation previously provided to Microsoft to develop the Windows operating system mitigations to protect against the chipset vulnerabilities known as Spectre and Meltdown.
The Meltdown and Spectre flaws—two related vulnerabilities that enable a wide range of information disclosure from every mainstream processor, with particularly severe flaws for Intel and some ARM chips—were originally revealed privately to chip companies, operating system developers, and cloud computing providers. That private disclosure was scheduled to become public some time next week, enabling these companies to develop (and, in the case of the cloud companies, deploy) suitable patches, workarounds, and mitigations.
Windows, Linux, and macOS have all received security patches that significantly alter how the operating systems handle virtual memory in order to protect against a hitherto undisclosed flaw. This is more than a little notable; it’s been clear that Microsoft and the Linux kernel developers have been informed of some non-public security issue and have been rushing to fix it. But nobody knew quite what the problem was, leading to lots of speculation and experimentation based on pre-releases of the patches.
Now we know what the flaw is. And it’s not great news, because there are in fact two related families of flaws with similar impact, and only one of them has any easy fix.
The flaws have been named Meltdown and Spectre. Meltdown was independently discovered by three groups—researchers from the Technical University of Graz in Austria, German security firm Cerberus Security, and Google’s Project Zero. Spectre was discovered independently by Project Zero and independent researcher Paul Kocher.
At their heart, both attacks takes advantage of the fact that processors execute instructions speculatively. All modern processors perform speculative execution to a greater or lesser extent; they’ll assume that, for example, a given condition will be true and execute instructions accordingly. If it later turns out that the condition was false, the speculatively executed instructions are discarded as if they had no effect.
However, while the discarded effects of this speculative execution don’t alter the outcome of a program, they do make changes to the lowest level architectural features of the processors. For example, speculative execution can load data into cache even if it turns out that the data should never have been loaded in the first place. The presence of the data in the cache can then be detected, because accessing it will be a little bit quicker than if it weren’t cached. Other data structures in the processor, such as the branch predictor, can also be probed and have their performance measured, which can similarly be used to reveal sensitive information.
The first problem, Meltdown, is the one that stimulated the flurry of operating system patches. It uses speculative execution to leak kernel data to regular user programs.
Our original coverage gave a high-level summary of how operating systems virtualize system memory, the use of page tables to map from virtual memory addresses to physical addresses, how processors cache those mappings, and how the kernel’s page table mapping is shared between processes in order to maximize the value of this special cache.
While all modern processors, including those from Intel, AMD, and ARM, perform speculation around memory accesses, Intel’s processors do so in a particularly aggressive way. Operating system memory has associated metadata that determines whether it can be accessed from user programs, or is restricted to access from the kernel (again: our original coverage has more detail about this point). Intel chips allow user programs to speculatively use kernel data and the access check (to see if the kernel memory is accessible to a user program) happens some time after the instruction starts executing. The speculative execution is properly blocked, but the impact that speculation has on the processor’s cache can be measured. With careful timing, this can be used to infer the values stored in kernel memory.
The researchers say they haven’t been able to perform the same kind of kernel memory-based speculation on AMD or ARM processors, though they hold out some hope that some way of using this speculation offensively will be developed. While AMD has stated specifically that its chips don’t speculate around kernel addresses in this way, ARM has said that some of its designs may be vulnerable, and ARM employees have contributed patches to Linux to protect against Meltdown.
For systems with Intel chips, the impact is quite severe, as potentially any kernel memory can be read by user programs. It’s this attack that the operating system patches are designed to fix. It works by removing the shared kernel mapping, an operating system design that has been a mainstay since the early 1990s due to the efficiency it provides. Without that shared mapping, there’s no way for user programs to provoke the speculative reads of kernel memory, and hence no way to leak kernel information. But it comes at a cost: it makes every single call into the kernel a bit slower, because each switch to the kernel now requires the kernel page to be reloaded.
The impact of this change will vary wildly depending on workload. Applications that are heavily dependent on user programs and which don’t call into the kernel often will see very little impact; games, for example, should see very little change. But applications that call into the operating system extensively, typically to perform disk or network operations, can see a much more substantial impact. In synthetic benchmarks that do nothing but make kernel calls, the difference can be substantial, dropping from five million kernel calls per second to two-to-three million.
Owners of AMD and ARM systems shouldn’t rest easy, though, and that’s thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.
Moreover, Spectre doesn’t offer any straightforward solution. Speculation is essential to high performance processors, and while there may be limited ways to block certain certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren’t known.
Sensitive pieces of code could be amended to include “serializing instructions”—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.
In the immediate term, it looks like most systems will shortly have patches for Meltdown. At least for Linux and Windows, these patches allow end-users to opt out if they would prefer. The most vulnerable users are probably cloud service providers; Meltdown and Spectre can both in principle be used to further attacks against hypervisors, making it easier for malicious user to break out of their virtual machines.
For typical desktop users, the risk is arguably less significant. While both Meltdown and Spectre can have value in expanding the scope of an existing flaw, neither one is sufficient on its own to, for example, break out of a Web browser.
Longer term, we’d expect a future Intel architecture to offer some kind of a fix, either by avoiding speculation around this kind of problematic memory access, or making the memory access permission checks faster so that this time interval between reading kernel memory, and checking that the process has permission to read kernel memory, is eliminated.
As of Thursday morning local time, a San Francisco animal adoption agency will immediately halt its recent use of a controversial security robot.
The moves comes after the San Francisco SPCA had been scrutinized for its deployment of a Knightscope K9 to mitigate vandalism and the presence of homeless people at its Mission District office. Knightscope, a Silicon Valley startup, touts the robots on its own website as the "security team of the future."
To further increase its enterprise appeal, Chrome 63—which hit the browser’s stable release channel yesterday—includes a couple of new security enhancements aimed particularly at the corporate market.
The first of these is site isolation, an even stricter version of the multiple process model that Chrome has used since its introduction. Chrome uses multiple processes for several security and stability reasons. On the stability front, the model means that even if a single tab crashes, other tabs (and the browser itself) are unaffected. On the security front, the use of multiple processes makes it much harder for malicious code from one site to steal secrets (such as passwords typed into forms) of another.
When a company like Microsoft needs to fix a security flaw in one of its products, the process is normally straightforward: determine where the bug lies, change the program’s source code to fix the bug, and then recompile the program. But it looks like the company had to step outside this typical process for one of the flaws it patched this Tuesday. Instead of fixing the source code, it appears that the company’s developers made a series of careful changes directly to the buggy program’s executable file.
Bug CVE-2017-11882 is a buffer overflow in the ancient Equation Editor that comes with Office. The Equation Editor allocates a fixed-size piece of memory to hold a font name and then copies the font name from the equation file into this piece of memory. It doesn’t, however, check to ensure that the font name will fit into this piece of memory. When provided with a font name that’s too long, the Equation Editor overflows the buffer, corrupting its own memory, and an attacker can use this to execute arbitrary malicious code.
Normally the work to fix this would be to determine the length of the font name and create a buffer that’s big enough to hold it. It’s a simple enough change to make in source code. If that’s not possible—there are occasional situations where a buffer can’t easily be made bigger—then the next best solution is to limit the amount of data copied to it, truncating the font name if it’s too long to fit. Again, this is a simple change to make in the source code.
But that doesn’t appear to be what Microsoft did here.
Analysis of Microsoft’s patch strongly indicates that the company didn’t make changes to the source code at all. Instead, it appears that the flaw has been fixed by very carefully modifying the Equation Editor executable itself. Normally when a program is modified and recompiled, there are ripple effects from this compilation. Low-level aspects of the compiled code will change slightly; the recompiled code will use registers slightly differently, functions will be placed at different locations in memory, and so on. But none of that is in evidence here; side-by-side comparison of the fixed program and the original version shows that it’s almost entirely unaltered except for a few bytes in a few functions. The only way that’s likely to happen is if the bug-fixing was performed directly on the program binary itself without reference to the source code.
This is a difficult task to pull off. The fixed version includes an extra test to make sure the font name is not too long, truncating it if it is. Doing this extra test means adding extra instructions to the buggy function, but Microsoft needed to make the fix without making the function any longer to ensure that other, adjacent functions were not disturbed. To make space for the new length checking, the part of the program that copied the font name was ever so slightly deoptimized, replacing a faster routine with a slightly slower one, and freeing up a few bytes in the process.
The inspection even suggests that this isn’t the first time that Microsoft has had to make such fixes; a few instructions were found to be strangely duplicated in the original, broken version of the program. This kind of thing would happen if a previous modification made the program’s code slightly shorter.
A look at the Equation Editor’s embedded version information also gives clues as to why Microsoft had to take this approach in the first place. It’s a third-party tool, developed between 1990 and 2000 by a company named Design Science. That company still exists and is still producing equation editing software, but if we were to guess, Microsoft either doesn’t have the source code at all or does not have permission to make fixes to it.
Word nowadays has its own built-in equation editing, but Equation Editor is still supported for backwards compatibility to ensure that old documents with embedded equations continue to be usable. Still, we’re a little surprised that Microsoft fixed it rather than removing it entirely. It’s truly a relic from another era, coming long before Microsoft’s considerable investment in safe coding practices and exploit mitigation techniques. Equation Editor lacks all of the protections found in Microsoft’s recent code, making its flaws much easier to exploit than those of, say, Word or Windows. This makes it something of a security liability, and we’d be amazed if this font bug is the last one to be found.
Mozilla is working on a major overhaul of its Firefox browser, and, with the general release of Firefox 57 today, has reached a major milestone. The version of the browser coming out today has a sleek new interface and, under the hood, major performance enhancements, with Mozilla claiming that it’s as much as twice as fast as it was a year ago. Not only should it be faster to load and render pages, but its user interface should remain quick and responsive even under heavy load with hundreds of tabs.