Uncommon Descent Serving The Intelligent Design Community

Sci-Tech: Meltdown patches patched as a first wave of lawsuits hits Intel over Meltdown and Spectre [u/d, AMD sued over Spectre too]

arroba Email

The Meltdown-Spectre processor architectural flaw crisis we have been monitoring has deepened as Intel has to patch its initial patch:

Daily Mail Update on the patch to the patch

. . . and as a first wave of the inevitable lawsuits hits. Here, we clip one in San Francisco:

Clipping from a Lawsuit against Intel in San Francisco. (DISCLAIMER: UD is only able to vouch for the report of a suit as reported in reasonably credible online media, not the contents thereof.)


NB: Comment 3 below links and clips documentation AMD has been sued over its response to Spectre.

Where also, The Register further reports that there are problems with embedded systems using microprocessors and microcontrollers:

>>Patches for the Meltdown vulnerability are causing stability issues in industrial control systems.

SCADA vendor Wonderware admitted that Redmond’s Meltdown patch made its Historian product wobble. “Microsoft update KB4056896 (or parallel patches for other Operating System) causes instability for Wonderware Historian and the inability to access DA/OI Servers through the SMC,” an advisory on Wonderware’s support site explains.

Rockwell Automation revealed that the same patch had caused issues with Studio 5000, FactoryTalk View SE, and RSLinx Classic (a widely used product in the manufacturing sector). “In fairness [this] may be RPC [Remote Procedure Call] change related,” said cybersecurity vulnerability manager Kevin Beaumont.

El Reg requested clarification from Rockwell but we’re yet to hear back from the vendor.

The expected and well-publicised system slowdown issues from Meltdown and Spectre patches (Reg reports here, here and here) have been accompanied by even more irksome stability problems on some systems. Incompatibility with Microsoft fixes released on January 3 freezes some PCs with AMD chips, as previously reported.

An Ubuntu Linux kernel update prompted by Meltdown caused systems to become unbootable. Patching against CVE-2017-5753, CVE-2017-5715 (Spectre) and CVE-2017-5754 (Meltdown) affected both the PulseSecure VPN client and Sandboxie, the sandbox-based isolation program developed by Sophos.>>

In short, we are clearly in for quite a ride and we are headed towards a new generation of chips with significantly modified architectures, leading to a huge stirring of the industrial pot in the most dynamic sector of the global economy. My guesstimate continues to be two to three years. END

