Thursday, January 5th 2017

Intel Released "Coffee Lake" Knowing it Was Vulnerable to Spectre and Meltdown

By the time Intel launched its 8th generation Core "Coffee Lake" desktop processor family (September 25, 2017, with October 5 availability), the company was fully aware that the product it is releasing was vulnerable to the three vulnerabilities plaguing its processors today, the two more publicized of which, are "Spectre" and "Meltdown." Google Project Zero teams published their findings on three key vulnerabilities, Spectre (CVE-2017-5753 and CVE-2017-5715); and Meltdown (CVE-2017-5754) in mid-2017, shared with hardware manufacturers under embargo; well before Intel launched "Coffee Lake." Their findings were made public on January 3, 2018.

Intel's engineers would have had sufficient time to understand the severity of the vulnerability, as "Coffee Lake" is essentially the same micro-architecture as "Kaby Lake" and "Skylake." As one security researcher puts it, this could affect Intel's liability when 8th generation Core processor customers decide on a class-action lawsuit. As if that wasn't worse, "Skylake" and later micro-architectures could require micro-code updates in addition to OS kernel patches to work around the vulnerabilities. The three micro-architectures are expected to face a performance-hit, despite Intel extracting colorful statements from its main cloud-computing customers that performance isn't affected "in the real-world." The company was also well aware of Spectre and Meltdown before its CEO dumped $22 million in company stock and options (while investors and the SEC were unaware of the vulnerabilities).
Add your own comment

111 Comments on Intel Released "Coffee Lake" Knowing it Was Vulnerable to Spectre and Meltdown

#51
NicklasAPJ
jigar2speed said:
^This, this is the reason why people get hacked and don't even realise/know that its not just your email account. Identity theft is the first thing that comes to my mind. Incase if you are using netbanking, you are screwed, incase if you are using CC for buying anything online, you are screwed.
This vulnerability has your computer completely exposed to attacks that you don't even comprehend yet. Oh and not having antivirus is an excellent recipe where you are already breached and someone might using your system for DDOS attacks or someone might be threatening someone pretending to be you. Things can go bad to worst and you won't even know it until authorities show up at your doorsteps.
What? I did not use a Anti Virus program for 10 years now, and still not a single time I got hacked.
Posted on Reply
#52
Basard
NicklasAPJ said:
What? I did not use a Anti Virus program for 10 years now, and still not a single time I got hacked.
Same here..... I say its half luck. Pray to RNJesus.
Posted on Reply
#53
Emu
NicklasAPJ said:
What? I did not use a Anti Virus program for 10 years now, and still not a single time I got hacked.
How do you know that? How do you know that your computer is not spewing out spam email by the boat load? How do you know that your computer is not sending out random packets at hosts in a DDoS bot network? Not all malware is aimed at disrupting your experience...
Posted on Reply
#54
lexluthermiester
Prima.Vera said:
Why do I have a feeling that things are blowing out of proportions again...
Perhaps the seriousness of these problems have not been made clear to you yet? These vulnerabilities go back all the way to CPU's made in the 90's.

All CPU's are affected. Intel's CPU's a taking a bit more of the brunt of all of this, but all x86, x64, MIPS, PPC and RISC CPU's are affected.
Emu said:
How do you know that? How do you know that your computer is not spewing out spam email by the boat load? How do you know that your computer is not sending out random packets at hosts in a DDoS bot network? Not all malware is aimed at disrupting your experience...
Maybe because they use network monitoring software or a firewall and watches their network traffic?
Posted on Reply
#55
Steevo
Manu_PT said:
You can worry if you want. I´m not worried at all, I don´t use anything that can allow access to my stuff with those flaws. You need to read the full disclosure of it to understand. Then talk please.

Stop spreading misinformation if you guys don´t know what you´re talking about.
You are on the internet, using a browser, and Intel hardware, you are susceptible to at least two of the flaws. https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/

