Spectre and Meltdown: Attackers Always Have The Advantage

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”

Getting a Handle on Meltdown Update Impact, Stay Tuned for Spectre

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]

 

Raspberry Pi Ain’t Afraid Of No Spectre And Will Not Meltdown

While there’s broad agreement that Meltdown and Spectre attacks are really bad news at a fundamental level, there is disagreement on its immediate practical impact in the real world. Despite reassurance that no attacks have been detected in the wild and there’s time to roll out the full spectrum of mitigation, some want to find protection right now. If you’re interested in an usable and easy to set up modern desktop that’s free of Meltdown or Spectre threats, a Raspberry Pi can provide the immunity you seek.

[Eben Upton] explained the side channel attacks using fragments of Python for illustration, which was an enlightening read independent of the Raspberry Pi pitch. While these ARM cores perform speculative instruction fetches, they don’t speculatively execute them or modify the cache. Under the current circumstances, that makes all the difference in the world.

A clever security researcher may yet find a way to exploit speculative fetches in the future, and claiming that Raspberry Pi has superior security would be a stretch. The platform has its own set of security problems, but today Meltdown/Spectre is not among them. And that just might be enough to sway some decisions.

If you need to stay in the x86 world, look over what it’d take to to rewind back to an Intel 486.

Thanks to [D00med] for sharing the link in a comment to our overview article.

Speculative Execution Was A Troublemaker For Xbox 360

Part of why people can’t stop talking about Meltdown/Spectre is the fact that all the individual pieces have been sitting in plain sight for a long time. When everyone saw how it all came together last week, many people (and not even necessarily security focused people) smacked themselves on the forehead: “Why didn’t I see that earlier?” Speculative execution has caused headaches going way back. [Bruce Dawson] tells one such story he experienced back in 2005. (Warning: ads on page may autoplay video.)

It’s centered around Xbox 360’s custom PowerPC processor. Among the customization on this chip was the addition of an instruction designed to improve memory performance. This instruction was a hack that violated some memory consistency guarantees held by the basic design, so they knew up front it had to be used very carefully. Even worse: debugging problems in this area were a pain. When memory consistency goes wrong, the code visible in the debugger might not be the actual code that crashed.

Since we’re talking about the dark side of speculative execution, you can already guess how the story ends: no matter how carefully it was used, the special instruction continued to cause problems when speculatively executed outside the constrained conditions. Extensive testing proved that instructions that were not being executed were causing crashes. That feels more like superstition than engineering. As far as he can recall, it ended up being more trouble than it was worth and was never used in any shipped Xbox 360 titles.

[Main image source: AnandTech article on Xbox 360 hardware]

Go Retro to Build a Spectre and Meltdown-Proof x86 Desktop

[Yeo Kheng Meng] had a question: what is the oldest x86 processor that is still supported by a modern Linux kernel? Furthermore, is it actually possible to use modern software with this processor? It’s a question that surely involves experimentation, staring into the bluescreen abyss of BIOS configurations, and compiling your own kernel. Considering Linux dropped support for the 386 in 2012, the obvious answer is a 486. This supposition was tested, and the results are fantastic. You can, indeed, install a modern Linux on an ancient desktop.

This project got its start last month at a Super Silly Hackathon where [Yeo] and [Hui Jing] installed Damn Small Linux on an ancient IBM PS/1 desktop of 1993 vintage. The hardware consists of an AMD 486 clone running at 133MHz, 64 MB of RAM, a 48x IDE CDROM drive (wow!), a floppy emulator, a Sound Blaster, 10Mbps Ethernet card, and a CompactFlash to IDE adapter. By any account, this is a pimped-out rig for 1993 that would have cost more than a car at the time. The hardware works, but can you run a modern Linux kernel on it?

[Yeo] decided to install the Gentoo x86 minimal installation, but sanity and time constraints meant compiling a kernel on a 486 wasn’t happening. That was done on a modern Thinkpad after partitioning all the drives, verifying all the compilation parameters, and configuring the kernel itself. The bootloader is LILO (Grub2 didn’t work), but for the most part, this is entirely modern software running on a 25-year-old machine. The step-by-step instructions for becoming a /g/entooman on a 486 are available on GitHub.

The entire (boring) boot process can be seen in the video below. One interesting application of this build is that the 486 does not support out-of-order execution, making this completely safe from Meltdown and Spectre attacks. It’s an impressive retrocomputing achievement that right now could not be more timely.

Continue reading “Go Retro to Build a Spectre and Meltdown-Proof x86 Desktop”

Hackaday Links: January 7, 2018

Whelp, Spectre and Meltdown are the tech news du jour right now, and everyone is wondering: what is the effect of this problem on real hardware in real server rooms? Epic Games patched their machines and found something shocking. The CPU utilization for one of their online services increased about 100%. We don’t know what this server is doing, or what this process is, but the Spectre and Meltdown patches will increase CPU load depending on the actual code running. This is bad for Epic — they now have to buy an entirely new server farm. This is doubly bad for Intel, and there is speculation of a class action suit floating around the darker corners of the Interwebs.

It is with a heavy heart that I must report the passing of John Young, the only person to have commanded four different classes of spacecraft (five if you include the lunar rover), including the first launch of the Space Shuttle. He was, simply, the most badass astronaut to ever live. Need proof of that? His heart rate during the launch of a Saturn V was seventy.

By the time this post is published, you’ll have less than twenty-four hours to submit your project to the Coin Cell Challenge. Get to it!

A short reminder that Shmoocon is a mere two weeks away. What is Shmoocon? A totally chill cyber/sec/hacker con at the Washington D.C. Hilton (yes, where Reagan was shot). We’ll be there, and we’re looking for some like-minded Hackaday peeps to chill out with. Want a meetup? Reply in the comments.

A few years ago, the ESP8266 appeared out of the blue in a few Chinese reseller’s web shops, and everything has been gravy since. Now there’s a new magic do-everything chip appearing on AliExpress and Taobao. It’s the RDA5981, a chip with an ARM Cortex M4 core, 32Mbit of Flash, 192k or user RAM, b/g/n WiFi, I2S, and enough peripherals to be useful. Given the support for a MIC, line in, MP3, WAV, WMA and AAC, it appears this is an all-in-one chip designed for Bluetooth speakers or some other audio application. You can find modules on Alibaba and a few breakout boards on Taobao.

According to my sources (the press releases that somehow slipped through the ‘CES’ filter on my email), the world’s fastest, smallest, biggest, least expensive, and newest drone is set to be unveiled at CES in Vegas this week.

Lowering JavaScript Timer Resolution Thwarts Meltdown and Spectre

The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.

Our web browsers present a huge potential surface for attack as JavaScript is ubiquitous on the modern web. Executing JavaScript code will definitely involve the processor cache and a high-resolution timer is accessible via browser performance API.

Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.

After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.

These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.

Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.

This is just one part of the shock wave Meltdown/Spectre has sent through the computer industry. We have broader coverage of the issue here.