from the so-that-means...-we-are-screwed dept.
Google security researchers have come to the conclusion that speculative execution attacks are here to stay without drastic changes to modern CPU architectures, such as removing speculative execution entirely.
Patch for Intel Speculative Execution Vulnerability Could Reduce Performance by 5 to 35% [Update: 2]
Qualcomm Joins Others in Confirming its CPUs Suffer From Spectre, and Other Meltdown News
Congress Questions Chipmakers About Meltdown and Spectre
What Impact Has Meltdown/Spectre Had on YOUR Systems?
Intel Admits a Load of its CPUs Have Spectre V2 Flaw That Can't be Fixed
Intel FPU Speculation Vulnerability Confirmed
New Spectre Variant SpectreRSB Targets Return Stack Buffer
Intel Discloses a Speculative Execution Attack in Software Guard eXtensions (SGX)
Intel 'Gags' Linux Distros From Revealing Performance Hit From Spectre Patches
MIT Researchers Claim to Have a Solution for Some Speculative Execution Attacks
Spectre, Meltdown Researchers Unveil 7 More Speculative Execution Attacks
New Side-Channel Leak: Researchers Attack Operating System Page Caches
UPDATE 2: (martyb)
This still-developing story is full of twists and turns. It seems that Intel chips are definitely implicated (AFAICT anything post Pentium Pro). There have been various reports, and denials, that AMD and ARM are also affected. There are actually two vulnerabilities being addressed. Reports are that a local user can access arbitrary kernel memory and that, separately, a process in a VM can access contents of other virtual machines on a host system. These discoveries were embargoed for release until January 9th, but were pre-empted when The Register first leaked news of the issues.
At this time, manufacturers are scrambling to make statements on their products' susceptibility. Expect a slew of releases of urgent security fixes for a variety of OSs, as well as mandatory reboots of VMs on cloud services such as Azure and AWS. Implications are that there is going to be a performance hit on most systems, which may have cascading follow-on effects for performance-dependent activities like DB servers.
To get started, see the very readable and clearly-written article at Ars Technica: What’s behind the Intel design flaw forcing numerous patches?.
Google Security Blog: Today's CPU vulnerability: what you need to know.
Google Project Zero: Reading privileged memory with a side-channel, which goes into detail as to what problems are being addressed as well as including CVEs:
Arthur T Knackerbracket has found the following story:
Qualcomm has confirmed its processors have the same security vulnerabilities disclosed this week in Intel, Arm and AMD CPU cores this week.
The California tech giant picked the favored Friday US West Coast afternoon "news dump" slot to admit at least some of its billions of Arm-compatible Snapdragon system-on-chips and newly released Centriq server-grade processors are subject to the Meltdown and/or Spectre data-theft bugs.
[...] Qualcomm declined to comment further on precisely which of the three CVE-listed vulnerabilities its chips were subject to, or give any details on which of its CPU models may be vulnerable. The paper describing the Spectre data-snooping attacks mentions that Qualcomm's CPUs are affected, while the Meltdown paper doesn't conclude either way.
[...] Apple, which too bases its iOS A-series processors on Arm's instruction set, said earlier this week that its mobile CPUs were vulnerable to Spectre and Meltdown – patches are available or incoming for iOS. The iGiant's Intel-based Macs also need the latest macOS, version 10.13.2 or greater, to kill off Meltdown attacks.
Vox Media website theverge.com reports that Rep. Jerry McNerney (D-CA) wants answers about the recent computer chip chaos.
Congress is starting to ask hard questions about the fallout from the Meltdown and Spectre vulnerabilities. Today, Rep. Jerry McNerney (D-CA) sent a letter [(pdf)] requesting a briefing from Intel, AMD, and ARM about the vulnerabilities’ impact on consumers.
[...] The two vulnerabilities are “glaring warning signs that we must take cybersecurity more seriously,” McNerney argues in the letter. “Should the vulnerabilities be exploited, the effects on consumers’ privacy and our nation’s economy and security would be absolutely devastating.”
Privately disclosed to chipmakers in June of 2016, the Meltdown and Spectre bugs became public after a haphazard series of leaks earlier this month. In the aftermath, there have been significant patching problems, including an AMD patch that briefly prevented Windows computers from booting up. Intel in particular has come under fire for inconsistent statements about the impact of the bugs, and currently faces a string of proposed class-action lawsuits relating to the bugs.
Meltdown can be fixed through a relatively straightforward operating-system level patch, but Spectre has proven more difficult, and there have been significant patching problems in the aftermath. The most promising news has been Google’s Retpoline approach, which the company says can protect against the trickiest Spectre variant with little negative performance impact.
The letter calls on the CEOs of Intel, AMD, and ARM to answer (among other things) when they learned about these problems and what they are doing about it.
SoylentNews first reported the vulnerabilities on January 3. Since then, we have had a few stories addressing different reports about these vulnerabilities. Now that it is over two weeks later and we are *still* dealing with reboots, I am curious as to what our community's experience has been.
What steps have you taken, if any, to deal with these reports? Be utterly proactive and install every next thing that comes along? Do a constrained roll out to test a system or two before pushing out to other systems? Wait for the dust to settle before taking any steps?
What providers (system/os/motherboard/chip) have been especially helpful... or non-helpful? How has their response affected your view of that company?
What resources have you been using to check on the status of fixes for your systems? Have you found a site that stands above the others in timeliness and accuracy?
How has this affected your purchasing plans... and your expectations on what you could get for selling your old system? Are you now holding off on purchasing something new?
It seems Intel has had some second thoughts about Spectre 2 microcode fixes:
Intel has issued new a new "microcode revision guidance" that confesses it won't address the Meltdown and Spectre design flaws in all of its vulnerable processors – in some cases because it's too tricky to remove the Spectre v2 class of vulnerabilities.
The new guidance (pdf), issued April 2, adds a "stopped" status to Intel's "production status" category in its array of available Meltdown and Spectre security updates. "Stopped" indicates there will be no microcode patch to kill off Meltdown and Spectre.
The guidance explains that a chipset earns "stopped" status because, "after a comprehensive investigation of the microarchitectures and microcode capabilities for these products, Intel has determined to not release microcode updates for these products for one or more reasons."
Those reasons are given as:
- Micro-architectural characteristics that preclude a practical implementation of features mitigating [Spectre] Variant 2 (CVE-2017-5715)
- Limited Commercially Available System Software support
- Based on customer inputs, most of these products are implemented as "closed systems" and therefore are expected to have a lower likelihood of exposure to these vulnerabilities.
Thus, if a chip family falls under one of those categories – such as Intel can't easily fix Spectre v2 in the design, or customers don't think the hardware will be exploited – it gets a "stopped" sticker. To leverage the vulnerabilities, malware needs to be running on a system, so if the computer is totally closed off from the outside world, administrators may feel it's not worth the hassle applying messy microcode, operating system, or application updates.
"Stopped" CPUs that won't therefore get a fix are in the Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, and Yorkfield Xeon families. The list includes various Xeons, Core CPUs, Pentiums, Celerons, and Atoms – just about everything Intel makes.
Most [of] the CPUs listed above are oldies that went on sale between 2007 and 2011, so it is likely few remain in normal use.
The Intel® FPU speculation vulnerability has been confirmed. Theo guessed right last week.
Using information disclosed in Theo's talk, Colin Percival developed a proof-of-concept exploit in around 5 hours. This seems to have prompted an early end to an embargo (in which OpenBSD was not involved), and the official announcement of the vulnerability.
An update to the article appearing in The Register adds:
A security flaw within Intel Core and Xeon processors can be potentially exploited to swipe sensitive data from the chips' math processing units.
Malware or malicious logged-in users can attempt to leverage this design blunder to steal the inputs and results of computations performed in private by other software.
These numbers, held in FPU registers, could potentially be used to discern parts of cryptographic keys being used to secure data in the system. For example, Intel's AES encryption and decryption instructions use FPU registers to hold keys.
In short, the security hole could be used to extract or guess at secret encryption keys within other programs, in certain circumstances, according to people familiar with the engineering mishap.
Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenBSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665).
Windows Server 2008 is among the operating systems that will need to be patched, we understand, and fixes for affected Microsoft and non-Microsoft kernels are on their way. The Linux kernel team is back-porting mitigations to pre-4.9 kernels.
Essentially, hold tight, and wait for patches to land for your Intel-powered machines, if they are vulnerable. CVE-2018-3665 isn't the end of the world: malicious software has to be already running on your system to attempt to exploit it, and even then, it can only lift out crumbs at a time.
[...] Red Hat has more technical details, here. RHEL 5, 6, and 7, and Enterprise MRG 2 not running kernel-alt are vulnerable. In a statement to The Register, the Linux vendor clarified that this a potential task-to-task theft of information:
[A] new Spectre-class exploit, dubbed SpectreRSB, was detailed by researchers from the University of California at Riverside in a research paper [PDF] on Friday. While the flaw still targets the process of speculative execution, unlike other variants, it manipulates a new part of the process called the return stack buffer.
[...] RSB is a common "predictor structure" in CPUs used to predict return addresses during the speculative execution process. It does so by pushing the return address from a call instruction on an internal hardware stack [...]
Since the disclosure of Spectre in January, various variants have consequently been disclosed by researchers – however, these have all targeted the branch predictor unit or cache within the CPU.
[...] Researchers said they have reported SpectreRSB to Intel, AMD and ARM [...]
The Register (CloudFlare-protected) also has an article about SpectreRSB.
A Last-In-First-Out buffer, called the return stack buffer, remembers the return address every time a call instruction is executed, and it uses this for predicting where the corresponding return will go. This mechanism makes sure that return instructions are correctly predicted when the same subroutine is called from several different locations. The P1 has no return stack buffer, but uses the same method for returns as for indirect jumps. Later processors have a return stack buffer. [...]
Another day, another speculative execution-based attack. Data protected by Intel's SGX—data that's meant to be protected even from a malicious or hacked kernel—can be read by an attacker thanks to leaks enabled by speculative execution.
Since publication of the Spectre and Meltdown attacks in January this year, security researchers have been taking a close look at speculative execution and the implications it has for security. All high-speed processors today perform speculative execution: they assume certain things (a register will contain a particular value, a branch will go a particular way) and perform calculations on the basis of those assumptions. It's an important design feature of these chips that's essential to their performance, and it has been for 20 years.
Open-source champion Bruce Perens has called out Intel for adding a new restriction to its software license agreement along with its latest CPU security patches to prevent developers from publishing software benchmark results.
The new clause appears to be a move by Intel to legally gag developers from revealing performance degradation caused by its mitigations for Spectre and Foreshadow or 'L1 Terminal Fault' (L1FT) flaw speculative attacks.
"You will not, and will not allow any third party to ... publish or provide any software benchmark or comparison test results," Intel's new agreement states .
[...] Another section of the license blocking redistribution appears to have caused maintainers of Debian to withhold Intel's patch too , as reported by The Register.
[...] Updated 12:15pm ET, August 23 2018: An Intel spokesperson responded: "We are updating the license now to address this and will have a new version available soon. As an active member of the open-source community, we continue to welcome all feedback."
The researchers call their solution Dynamically Allocated Way Guard (DAWG) and revealed it in a recent paper. This name stands in opposition to Intel's Cache Allocation Technology (CAT) and is said to prevent attackers from accessing ostensibly secure information through exploiting flaws in the speculative execution process. Best of all, DAWG is said to require very few resources that CAT isn't already using and can be enabled with operating system changes instead of requiring the in-silicon fixes many thought were needed to address the flaws.
[...] Here's how the researchers summarized their approach with DAWG:
"Unlike existing mechanisms such as CAT, DAWG disallows hits across protection domains. This affects hit paths and cache coherence, and DAWG handles these issues with minimal modification to modern operating systems, while reducing the attack surface of operating systems to a small set of annotated sections where data moves across protection domains, or where domains are resized/reallocated. Only in these handful of routines, DAWG protection is relaxed, and other defensive mechanisms such as speculation fences are applied as needed."
Back at the start of the year, a set of attacks that leveraged the speculative execution capabilities of modern high-performance processors was revealed. The attacks were named Meltdown and Spectre. Since then, numerous variants of these attacks have been devised. In tandem, a range of mitigation techniques has been created to enable at-risk software, operating systems, and hypervisor platforms to protect against these attacks.
A research team—including many of the original researchers behind Meltdown, Spectre, and the related Foreshadow and BranchScope attacks—has published a new paper disclosing yet more attacks in the Spectre and Meltdown families. The result? Seven new possible attacks. Some are mitigated by known mitigation techniques, but others are not. That means further work is required to safeguard vulnerable systems.
The previous investigations into these attacks have been a little ad hoc in nature: examining particular features of interest to provide, for example, a Spectre attack that can be performed remotely over a network or Meltdown-esque attack to break into SGX enclaves. The new research is more systematic, looking at the underlying mechanisms behind both Meltdown and Spectre and running through all the different ways the speculative execution can be misdirected.
Some of the computer security boffins who revealed last year's data-leaking speculative-execution holes have identified yet another side-channel attack that can bypass security protections in modern systems.
While side channel attacks like Spectre and Meltdown exploited chip design flaws to glean privileged information, this one is hardware agnostic, involves the Windows and Linux operating system page cache, and can be exploited remotely, within limits.
In a paper provided to The Register in advance of distribution early next week through ArXiv, researchers from Graz University of Technology, Boston University, NetApp, CrowdStrike, and Intel – Daniel Gruss, Erik Kraft, Trishita Tiwari, Michael Schwarz, Ari Trachtenberg, Jason Hennessey, Alex Ionescu, and Anders Fogh – describe a way to monitor how certain processes access memory through the operating system page cache.
"We present a set of local attacks that work entirely without any timers, utilizing operating system calls (mincore on Linux and QueryWorkingSetEx on Windows) to elicit page cache information," wrote the researchers. "We also show that page cache metadata can leak to a remote attacker over a network channel, producing a stealthy covert channel between a malicious local sender process and an external attacker."