I have read the full disclosures, read the way the fauls were found, and understand that it affects almost everyone on the internet, and one idiot not running AV as they are somehow immune only makes it worse as your system could easily be host to a plethora of malware. Your TPU ID could be compromised, you could start sending out spam messages, your email could be compromised, your home PC could be being used to bounce traffic or to spam. Your bank account information, personal data from taxes, and much more can be accessed by simply reading data out of your computer as if they were sitting in front of it reading your passwords written on sticky notes. It is a big deal to essentially every company, as all it takes to get this access is using the internet, and a simple java script. Its akin to the olden days where network worms were prevalent and few had anti-virus so they spread like wildfire, except this doesn't need to spread, it just needs you to use any portion of the internet and your browser to run a snip of java, which happens all the time.
Posted on Reply
#56
lexluthermiester
Steevo said:
You are on the internet, using a browser, and Intel hardware, you are susceptible to at least two of the flaws.
You are on the internet, using a browser, and using a modern CPU, you are susceptible to at least two of the flaws. https://meltdownattack.com/
Posted on Reply
#57
newtekie1
Semi-Retired Folder
Vayra86 said:
I keep reading this on TPU, but these days 'to execute code' is not something that needs to be done locally, it just needs to reside locally. Any malware can reside on your system for days, months, undetected and call home once its done reading out the process it wants to read.

The user really doesn't have to be in play here.
For the code to get on the machine locally, it requires the user do something to get it there. Despite popular belief, hackers can't just access your computer and put anything on your computer you they want without you doing something to allow it. Even if that something is visiting a malicious website.
Posted on Reply
#58
lexluthermiester
newtekie1 said:
For the code to get on the machine locally, it requires the user do something to get it there. Despite popular belief, hackers can't just access your computer and put anything on your computer they want without you doing something to allow it. Even if that something is visiting a malicious website.
Fixed that for you. I agree with your points. While these are serious problems, criminals are not going to be able to just waltz into a PC willy-nilly.
Posted on Reply
#59
_UV_
Vayra86 said:

Let me sketch a worst-case scenario: software patching keeps getting circumvented and new hacks actually occur using these backdoors. At some point, public outrage forces Intel/AMD to start disabling branch prediction/speculative exec entirely. All of a sudden we're back in Sandy Bridge performance metrics ie. performance drops to 2012 mainstream.
Very optimistic. Branch prediction and speculative execution related to Pentium/Pro era, and it doubles performance against 486. Also we have much more than 2 execution units per core (processor) now with all what x86 microop decoding to RISC. So i would say modern 4GHz would be equal to Piii/early Athlons with all features enabled.
Posted on Reply
#62
efikkan
First Strike said:
It is OK to blame Intel for releasing Meltdown-vulnerable processors. But since it can be solved with Linux KPTI and Windows kernel rework, and Intel did finish those work with Linux team and Microsoft in time, it's kinda less unacceptable.

But hell no, you can’t blame Intel for Spectre vulnerability. It affects ALL modern processors with speculative execution and is simply impossible to fix (unless every app developer cooperates). The only way we currently know is to drop speculative execution and get back to stone age (80x86). We need another breakthrough in computer science in the following years to fix it.
It's not only unfair, but completely ridiculous to blame Intel for everyone's mistakes. This of course doesn't diminish the severity of the problem, but makes them all sinners.

Some refers to these issues with speculative execution as "Meltdown" and "Spectre", Google divides it into three classes, and ARM divides it into "four". All modern x86 (both Intel and AMD), most ARM processors and even IBM Power are affect by one or more of these exploits. It's worth mentioning that these are not production errors or tapeout mistakes, these are all logical design errors. So why does very different designs have similar mistakes? Simply because engineers are prone to do similar mistakes and assumptions when tackling similar problems. This is why it's simple to find many new problems once we've discovered one new class of mistakes.

Something tells me there will be even more exploits found soon, with this many people exploring these new approaches and the embargo being lifted next Tuesday.

Prima.Vera said:
But then again, for a normal desktop machine, do you really need a bios and OS update that just going to slow your CPU down? I mean how many Joes are running VMs in a shared environment??
Most sites, including TPU, incorrectly refers to these bugs as VM related, but they're not. These bugs are related to leaking of virtual memory, which is the method of separating the address space of each process and of course kernel memory. This is done in every modern operating system, and is one of the primary tasks of the OS kernel itself. The process involves something called "paging", which are small chunks of memory mapped into a continuous address space for each process, while it in reality are fragmented chunks spread throughout the physical address space.

A user space process is only allowed to access it's own memory, attempting to access memory outside this range will result in a page fault. These new exploits involves techniques to make the CPU leak small parts of unaccessible kernel memory. It seems like you can only get a few bytes at the time, and Google achieved something like ~2kB/s, so it will take a while to dump all of the memory… But provided you can dump arbitrary memory this way, any single user space process can in theory* dump the entire system memory, including memory of other processes and the kernel itself.

This is where Virtual Machines actually comes in, since VMs technically only is a process on a host machine. So if one process can access the memory of any other process, it would mean one VM can access the memory of another VM as well. This is a serious exploit vector since cloud providers make their living off allowing people to run their own VMs on the same host.

