‘It Can’t Be True’ – Inside the Semiconductor Industry’s Meltdown(bloomberg.com)
bloomberg.com
‘It Can’t Be True’ – Inside the Semiconductor Industry’s Meltdown
https://www.bloomberg.com/news/articles/2018-01-08/-it-can-t-be-true-inside-the-semiconductor-industry-s-meltdown
65 comments
This article made it easier for me to understand how various independent researchers could have arrived at the same discovery around the same time. It seems like Fogh was informally pushing the idea in private discussions, and then after Horn found the first PoC and notified Intel, other researchers got suspicious by the patches being submitted and put 2 and 2 together.
"Last week, his worst fears were proved right when Intel, one of the world’s largest chipmakers, said all modern processors can be attacked by techniques dubbed Meltdown and Spectre".
Seems like a sneaky reporting by Bloomberg - has Intel actually said that "all modern processors can be attacked by ... Meltdown"?
Seems like a sneaky reporting by Bloomberg - has Intel actually said that "all modern processors can be attacked by ... Meltdown"?
They're basically just regurgitating the sneakiness of Intel's official press release, which just said that all modern processors were affected and it wasn't an Intel-specific problem without clarifying in any way that the most serious problem was Intel-specific.
They're just reporting what Intel said, whereas later in the article they clarify the consequences for AMD and ARM in more detail.
> Spectre fools the processor into running speculative operations -- ones it wouldn’t normally perform -- and then uses information about how long the hardware takes to retrieve the data to infer the details of that information.
After reading several in-depth analysis of this vulnerability and then trying to explain my non-tech friends what this is all is about (disclaimer: I'm just a developer and don't work with assembly, processors or security), I have to admit that it's a pretty awesome executive summary of the issue for a non-technical reader.
After reading several in-depth analysis of this vulnerability and then trying to explain my non-tech friends what this is all is about (disclaimer: I'm just a developer and don't work with assembly, processors or security), I have to admit that it's a pretty awesome executive summary of the issue for a non-technical reader.
It's slightly wrong, proposal for improvement:
Spectre fools the processor into running speculative operations -- ones that it usually executes "just in case" and then throws the result away if it is not needed -- and then uses information about how long the hardware takes to retrieve the data to infer the details of that information.
Spectre fools the processor into running speculative operations -- ones that it usually executes "just in case" and then throws the result away if it is not needed -- and then uses information about how long the hardware takes to retrieve the data to infer the details of that information.
> Last week, his worst fears were proved right when Intel, one of the world’s largest chipmakers, said all modern processors can be attacked by techniques dubbed Meltdown and Spectre, exposing crucial data, such as passwords and encryption keys.
Intel was extremely lucky that Spectre was discovered at the same time as Meltdown, otherwise Intel would've been standing alone facing the industry.
Intel was extremely lucky that Spectre was discovered at the same time as Meltdown, otherwise Intel would've been standing alone facing the industry.
Having read the tech reports myself, the interviewee on the Bloomberg report seemed to be most sensible talking head I've yet seen in the media. While most of the press are shouting that we're all pwned and it's Intel's fault or Apple's fault, or whoever, I'm of the opinion that this is one seriously difficult bug to exploit.
The speculative branch predication vulnerability seems to basically depend on finding a specific instruction sequence in the target code and then going to some extraordinary lengths to exploit it via a highly convoluted side-channel.
My first thought when I started to appreciate the technical details were that this was a Bletchley Park level of exploit, or "nation state" as the man in the interview said. And whilst it's completely possible that the exploit could be packaged up for script kiddies, it seems to me unlikely that someone with the necessary skills would do that, because the return would be too low. But states spying on each other: that seems a much more likely scenario for this.
The speculative branch predication vulnerability seems to basically depend on finding a specific instruction sequence in the target code and then going to some extraordinary lengths to exploit it via a highly convoluted side-channel.
My first thought when I started to appreciate the technical details were that this was a Bletchley Park level of exploit, or "nation state" as the man in the interview said. And whilst it's completely possible that the exploit could be packaged up for script kiddies, it seems to me unlikely that someone with the necessary skills would do that, because the return would be too low. But states spying on each other: that seems a much more likely scenario for this.
I am not an expert in these matters in any way, but most vulnerabilities appear fairly difficult to exploit to me (as an application developer).
Isn't it usually the case that someone scripts (difficult parts of) the process and then it is a lot easier to exploit?
Isn't it usually the case that someone scripts (difficult parts of) the process and then it is a lot easier to exploit?
Yes, but my point is I think the exploit would be extremely difficult, and any agent capable of doing it would not be too interested in making it available to anyone else. Perhaps I'm naive, but it feels like the kind of thing government agencies would keep in their own armouries.
This
>I think the exploit would be extremely difficult,
and this
>The idea nagged at Prescher, so when he got home he fired up his desktop computer and set about putting the theory into practice. At 2 a.m., a breakthrough: he’d strung together code that reinforced Fogh’s idea and suggested there was something seriously wrong.
Don't seem to match up. It may be hard, but even a security researcher doesn't bust a hard to exploit hole open in a few hours overnight. I believe that this was an area where no one was looking and now that its out in the open it will be much easier for others to exploit.
>I think the exploit would be extremely difficult,
and this
>The idea nagged at Prescher, so when he got home he fired up his desktop computer and set about putting the theory into practice. At 2 a.m., a breakthrough: he’d strung together code that reinforced Fogh’s idea and suggested there was something seriously wrong.
Don't seem to match up. It may be hard, but even a security researcher doesn't bust a hard to exploit hole open in a few hours overnight. I believe that this was an area where no one was looking and now that its out in the open it will be much easier for others to exploit.
As a general rule, I'd think the harder part is figuring out that the vulnernability is possible in the first place and formulating an approximate algorithm to exploit it. Implementation is a lot easier when you have a blueprint for what to do.
Yes, but again, proving there's an exploit is different to implementing it and actually stealing someone's banking details (which is the media definition of a scary hack). And you say "even a security researcher"... surely they are the guys most likely to be able to perform the exploit, in real life?
To prove the vulnerability is exploitable I'd ideally do ahead and do it. Has this not been done?
It's one thing to exploit something locally. It's another to exploit it remotely. And if you have local access to a machine I'm sure there are much easier ways to get root access to it.
Before being patched, this exploit would have worked at any of the cloud providers: Google Compute Engine, AWS, etc. You could have run it on thousands of virtual machines and sifted through all the data of other VMs running on the same hardware.
Oh, and it works (/worked) on browsers.
Oh, and it works (/worked) on browsers.
Or you could just download it from github. https://github.com/paboldin/meltdown-exploit
Perhaps I'm reading the code wrong, but that seems to be a check if your CPU is vulnerable, rather than an exploit. It seems to me that in order to actually obtain any useful information using this method would require far more work. I'm happy to be corrected if that is not the case...
Played with it a bit, to me it is really reading data of arbitrary size starting at any given memory address.
Usage is ./meltdown [hexadrr] [size]
Run.sh is first reading the adress where the value of linux_proc_banner is held, with a adequat sed on /proc/kallsyms, then running the meltdown binary to check that this adress has the value stored in /proc/version, which should be the case if the exploit is indeed working (which IS the case with my CPU and current kernel).
Meltdown.c is below 300 lines, the actual exploit being maybe half of that.
From here, it seems to me that you can extrapolate in reading any value anywhere in the memory.
Usage is ./meltdown [hexadrr] [size]
Run.sh is first reading the adress where the value of linux_proc_banner is held, with a adequat sed on /proc/kallsyms, then running the meltdown binary to check that this adress has the value stored in /proc/version, which should be the case if the exploit is indeed working (which IS the case with my CPU and current kernel).
Meltdown.c is below 300 lines, the actual exploit being maybe half of that.
From here, it seems to me that you can extrapolate in reading any value anywhere in the memory.
Meltdown is not that hard to exploit:
1. Just download the POC, its a C program which reads the kernel memory at a speed of ~2KB/sec.
2. Deploy it to as many AWS instances as possible.
3. save the results somewhere and search it for stuff like CC card numbers or passwords.
Luckily this is not possible because the tech companies were really careful about this issue and deployed a fix very quickly.
1. Just download the POC, its a C program which reads the kernel memory at a speed of ~2KB/sec.
2. Deploy it to as many AWS instances as possible.
3. save the results somewhere and search it for stuff like CC card numbers or passwords.
Luckily this is not possible because the tech companies were really careful about this issue and deployed a fix very quickly.
Depends if one of the semi criminal subcontractors that the FSB /GRU use or some idiot "booze mah kidney" NSA contractor gets pwnd - all bets are off.
The _sec world has its own variant of the architecture astronaut problem.
These are researchers that see anything that can't stop a TLA in its tracks as fundamentally flawed.
And yes, you will likely find them congregating at defcon, laughing and cheering at the sheeple board, and playing spot the fed.
These are researchers that see anything that can't stop a TLA in its tracks as fundamentally flawed.
And yes, you will likely find them congregating at defcon, laughing and cheering at the sheeple board, and playing spot the fed.
Is this Brian White for real?
Host: Who could exploit this vulnerability...? White: Those that have significant resources, for instance, Google... (mentions nation-states much later)
Nice FUD there.
White: what is important here, there are no known attacks ongoing right now...
Nice argument from ignorance there.
White: there is a lot of things we don't know but it reinforces two things to me, one is that increasingly the software we are operating is quite secure, coz now we are looking at kernel level problems...
Nice false cause fallacy.
Host: Who could exploit this vulnerability...? White: Those that have significant resources, for instance, Google... (mentions nation-states much later)
Nice FUD there.
White: what is important here, there are no known attacks ongoing right now...
Nice argument from ignorance there.
White: there is a lot of things we don't know but it reinforces two things to me, one is that increasingly the software we are operating is quite secure, coz now we are looking at kernel level problems...
Nice false cause fallacy.
You should argue the points, not label the fallacies. Would you rather White say “well there’s probably attacks, but no one knows!”? This is just as incorrect as his statement, the problem being that /no one knows./
The FUD is real though.
The FUD is real though.
Arguing logical fallacies is a waste of time and effort.
They are things that never should have been said in the first place because they're only made to deflect, detract, or support a nonsensical argument.
If you get caught up in trying to defend against these things you've already fallen into their trap.
They are things that never should have been said in the first place because they're only made to deflect, detract, or support a nonsensical argument.
If you get caught up in trying to defend against these things you've already fallen into their trap.
People frequently use logical fallacies in good faith, usually because they're falling for one of the many permutations of the law of averages, using associative logic/magical thinking, or just have some axiomatic beliefs that they believe are somehow sinful/wrong to scrutinize due to their religion/loyalty.
Very true, I think the point still stands though that the best thing to do is to point them out rather than to try and argue them.. otherwise you end up legitimizing the discussion and going off on some irrelevant tangent rather than debating something worthwhile.
Yup. Big difference between rhetoric and an intellectually honest discussion.
"If you're explaining, you're losing." -- Lee Atwater
"If you're explaining, you're losing." -- Lee Atwater
I've heard security researchers make the last claim. Especially with the increasing use of fuzzing, ASLR, etc., trivially exploitable buffer overflows and other things of that nature are much less common now.
But still extremely common. SQL injection is my favorite one. We've had a good solution for it for ages. But look at CVEs and you will still see loads of SQL injection.
Is it just me who now thinks there should be some gigantic holes in processor security, which were just never stumbled upon before, but now will?
Similarly how there was a long and happy life of flash plugin before it was recognized as a massive vulnerability surface?
Similarly how there was a long and happy life of flash plugin before it was recognized as a massive vulnerability surface?
I'm finding it hard to escape the suspicion that Spectre and (to a lesser extent) Meltdown is another failure of expertise on the same rough scale as the run-up to the financial crisis, the decades of bad or poorly-justified dietary advice, and the statistical problems in experimental psychology. On the face of it, it seems obvious that speculation + cache + protected mode was a combination likely ripe for exploitation, but the response seems to have been "nah, it'll be fine, probably"? And even if it for some reason wasn't obvious, it's now clear that it actually was the case. So the academic and industrial and bad-boy "security community" collectively more or less let the CPU manufacturers take a flyer on this for, what, a decade?
Speculative execution, out of order execution, branch prediction have been in processor designs at least back to the 1980s.
Sure. I had Meltdown specifically on the brain when I wrote that, sorry. It hardly needs saying that the preconditions for Spectre-like attacks being around for several decades doesn't make the situation any less embarrassing. (That said, I don't know whether things like eg. increasing pipeline depths only made actual attacks feasible relatively recently.)
I think this is a pervasive problem in big corporations and government. There are probably a few people that are concerned with security and others that are concerned with performance. They don't talk enough.
The problem, I believe, is that most people (even many in CS/CE/EE) don't fully understand the complexity of Turing machines running programs in recursively enumerable languages. Moving a problem into software doesn't merely add complexity; it moves the problem into another class of complexity where behavior cannot be understood without running the program[1]. The behavior of sufficiently large programs (>8k states[2]) is so complex it cannot be described by math[3].
Anybody claiming to understand the consequences of adding any new feature to a processor (or software) is implicitly claiming they have solved the equivalent to halting problem. The only solution is to move as many problem as possible back to a simpler domain that is actually decidable[4].
[1] halting problem, Gödel’s Incompleteness Theorem
[2] https://www.scottaaronson.com/blog/?p=2725
[3] "math" := ZF set theory
[4] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
Anybody claiming to understand the consequences of adding any new feature to a processor (or software) is implicitly claiming they have solved the equivalent to halting problem. The only solution is to move as many problem as possible back to a simpler domain that is actually decidable[4].
[1] halting problem, Gödel’s Incompleteness Theorem
[2] https://www.scottaaronson.com/blog/?p=2725
[3] "math" := ZF set theory
[4] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
Not really. That's the 'only solution' if use limit yourself to the straight jacket of existing CS theoretical methods. Given how irrelevant it has been to industry up to this point (unable to even prove something as simple to state as whether P = NP), that seems pointless.
There are many specific Turing machines for which the behavior can be understood without running the program, such as the one that starts by unconditionally halting.
Are you careful to only run e.g only run javascript it's one of those special cases? How often do you use the one-state program that unconditionally halts?
One never actually runs a Turing machine, they exist only for the purpose of argument.
Well, the article ends with that same thought coming from one of the researchers.
I didn't see any mention of weather Linus et al were on the inside of this. The impression I get from the article is that they weren't. But that must be wrong, right?
He does live less than 20 miles from Intel. They could have just driven to his house to let him know.
I can imagine Linus Torvalds happily working one bright California afternoon and gets a knock at the door. Two men say they are from Intel and need to discuss a serious bug with him. Wondering what could be so bad that Intel pays him a personal visit, he invites them into the sitting room, gets them some tea/coffee. Then they describe the problem.
What I want to know is what happens next? Is Linus (or "Mr. Torvolds" to me) silently shocked? Does he go on a LKML-style rant? Immediately whip out his laptop and code up an exploit just to see if it's actually true? All of them?
(Mostly I just want to hear him rant, I love his well-informed, opinionated take-downs of lousy ideas. Although it's probably a toxic environment to work it.)
What I want to know is what happens next? Is Linus (or "Mr. Torvolds" to me) silently shocked? Does he go on a LKML-style rant? Immediately whip out his laptop and code up an exploit just to see if it's actually true? All of them?
(Mostly I just want to hear him rant, I love his well-informed, opinionated take-downs of lousy ideas. Although it's probably a toxic environment to work it.)
Headline hyperbole. Applications of high end CPU suffer. That AVR-equipped light bulb doesn’t, nor do voltage regulators or DRAMs (though they could suffer if fewer devices are built...which won’t happen)
That's actually an interesting accidental point.
How many embedded CPU's with speculation might be affected? You may say "none" but there are Cortex CPUs embedded into FPGAs (either directly or form of IP cores). What if enterprise routers have them? What if TVs have them?
I know many Cortex's aren't affected. The point is, anything that needs a "fast enough" CPU to benefit from OoO scheduling is possibly at risk, right? So while most embedded devices use cheaper, less complex CPUs, there are plenty that don't--as more powerful CPUs (which offer speculation) are becoming cheaper and cheaper.
A Raspberry Pi 3 has a Cortex-A53 (because they're cheap). They're luckily not affected, but those CPUs and faster are cheap enough to throw onto a $35 retail price computer. What's running in your $800 internet-connected 4K TV?
Per the Pi 3 explaination page:
>Examples of out-of-order processors include the Intel Pentium 2 (and most subsequent Intel and AMD x86 processors with the exception of some Atom and Quark devices), and many recent ARM cores, including Cortex-A9, -A15, -A17, and -A57.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
The A9, 15, 17, and A57 are all affected and used across TONS of devices in the world. They're very popular not just in chip form (as the primary CPU), but also in IP cores (inside an FPGA), as well as "secondary CPU" systems attached to FPGAs or other CPU's.
And that's just one brand of one type of CPU. Who knows what else is out there. PowerPCs are in everything. Even your dust-covered Gamecube has out-of-order speculation!
Here's a link mentioning that PowerPC CPUs are affected:
http://tenfourfox.blogspot.com/2018/01/is-powerpc-susceptibl...
So there goes all your PowerMacs. (And likely the Gamecube and Wii too!)
How many embedded CPU's with speculation might be affected? You may say "none" but there are Cortex CPUs embedded into FPGAs (either directly or form of IP cores). What if enterprise routers have them? What if TVs have them?
I know many Cortex's aren't affected. The point is, anything that needs a "fast enough" CPU to benefit from OoO scheduling is possibly at risk, right? So while most embedded devices use cheaper, less complex CPUs, there are plenty that don't--as more powerful CPUs (which offer speculation) are becoming cheaper and cheaper.
A Raspberry Pi 3 has a Cortex-A53 (because they're cheap). They're luckily not affected, but those CPUs and faster are cheap enough to throw onto a $35 retail price computer. What's running in your $800 internet-connected 4K TV?
Per the Pi 3 explaination page:
>Examples of out-of-order processors include the Intel Pentium 2 (and most subsequent Intel and AMD x86 processors with the exception of some Atom and Quark devices), and many recent ARM cores, including Cortex-A9, -A15, -A17, and -A57.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
The A9, 15, 17, and A57 are all affected and used across TONS of devices in the world. They're very popular not just in chip form (as the primary CPU), but also in IP cores (inside an FPGA), as well as "secondary CPU" systems attached to FPGAs or other CPU's.
And that's just one brand of one type of CPU. Who knows what else is out there. PowerPCs are in everything. Even your dust-covered Gamecube has out-of-order speculation!
Here's a link mentioning that PowerPC CPUs are affected:
http://tenfourfox.blogspot.com/2018/01/is-powerpc-susceptibl...
So there goes all your PowerMacs. (And likely the Gamecube and Wii too!)
Unless these embedded CPU run third party code, they aren't really vulnerable. This is more of a general computing problem.
Many of these devices can run 3rd party code in user context (java script in browser). The big issue is they rarely have updates and many if not most are impossible to do a good security audit on.
Not many embedded devices run browsers. That leaves you no place to run the javascript.
> What's running in your $800 internet-connected 4K TV?
Not my banking website, for one thing. Your point is completely valid, but sadly no-one in the media cares whether your TV or toaster is vulnerable.
Perhaps they should be, because in reality, all these devices could be used in a botnet. But then again, it's so much easier to hack those devices with default admin/password123 than it is using speculative branch predication exploits...
Not my banking website, for one thing. Your point is completely valid, but sadly no-one in the media cares whether your TV or toaster is vulnerable.
Perhaps they should be, because in reality, all these devices could be used in a botnet. But then again, it's so much easier to hack those devices with default admin/password123 than it is using speculative branch predication exploits...
Not really a semiconductor issue. I doubt the guys working on analogue ICs are working overtime on this.
It's Bloomberg. They view things in terms of economic sectors. To them, integrated circuit design and manufacturing is all part of one sector.
Well said. I think that applies to any journalist by extension. Little do they know about the difference between analog and digital.
Bloomberg is a technology company
The narrative sounds a bit like the story of Chernobyl. Except with less (for now) human suffering.