News

3621 Articles

Lowering JavaScript Timer Resolution Thwarts Meltdown And Spectre

January 6, 2018 by 35 Comments

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.

Let’s Talk Intel, Meltdown, And Spectre

January 5, 2018 by 150 Comments

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.

There Once Was An IC Dedicated To Blinking An LED

January 4, 2018 by 56 Comments

Today you can buy flashing LEDs; a simple two-lead component that requires only a power supply to produce even flashes of light. They look for all the world like any other LED, though embedded in the plastic dome is an integrated circuit to do all that flashing work.

There was a time though when a flashing LED was something of a big deal, so much so that National Semiconductor produced a dedicated chip for the task. The LM3909 boasted the ability to flash an LED for over a year using a single C battery. That part is now long out of production, so [Dillon] has implemented the LM3909 circuit using discrete components on a small PCB designed to take pins and fit the footprint of the original.

Why on earth might a reborn LM3909 be of interest to him, you ask? Well, he wasn’t able to make a 555 flash the LED from a coin cell, and a friend mentioned this chip which piqued his interest. The internal schematic is in the data sheet (found in the files section of his project), so he was able to implement it relatively easily using common parts. It still requires an external capacitor just like the original, but there is space on-board should you wish to put it there.

He’s produced a video we’ve placed below the break showing the device in action, proving it to be a drop-in replacement for an original. Recreations of classic chips using discretes are nothing new, we recently brought you a reborn PSU regulator chip made in 2014. An while you’re playing around with coin cell batteries, may we direct your attention to the Coin Cell Challenge.

Continue reading “There Once Was An IC Dedicated To Blinking An LED” →

How Hackerspaces Spend Money

January 1, 2018 by 13 Comments

Running a hackerspace is no easy task. One of the biggest issues is money — how to collect in dues and donations, managing it, and how to spend it. Everyone has different interests and would like to see the budget go to their favorite project or resource. Milwaukee Makerspace has come up with a novel way to handle this. Members pay $40 a month in dues. $35 of that goes into the general budget. The member themselves can pick where the last $5 goes.

Using the hackerspace’s software, members chose where their $5 goes each month. It can all be spent in one area or split up among different resources at the hackerspace. Members choose from many different interests like the 3D printing area, the laser lab, the forge, or specific projects like the power racing series. This results in a budget for each area which can be used for materials and parts. It also gives the hackerspace board of directors information on which resources people are interested in, and which they aren’t.

In the current budget, no one is supporting the anodizing area, but lots of people are supporting the laser lab. This is just the sort of information the board could use when planning. Perhaps they could store the anodizing tools and expand the laser lab. Click through to the link above and see how this year’s cash voting panned out.

Of course, all this only works if you have a hackerspace with plenty of active members. In Milwaukee’s case, they have about 300 members. Would this work for your hackerspace? Let us know down in the comments!

Have Your Own 200 Water Street Digital Clock

December 31, 2017 by 11 Comments

On the front of a building in New York City, above a branch of the ubiquitous Starbucks coffee chain, there is a clock. It is no ordinary clock, the 200 Water Street clock is an art installation created by the artist [Rudolph de Harak], and consists of 72 lighted numbers which are illuminated in sequence to show hours, minutes, and seconds. It is a landmark of sufficient fame that [Jason Ben Nathan] and [Eldar Slobodyan], Cornell University students of [Bruce Land], decided to make their own tribute to it as their course project.

Water Street clock at night
Water Street clock at night [via NYC ♥ NYC]
It’s a fairly straightforward build, thanks to the use of Adafruit Dotstar multicolour LED strips which are populated with APA102 pixels. Behind the scenes is a PIC32 microcontroller, and the time information comes from an off-the-shelf 60kHz WWVB time signal receiver. There is also a temperature sensor, for a handy second function.

The front panel is a piece of ply with the required numbers nicely laser-cut. All the schematics and code are available, should you fancy your hand at building your own version of the clock.

If you are curious about the real-life clock here’s an image. But you get a much more interesting perspective if you stand in front of it. If you just can’t go there, get an approximation through the wonders of Google Street View.

34C3: Hacking Into A CPU’s Microcode

December 28, 2017 by 67 Comments

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

34C3: The First Day Is A Doozy

December 27, 2017 by 8 Comments

It’s 5 pm, the sun is slowly setting on the Leipzig conference center, and although we’re only halfway through the first day, there’s a ton that you should see. We’ll report some more on the culture of the con later — for now here’s just the hacks. Continue reading “34C3: The First Day Is A Doozy” →