But as mentioned, the exploit itself has nothing to do with VMs. Any specially crafted program with the right system calls executed on a machine will be able to do it. So going back to your question, does this apply to your desktop machine? Yes, if you run any executable which is not trusted. But, this is not limited to standalone programs, but also JIT programs like Java applets or Java apps on your phone, various scripts, etc. The big question remains if JavaScript in Web Browsers are able to execute this. I'm not sure yet if it's possible, but evidently both Google and Mozilla thinks there might be a risk. If this turns out to be feasable, then these exploits become much worse than for VMs, since it will allow any web page to scan through system memory for things like encryption keys, passwords, etc. , and then it's really bad!

*) Why in theory? At this rate the memory is likely to change rapidly while dumping it, so making a complete dump will be hard.

cmmw said:
This may all not be a design flaw but "is functional by design as a backdoor to professional hackers, legel, and illegal organization that had been informed about the backdoor." NSA is one of the publicly known organizations.
These exploits is about leaking memory, not backdoors.

BTW, Windows has had a "service backdoor" since 95…

Jism said:
This is why trust AMD with hardware more then Intel. The amount of bugs that Intel actually has is scaring. The IMEI thing, now this. So basicly no matter how updated your OS, Antivir, Firewall and even router configuration was, your system was still completely vulnerable towards some slick exploits causing safe data to be compromised.
Because AMD is bug-free? Have you even followed this subject? AMD is affected as well.
AMD also incorporate a security processor like Intel, and it's not that many months ago that AMD refused to admit a serious stability issue which they dismissed as a "performance bug marginally affecting Linux", despite it having no relation to Linux nor performance. All of these vendors will always downplay or dismiss problems, even when they are fully aware.
Edit: AMD PSP Affected By Remote Code Execution Vulnerability

Both Intel, AMD and ARM has been aware of these new bugs since last summer.

Jism said:

And on top of that, have 5 up to 30% performance penalty due to a software fix.
These performance numbers are referring to the performance in edge cases with Linux kernel KPTI patches which were made in a rush to circumvent the problem. It's very likely that better OS patches combined with firmware tweaks will reduce this slowdown. Many workloads, such as gaming and video encoding should not be affected.

CrAsHnBuRnXp said:
We should all get a refund on our processors and motherboards and then buy stock in AMD and all buy Ryzen products.
You mean old 486 cpus from AMD, right? All modern AMD CPUs are affected.

newtekie1 said:
For the code to get on the machine locally, it requires the user do something to get it there. Despite popular belief, hackers can't just access your computer and put anything on your computer you want without you doing something to allow it. Even if that something is visiting a malicious website.
This all depends on this being exploitable through JavaScript, which "everyone" executes happily. It's already known to be exploitable through JIT compiled stuff such as Android apps and Java applets. See my longer paragraph above.
Posted on Reply
#63
newtekie1
Semi-Retired Folder
lexluthermiester said:
Fixed that for you. I agree with your points. While these are serious problems, criminals are not going to be able to just waltz into a PC willy-nilly.
Yes, thank you. For these things to be exploited on a consumer level system, or even really an enterprise data center system, there has to be some other security issues at play. In the consumer space, those other security flaws already pretty much give the malicious person access to your system, so this security flaw is just icing on the cake.

efikkan said:
This all depends on this being exploitable through JavaScript, which "everyone" executes happily. It's already known to be exploitable through JIT compiled stuff such as Android apps and Java applets. See my longer paragraph above.
Yes, like I said, it could be as simple as visiting the wrong site. But this is also where having a AV program is a must. I would be very surprised if the major AV programs out there aren't updated to recognize a process that is exhibiting the behavior of this exploit and lock down the process long before it can really get anything useful from a consumer level system. It is exploits like this that made all the good AVs add behavior detection in the first place.
Posted on Reply
#64
efikkan
newtekie1 said:

Yes, like I said, it could be as simple as visiting the wrong site. But this is also where having a AV program is a must. I would be very surprised if the major AV programs out there aren't updated to recognize a process that is exhibiting the behavior of this exploit and lock down the process long before it can really get anything useful from a consumer level system. It is exploits like this that made all the good AVs add behavior detection in the first place.
That's not how Antivirus works. It can only recognize file signatures of known malware and known filenames, they never are able to analyze execution of code in real time, that would slow down your computer by a factor of 10,000 and be analytically impossible.

