It’s been at least a month or two since the last vulnerability in Intel CPUs was released, but this time it’s serious. Foreshadow is the latest speculative execution attack that allows balaclava-wearing hackers to steal your sensitive information. You know it’s a real 0-day because it already has a domain, a logo, and this time, there’s a video explaining in simple terms anyone can understand why the sky is falling. The video uses ukuleles in the sound track, meaning it’s very well produced.
The Foreshadow attack relies on Intel’s Software Guard Extension (SGX) instructions that allow user code to allocate private regions of memory. These private regions of memory, or enclaves, were designed for VMs and DRM.
How Foreshadow Works
The Foreshadow attack utilizes speculative execution, a feature of modern CPUs most recently in the news thanks to the Meltdown and Spectre vulnerabilities. The Foreshadow attack reads the contents of memory protected by SGX, allowing an attacker to copy and read back private keys and other personal information. There is a second Foreshadow attack, called Foreshadow-NG, that is capable of reading anything inside a CPU’s L1 cache (effectively anything in memory with a little bit of work), and might also be used to read information stored in other virtual machines running on a third-party cloud. In the worst case scenario, running your own code on an AWS or Azure box could expose data that isn’t yours on the same AWS or Azure box. Additionally, countermeasures to Meltdown and Spectre attacks might be insufficient to protect from Foreshadown-NG
The researchers behind the Foreshadow attacks have talked with Intel, and the manufacturer has confirmed Foreshadow affects all SGX-enabled Skylake and Kaby Lake Core processors. Atom processors with SGX support remain unaffected. For the Foreshadow-NG attack, many more processors are affected, including second through eighth generation Core processors, and most Xeons. This is a significant percentage of all Intel CPUs currently deployed. Intel has released a security advisory detailing all the affected CPUs.
Hacker uses pineapple on unencrypted WiFi. The results are shocking! Film at 11.
Right on, we’ve got some 3D printing cons coming up. The first is MRRF, the Midwest RepRap Festival. It’s in Goshen, Indiana, March 23-25th. It’s a hoot. Just check out all the coverage we’ve done from MRRF over the years. Go to MRRF.
We got news this was going to happen last year, and now we finally have dates and a location. The East Coast RepRap Fest is happening June 22-24th in Bel Air, Maryland. What’s the East Coast RepRap Fest? Nobody knows; this is the first time it’s happening, and it’s not being produced by SeeMeCNC, the guys behind MRRF. There’s going to be a 3D printed Pinewood Derby, though, so that’s cool.
జ్ఞా. What the hell, Apple?
Defcon’s going to China. The CFP is open, and we have dates: May 11-13th in Beijing. Among the things that may be said: “Hello Chinese customs official. What is the purpose for my visit? Why, I’m here for a hacker convention. I’m a hacker.”
Intel hit with lawsuits over security flaws. Reuters reports Intel shareholders and customers had filed 32 class action lawsuits against the company because of Spectre and Meltdown bugs. Are we surprised by this? No, but here’s what’s interesting: the patches for Spectre and Meltdown cause a noticeable and quantifiable slowdown on systems. Electricity costs money, and companies (server farms, etc) can therefore put a precise dollar amount on what the Spectre and Meltdown patches cost them. Two of the lawsuits allege Intel and its officers violated securities laws by making statements or products that were false. There’s also the issue of Intel CEO Brian Krzanich selling shares after he knew about Meltdown, but before the details were made public. Luckily for Krzanich, the rule of law does not apply to the wealthy.
What does the Apollo Guidance Computer look like? If you think it has a bunch of glowey numbers and buttons, you’re wrong; that’s the DSKY — the user I/O device. The real AGC is basically just two 19″ racks. Still, the DSKY is very cool and a while back, we posted something about a DIY DSKY. Sure, it’s just 7-segment LEDs, but whatever. Now this project is a Kickstarter campaign. Seventy bucks gives you the STLs for the 3D printed parts, BOM, and a PCB. $250 is the base for the barebones kit.
Intel just moved some high level people around to form a dedicated security group.
When news of Meltdown and Spectre broke, Intel’s public relations department applied maximum power to their damage control press release generators. The initial message was one of defiance, downplaying the impact and implying people are over reacting. This did not go over well. Since then, we’ve started seeing a trickle of information from engineering and even direct microcode updates for people who dare to live on the bleeding edge.
All the technical work to put out the immediate fire is great, but for the sake of Intel’s future they need to figure out how to avoid future fires. The leadership needs to change the company culture away from an attitude where speed is valued over all else. Will the new security group have the necessary impact? We won’t know for quite some time. For now, it is encouraging to see work underway. Fundamental problems in corporate culture require a methodical fix and not a hack.
Editor’s note: We’ve changed the title of this article to better reflect its content: that Intel is making changes to its corporate structure to allow a larger voice for security in the inevitable security versus velocity tradeoff.
The year so far has been filled with news of Spectre and Meltdown. These exploits take advantage of features like speculative execution, and memory access timing. What they have in common is the fact that all modern processors use cache to access memory faster. We’ve all heard of cache, but what exactly is it, and how does it allow our computers to run faster?
In the simplest terms, cache is a fast memory. Computers have two storage systems: primary storage (RAM) and secondary storage (Hard Disk, SSD). From the processor’s point of view, loading data or instructions from RAM is slow — the CPU has to wait and do nothing for 100 cycles or more while the data is loaded. Loading from disk is even slower; millions of cycles are wasted. Cache is a small amount of very fast memory which is used to hold commonly accessed data and instructions. This means the processor only has to wait for the cache to be loaded once. After that, the data is accessible with no waiting.
A common (though aging) analogy for cache uses books to represent data: If you needed a specific book to look up an important piece of information, you would first check the books on your desk (cache memory). If your book isn’t there, you’d then go to the books on your shelves (RAM). If that search turned up empty, you’d head over to the local library (Hard Drive) and check out the book. Once back home, you would keep the book on your desk for quick reference — not immediately return it to the library shelves. This is how cache reading works.
Continue reading “Spectre and Meltdown: How Cache Works”
If you’ve read about Meltdown, you might have thought, “how likely is that to actually happen?” You can more easily judge for yourself by looking at the code available on GitHub. The Linux software is just proof of concept, but it both shows what could happen and — in a way — illustrates some of the difficulties in making this work. There are also two videos in the repository that show spying on password input and dumping physical memory.
The interesting thing is that there are a lot of things that will stop the demos from working. For example a slow CPU, a CPU without out-of-order execution, or an imprecise high-resolution timer. This is apparently especially problematic in virtual machines.
Continue reading “Meltdown Code Proves Concept”
While the whole industry is scrambling on Spectre, Meltdown focused most of the spotlight on Intel and there is no shortage of outrage in Internet comments. Like many great discoveries, this one is obvious with the power of hindsight. So much so that the spectrum of reactions have spanned an extreme range. From “It’s so obvious, Intel engineers must be idiots” to “It’s so obvious, Intel engineers must have known! They kept it from us in a conspiracy with the NSA!”
We won’t try to sway those who choose to believe in a conspiracy that’s simultaneously secret and obvious to everyone. However, as evidence of non-obviousness, some very smart people got remarkably close to the Meltdown effect last summer, without getting it all the way. [Trammel Hudson] did some digging and found a paper from the early 1990s (PDF) that warns of the dangers of fetching info into the cache that might cross priviledge boundaries, but it wasn’t weaponized until recently. In short, these are old vulnerabilities, but exploiting them was hard enough that it took twenty years to do it.
Building a new CPU is the work of a large team over several years. But they weren’t all working on the same thing for all that time. Any single feature would have been the work of a small team of engineers over a period of months. During development they fixed many problems we’ll never see. But at the end of the day, they are only human. They can be 99.9% perfect and that won’t be good enough, because once hardware is released into the world: it is open season on that 0.1% the team missed.
The odds are stacked in the attacker’s favor. The team on defense has a handful of people working a few months to protect against all known and yet-to-be discovered attacks. It is a tough match against the attackers coming afterwards: there are a lot more of them, they’re continually refining the state of the art, they have twenty years to work on a problem if they need to, and they only need to find a single flaw to win. In that light, exploits like Spectre and Meltdown will probably always be with us.
Let’s look at some factors that paved the way to Intel’s current embarrassing situation.
Continue reading “Spectre and Meltdown: Attackers Always Have The Advantage”
When news broke on Meltdown and Spectre ahead of the original disclosure plan, word spread like wildfire and it was hard to separate fact from speculation. One commonly repeated claim was that the fix would slow down computers by up to 30% for some workloads. A report released by Microsoft today says that “average users” with post-2015 hardware won’t notice the difference. Without getting into specific numbers, they mention that they expect folks running pre-2015 hardware to experience noticeable slowdowns with the patches applied.
The impact from Meltdown updates are easier to categorize: they slow down the transition from an user’s application level code to system level kernel code. The good news: such transitions were already a performance killjoy before Meltdown came along. There exists an extensive collection of tools (design patterns, libraries, and APIs) to help software developers reduce the number of user-kernel transitions.
Performance sensitive code that were already written to minimize kernel transitions will suffer very little from Meltdown updates. This includes most games and mainstream applications. The updates will have a greater impact on the minority of applications that frequently jump between kernel and user worlds. Antivirus software (with their own problems) have reasons to do so, and probably will end up causing most of the slowdowns seen by normal users.
Servers, with their extensive disk and networking IO — and thus kernel usage — are going to have a much worse time, even as seen through Microsoft’s rosy spectacles. So much so that Microsoft is recommending that admins “balance the security versus performance tradeoff for your environment”.
The impact from Spectre updates are harder to pin down. Speculative execution and caching are too important in modern CPUs to “just” turn off. The fixes will be more complex and we’ll have to wait for them to roll out (bumps and all) before we have a better picture.
The effects might end up being negligible as some tech titans are currently saying, and that probably will fit your experience, unless you’re running a server farm. But even if they’re wrong, you’ll still be comfortably faster than an Intel 486 or a Raspberry Pi.
Do any of you have numbers yet?
[via The Verge]