KF, Very interesting situation. Thanks for keeping us updated on this here. Dionisio
PPPS: H'mm, the timing on this suggests some implicit information now:
Avast SafeZone Browser - FAQs Please note: From September 2017, Avast is temporarily pausing the distribution of Avast SafeZone Browser. Our updated browser, which includes a range of new security and privacy tools, will be available for download in the near future. If you already have SafeZone Browser installed on your PC, you will be automatically upgraded to our latest browser as soon as it is released.
PPS: Let us note the Abstract for the Arxiv Spectre paper:
Spectre Attacks: Exploiting Speculative Execution Paul Kocher, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom (Submitted on 3 Jan 2018) Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim's memory and registers, and can perform operations with measurable side effects. [--> inherent info "leaks" per information theory] Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices. While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak. Subjects: Cryptography and Security (cs.CR) Cite as: arXiv:1801.01203 [cs.CR] (or arXiv:1801.01203v1 [cs.CR] for this version)
Uh oh, we credibly have a headache on our hands for years to come. And yes, I am going to be rethinking Browser preferences. Maybe, we are about to face a new market: paid-for, guaranteed high security browsers brought out by anti-malware providers. (I already know of and have used Avast's Safe Zone.) kairosfocus
JB, I agree that you are raising a good part of the matter, and certainly I have long had suspicions on browsers especially as I notice browser bloat and how much memory and CPU workload they now seem to take up -- those suspicions go far beyond Spectre, on the principle that if something is free to you, YOU are the product being sold to someone else. As in, browser ware should be inherently suspect of being spyware [oh, "market research" and "data mining"], as should be search engines and major social media platforms. So, maybe we need to be looking at the browsers of choice we use, given what is emerging about Google, what has come out about Mozilla, and what has long been felt by many about Microsoft. In that context, browser use of scripting languages is indeed a point for concern, most notably Javascript. However, it also seems that for example a key thing is the architecture at work. When timing differences due to using caching to speed up processing [as opposed to going out to main memory] are part of the game for instance, we are getting into a serious bind. From the noted, that then contains a reasonable probability that "If [the data fetched] was read from the cache the access time was very short, and the data read could contain the private key of encryption algorithms." Further, as this is in key part based on MPUs using speculative execution [and thus also introducing the commit phase to the classic fetch-decode-execute processor machine code cycle], which is clearly a CPU speed-up architectural feature, we further compound the speed-security trade-off. The generic nature of the attack then suggests that no single patch is likely to fix it and why it is liable to be a longstanding challenge. Yes, just in time compilation may be a vehicle in, but the problem also seems to involve the speed-up features of processor architectures developed over the past 20 years or so, and growing in importance over the past decade. On this, I note the claimed roots in how in 2002 - 3, Yukiyasu Tsunoo and colleagues from NEC showed how to attack Misty and DES. That's fifteen years back. KF PS: I'd love to hear more on the "sound" -- mechanical vibrations? -- attack. kairosfocus
KF - What I said was precisely what you were pointing out. There may be features that are needed, but it is not the *CPU* that is violating security. In fact, it is literally impossible to remove all potential avenues of side-channel attack. There have been some that have extracted private keys via *sound*. It isn't that Spectre doesn't work, but that the specific *reason* it works is because browsers allow code to execute *in their own address space*. That is not really the CPU's problem. Why should the CPU care about what a program can do with its own address space? Why should the CPU care that information about a program's address space should leak to the program that owns it. Spectre, at least from what I can tell, isn't an attack on the CPU as much as it is an attack on JIT compilation. Because the attacker can predict the JIT compilation, and the JIT doesn't segregate the address space, that allows the attacker access. But, again, this isn't the fault of the CPU. The program responsible for guaranteeing the address space here is the hosting program. The fact that most programs aren't built with this in mind isn't really the CPU manufacturer's problem. johnnyb
F/N: Briefing papers: Meltdown: https://arxiv.org/abs/1801.01207 Spectre: https://arxiv.org/abs/1801.01203 KF kairosfocus
OP updated to reflect the suit against AMD over Spectre. kairosfocus
JB, Before anything else, I just saw AMD has also been sued:
CHIPMAKER AMD has been slapped with a class-action lawsuit over claims that it artificially inflated its stock price by keeping quiet about the fact that the high-profile Spectre flaws affect its chips. A filing to a US court in the northern district of California made by Pomerantz LLP on behalf of shareholder Doyun Kim claims that AMD's initial reaction to the flaw, which saw it declare that Spectre posed "near zero risk" to its chips before admitting that its processors were, in fact, affected by both variants of the vulnerability, resulted in AMD's stock prices plummeting "As a result of defendants' wrongful acts and omissions, and the precipitous decline in the market value of the company's common shares, plaintiff and other class members have suffered significant losses and damages," the filing states. These are strong accusation for flaws which only recently came to light and the scope of their reach and potential to cause damage is arguably still being figured out. But AMD is not alone in facing court filings. Intel is in the same boat, and has already been whacked by multiple class-action lawsuits over both Meltdown and Spectre. Given that both CPU flaws have effectively sat dormant for years, throwing court cases at Intel and AMD may seem a little unfair. That being said, Google's Project Zero team, which was instrumental in uncovering the CPU flaws, had apparently informed AMD about Spectre back in June 2017, so one could argue that the firm should have been more forthcoming about the issue.
I suppose ARM is next and maybe whoever owns the SPARC chip designs now. In an earlier u/d I noted Intel is so far the main target for Meltdown, though apparently no guarantee. They pay a price for especially aggressive use of speculative execution. The dump it problem seems to be when, and apparently that is not easily solved. NYT, Jan 3:
There is no easy fix for Spectre, which could require redesigning the processors, according to researchers. As for Meltdown, the software patch needed to fix the issue could slow down computers by as much as 30 percent — an ugly situation for people used to fast downloads from their favorite online services. “What actually happens with these flaws is different and what you do about them is different,” said Paul Kocher, a researcher who was an integral member of a team of researchers at big tech companies like Google and Rambus and in academia that discovered the flaws. Meltdown is a particular problem for the cloud computing services run by the likes of Amazon, Google and Microsoft. By Wednesday evening, Google and Microsoft said they had updated their systems to deal with the flaw. Continue reading the main story Amazon told customers of its Amazon Web Services cloud service that the vulnerability “has existed for more than 20 years in modern processor architectures.” It said that it had already protected nearly all instances of A.W.S. and that customers must update their own software running atop the service as well. To take advantage of Meltdown, hackers could rent space on a cloud service, just like any other business customer. Once they were on the service, the flaw would allow them to grab information like passwords from other customers . . . . Spectre will be much more difficult to deal with than issuing a software patch. The Meltdown flaw is specific to Intel, but Spectre is a flaw in design that has been used by many processor manufacturers for decades. It affects virtually all microprocessors on the market, including chips made by AMD that share Intel’s design and the many chips based on designs from ARM in Britain. Spectre is a problem in the fundamental way processors are designed, and the threat from Spectre is “going to live with us for decades,” said Mr. Kocher, the president and chief scientist at Cryptography Research, a division of Rambus. “Whereas Meltdown is an urgent crisis, Spectre affects virtually all fast microprocessors,” Mr. Kocher said. An emphasis on speed while designing new chips has left them vulnerable to security issues, he said. “We’ve really screwed up,” Mr. Kocher said. “There’s been this desire from the industry to be as fast as possible and secure at the same time. Spectre shows that you cannot have both” . . . . A fix may not be available for Spectre until a new generation of chips hit the market. “This will be a festering problem over hardware life cycles. It’s not going to change tomorrow or the day after,” Mr. Kocher said. “It’s going to take a while.”
In short there has to be a reason for this degree of concern. Wiki might help as a first quick check:
Spectre is a vulnerability that affects modern microprocessors that perform branch prediction.[1][2][3] On most processors, the speculative execution resulting from a branch misprediction may leave observable side effects that may reveal private data to attackers. For example, if the pattern of memory accesses performed by such speculative execution depends on private data, the resulting state of the data cache constitutes a side channel through which an attacker may be able to extract information about the private data using a timing attack . . . . History In 2002 and 2003 Yukiyasu Tsunoo and colleagues from NEC showed how to attack MISTY and DES respectively. In 2005, Daniel Bernstein from the university of Illinois reported an extraction of an OpenSSL AES key via a cache timing attack, and Colin Percival had a working attack on the OpenSSL RSA key using the Intel processor's cache. 2013 Yuriv Yarom and Katrina Falkner from the University of Adelaide showed how measuring the access time to data lets a spy application guess if the information was read from the cache, or not. If it was read from the cache the access time was very short, and the data read could contain the private key of encryption algorithms. This technique was used to successfully attack GnuPG, AES and other cryptographic implementations[17][18][19][20][21][22] In January 2017, Anders Fogh gave a presentation at the Ruhruniversität Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core. [23]. Spectre was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp and Yuval Yarom.[when?] Microsoft Vulnerability Research extended it to browsers' JavaScript JIT engines.[4][24] It was made public in conjunction with another vulnerability, Meltdown, on January 3, 2018, after the affected hardware vendors had already been made aware of the issue on June 1, 2017.[25] The vulnerability was called "Spectre" because it "is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time."[26] Impact As of 2018, almost every computer system is affected by Spectre, including desktops, laptops, and mobile devices. Specifically, Spectre has been shown to work on Intel, AMD, ARM-based, and IBM processors . . . . Researchers have indicated that the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors.[35][36][37][38] Specifically, processors with speculative execution are affected with these vulnerabilities.[39] . . . . Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.[43] Mitigation Since Spectre represents a whole class of attacks, there most likely cannot be a single patch for it.[3] While work is already being done to address special cases of the vulnerability, the original website devoted to Spectre and Meltdown states: "As [Spectre] is not easy to fix, it will haunt us for a long time."[4] Nonetheless, several procedures to help protect home computers and related devices from the "Meltdown" and "Spectre" security vulnerabilities have been published.[9][10][11][12] Spectre patches have been reported to significantly slow down performance, especially on older computers; on the newer eighth generation Core platforms, benchmark performance drops of 2–14 percent have been measured.[13] On January 18, 2018, unwanted reboots, even for newer Intel chips, due to Meltdown and Spectre patches, were reported.[16] Exploitation through JavaScript embedded in websites is possible.[1] Chrome 64 will include mitigations against the attack by default, and Chrome 63 users can manually mitigate the attack by enabling the Site Isolation feature (chrome://flags#enable-site-per-process).[44] As of Firefox 57.0.4, Mozilla is reducing the resolution of JavaScript timers to help prevent timing attacks, with additional work on time-fuzzing techniques planned for future releases.[24][45] On January 4, 2018, Google detailed a new technique on their security blog called "Retpoline" (return trampoline)[46] which can overcome the Spectre vulnerability with a negligible amount of processor overhead. It involves compiler level steering of indirect branches towards a different target that does not result in a vulnerable speculative out-of-order execution taking place.[47][48] While it was developed for the x86 instruction set, the Google engineers believe the technique is transferable to other processors as well.
looks like there is a problematique here and we are looking at a new architecture generation. Thoughts? KF kairosfocus
Just to point out, Meltdown only affects Intel CPUs. Therefore, they do not really necessitate reworking of general CPU architecture. In fact, I can see AMD coming out of this as a champion. Spectre, I think, even though it is based on the same idea (utilizing branch prediction), as far as I can tell, it is not technically a problem with the CPU. It is actually a problem with the JavaScript implementation. As far as the CPU is concerned, the JavaScript executes at the same security level as the browser. Therefore, the ability for the JavaScript to read the rest of the browser's address space is not actually an issue with the CPU itself. It's an issue with the JavaScript implementation. It may be that there are features that would be helpful in the CPU for such execution isolation, but I don't think it is really a flaw, as it is not considered a guarantee of the CPU to prevent a program from accessing its own address space. It is a flaw in the browser for not sufficiently policing programs that run with its own permissions. Additionally, I'm not sure about this, but I think the specific flaw can be solved by simply issuing a cache flush after any failed bounds check. johnnyb
Sci-Tech: Meltdown patches patched as a first wave of lawsuits hits Intel over Meltdown and Spectre kairosfocus

Leave a Reply