Even if this is exploitable through JavaScript, no Antivirus can intercept this execution. It will have to be up to the CPU firmware, OS kernel an to some extent JavaScript interpretor (browser) to put the appropriate safeguards in place to avoid the problem.
Posted on Reply
#65
lexluthermiester
efikkan said:
That's not how Antivirus works. It can only recognize file signatures of known malware and known filenames, they never are able to analyze execution of code in real time, that would slow down your computer by a factor of 10,000 and be analytically impossible.
That's not true at all. Antivirus suites have been using real-time heuristic analyzation for over a decade and some of them are very good at it. It isn't perfect and can often render false positives, but it is used none-the-less.
Posted on Reply
#66
newtekie1
Semi-Retired Folder
efikkan said:
That's not how Antivirus works. It can only recognize file signatures of known malware and known filenames, they never are able to analyze execution of code in real time, that would slow down your computer by a factor of 10,000 and be analytically impossible.

Even if this is exploitable through JavaScript, no Antivirus can intercept this execution. It will have to be up to the CPU firmware, OS kernel an to some extent JavaScript interpretor (browser) to put the appropriate safeguards in place to avoid the problem.
Yeah, go do more research on how modern anti-virus programs work. Signature based detection, while still in use, has long been considered largely ineffective against modern viruses. Behavioral and heuristic based detection has become the new method that any good anti-virus uses.
Posted on Reply
#67
Manu_PT
efikkan said:
It's not only unfair, but completely ridiculous to blame Intel for everyone's mistakes. This of course doesn't diminish the severity of the problem, but makes them all sinners.

Some refers to these issues with speculative execution as "Meltdown" and "Spectre", Google divides it into three classes, and ARM divides it into "four". All modern x86 (both Intel and AMD), most ARM processors and even IBM Power are affect by one or more of these exploits. It's worth mentioning that these are not production errors or tapeout mistakes, these are all logical design errors. So why does very different designs have similar mistakes? Simply because engineers are prone to do similar mistakes and assumptions when tackling similar problems. This is why it's simple to find many new problems once we've discovered one new class of mistakes.

Something tells me there will be even more exploits found soon, with this many people exploring these new approaches and the embargo being lifted next Tuesday.


Most sites, including TPU, incorrectly refers to these bugs as VM related, but they're not. These bugs are related to leaking of virtual memory, which is the method of separating the address space of each process and of course kernel memory. This is done in every modern operating system, and is one of the primary tasks of the OS kernel itself. The process involves something called "paging", which are small chunks of memory mapped into a continuous address space for each process, while it in reality are fragmented chunks spread throughout the physical address space.

A user space process is only allowed to access it's own memory, attempting to access memory outside this range will result in a page fault. These new exploits involves techniques to make the CPU leak small parts of unaccessible kernel memory. It seems like you can only get a few bytes at the time, and Google achieved something like ~2kB/s, so it will take a while to dump all of the memory… But provided you can dump arbitrary memory this way, any single user space process can in theory* dump the entire system memory, including memory of other processes and the kernel itself.

This is where Virtual Machines actually comes in, since VMs technically only is a process on a host machine. So if one process can access the memory of any other process, it would mean one VM can access the memory of another VM as well. This is a serious exploit vector since cloud providers make their living off allowing people to run their own VMs on the same host.

But as mentioned, the exploit itself has nothing to do with VMs. Any specially crafted program with the right system calls executed on a machine will be able to do it. So going back to your question, does this apply to your desktop machine? Yes, if you run any executable which is not trusted. But, this is not limited to standalone programs, but also JIT programs like Java applets or Java apps on your phone, various scripts, etc. The big question remains if JavaScript in Web Browsers are able to execute this. I'm not sure yet if it's possible, but evidently both Google and Mozilla thinks there might be a risk. If this turns out to be feasable, then these exploits become much worse than for VMs, since it will allow any web page to scan through system memory for things like encryption keys, passwords, etc. , and then it's really bad!

*) Why in theory? At this rate the memory is likely to change rapidly while dumping it, so making a complete dump will be hard.


These exploits is about leaking memory, not backdoors.

BTW, Windows has had a "service backdoor" since 95…


Because AMD is bug-free? Have you even followed this subject? AMD is affected as well.
AMD also incorporate a security processor like Intel, and it's not that many months ago that AMD refused to admit a serious stability issue which they dismissed as a "performance bug marginally affecting Linux", despite it having no relation to Linux nor performance. All of these vendors will always downplay or dismiss problems, even when they are fully aware.
Edit: AMD PSP Affected By Remote Code Execution Vulnerability

Both Intel, AMD and ARM has been aware of these new bugs since last summer.


These performance numbers are referring to the performance in edge cases with Linux kernel KPTI patches which were made in a rush to circumvent the problem. It's very likely that better OS patches combined with firmware tweaks will reduce this slowdown. Many workloads, such as gaming and video encoding should not be affected.


You mean old 486 cpus from AMD, right? All modern AMD CPUs are affected.


This all depends on this being exploitable through JavaScript, which "everyone" executes happily. It's already known to be exploitable through JIT compiled stuff such as Android apps and Java applets. See my longer paragraph above.
AMD has the spectre problem wich isn´t 1/10 as bad as meltdown. Don´t spread misinformation. Meltdown is the real problem here, Spectre is just another threat like 10000 others, and you need physical access to the machine first, to use it.
Posted on Reply
#68
efikkan
Manu_PT said:
AMD has the spectre problem wich isn´t 1/10 as bad as meltdown. Don´t spread misinformation. Meltdown is the real problem here, Spectre is just another threat like 10000 others, and you need physical access to the machine first, to use it.
No, both needs to be executed on the actual machine.
The first two variants abuse speculative execution to perform bounds-check bypass (CVE-2017-5753), or by utilizing branch target injection (CVE-2017-5715) to cause kernel code at an address under attacker control to execute speculatively. Collectively these are known as "Spectre". Both variants rely upon the presence of a precisely-defined instruction sequence in the privileged code, as well as the fact that memory accesses may cause allocation into the microprocessor’s level 1 data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use these two flaws to read privileged memory by conducting targeted cache side-channel attacks. These variants could be used not only to cross syscall boundary (variant 1 and variant 2) but also guest/host boundary (variant 2).
BTW; The new ARM Cortex-A75 have all of these problems.
Posted on Reply
#69
lexluthermiester
Manu_PT said:
AMD has the Spectre problem which isn't 1/10 as bad as meltdown. Don´t spread misinformation.
Actually, that statement is misinformed. Meltdown is solved with a software fix. Spectre is a vulnerability in all hardware platforms and can be exploited many different ways. It's far more dangerous and far more serious.
Manu_PT said:
Meltdown is the real problem here, Spectre is just another threat like 10000 others, and you need physical access to the machine first, to use it.
Sorry, that's also incorrect. Like most other forms of malicious code, Spectre is remotely exploitable.
Posted on Reply
#70
trparky
piloponth said:
Has been Intel's CEO sued for insider trading yet? Or once again rule "too big to fail" applies?
As long as he informed the SEC that he was going to sell his stock it's not Insider Trading, it's perfectly legal to do so. Now had he sold his stock and did not inform the SEC then yes, it would be Insider Trading. That's what happened to Martha Stewart a couple of years ago, she didn't inform the SEC and got thrown in jail.
Posted on Reply
#71
I No
trparky said:
As long as he informed the SEC that he was going to sell his stock it's not Insider Trading, it's perfectly legal to do so. Now had he sold his stock and did not inform the SEC then yes, it would be Insider Trading. That's what happened to Martha Stewart a couple of years ago, she didn't inform the SEC and got thrown in jail.
While the 10b5-1 is a way to counter insider trading all sells of stocks is submitted via a SEC form 4 so everything he did was public knowledge and SEC knew about this. The thing SEC didn't know about was the "flaw" that Google dug up because it wasn't meant to be public.
Posted on Reply
#72
lexluthermiester
I No said:
While the 10b5-1 is a way to counter insider trading all sells of stocks is submitted via a SEC form 4 so everything he did was public knowledge and SEC knew about this. The thing SEC didn't know about was the "flaw" that Google dug up because it wasn't meant to be public.
trparky's right, This doesn't qualify as insider trading. The reality is Intel did not know how serious this was until after the sale, and even if they did, it would have to be proved that there was a connection. For all anyone else knows it could have been a personal reason motivating the sale. People like us don't have all the details and therefore can not make informed conclusions.
Posted on Reply
#73
Devon68
Speculation "If this didn't reach the public would the public know after they resolved it"?
Posted on Reply
#75
efikkan
Devon68 said:
Speculation "If this didn't reach the public would the public know after they resolved it"?
Intel regularly updates their errata, just look at this long list for skylake.
A lot of small bugs are normal for CPUs, if they fixed it "silently", nobody would have noticed it in the list.
Posted on Reply
Add your own comment