Intel CPUs Released in Last 8 Years Impacted by New Zombieload Side-Channel Attack (zdnet.com) 149
Academics have discovered a new class of vulnerabilities in Intel processors that can allow attackers to retrieve data being processed inside a CPU. From a report: The leading attack in this new vulnerability class is a security flaw named Zombieload, which is another side-channel attack in the same category as Meltdown, Spectre, and Foreshadow. Just like the first three, Zombieload is exploited by taking advantage of the speculative execution process, which is an optimization technique that Intel added to its CPUs to improve data processing speeds and performance. For more than a year, academics have been poking holes in various components of the speculative execution process, revealing ways to leak data from various CPU buffer zones and data processing operations. Meltdown, Spectre, and Foreshadow have shown how various CPU components leak data during the speculative execution process.
Today, an international team of academics -- including some of the people involved in the original Meltdown and Spectre research -- along with security researchers from Bitdefender have disclosed a new attack impacting the speculative execution process. This one is what researchers have named a Microarchitectural Data Sampling (MDS) attack, and targets a CPU's microarchitectural data structures, such as the load, store, and line fill buffers, which the CPU uses for fast reads/writes of data being processed inside the CPU. [...] In a research paper published today, academics say that all Intel CPUs released since 2011 are most likely vulnerable. Processors for desktops, laptops, and (cloud) servers are all impacted, researchers said on a special website they've set up with information about the Zombieload flaws.
Today, an international team of academics -- including some of the people involved in the original Meltdown and Spectre research -- along with security researchers from Bitdefender have disclosed a new attack impacting the speculative execution process. This one is what researchers have named a Microarchitectural Data Sampling (MDS) attack, and targets a CPU's microarchitectural data structures, such as the load, store, and line fill buffers, which the CPU uses for fast reads/writes of data being processed inside the CPU. [...] In a research paper published today, academics say that all Intel CPUs released since 2011 are most likely vulnerable. Processors for desktops, laptops, and (cloud) servers are all impacted, researchers said on a special website they've set up with information about the Zombieload flaws.
seems like it's Intel only,... (Score:5, Informative)
"Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities. AMD and ARM chips are not said to be vulnerable like earlier side-channel attacks."
source: https://techcrunch.com/2019/05... [techcrunch.com]
Re: (Score:2)
Re:seems like it's Intel only,... (Score:4, Informative)
While I _have_ asked myself whether buying AMD gave me an overall worse result in the past, it is now amply clear where Intel got that extra performance: Really bad design trade-offs.
Looking forward to buying a zen-2 later this year!
Re: (Score:2)
While I _have_ asked myself whether buying AMD gave me an overall worse result in the past, it is now amply clear where Intel got that extra performance: Really bad design trade-offs.
Looking forward to buying a zen-2 later this year!
I thought about that too, but only for tiny fractions of a second. Then I always remembered that I paid less per performance, and didn't care enough about performance to set up a Beowulf cluster. So I must have made the right choice.
Re: (Score:2)
Then you haven't seen how badly recent AMDs are crippled. I own a Zen+ Threadripper (the big one: 2990WX), and all communication between quarters of the processor (it's split into four pieces, 8 cores 16 HT each) goes through a narrow pipe that's 15GB/s total. You can't even access L3 cache faster than that! So the external PCIe bandwidth that's impressive on paper (63GB/s -- 64 PCI3.0 lanes) is of no real use as the processor can't consume or return data fast enough. Half of the cores (NUMA nodes 1 and
Re: (Score:2)
And which Intel product are you comparing it against? How's the price per performance, when patching against the known vulnerabilities?
Also, the Threadripper performance does depend a lot on the use case. In some cases, a 2700x will beat them, but in some cases the Threadripper wipes the floor with those. I think it's always a good idea to check the benchmarks for the particular use case(s) one plans to use the product, and make the decision based on those (of course thinking about performance per cost and/
Re: (Score:2)
That is complete nonsense. You do never use all those PCI-E lanes at once.
Re: (Score:2)
Really bad design trade-offs.
Nope. Just design trade-offs. The risk profile actually makes these relevant and good design trade-offs which renders Intel processors unsuitable for only a small minority of workloads.
Personally I run AMD, but I don't pretend that this is somehow related to security.
Re: (Score:2)
And you realize that without giving specifics and posting as AC you have zero credibility?
Re: (Score:2)
Goes back further than that. It even affects Penryn chips (and there's no microcode update planned for them).
I'm fed up with Intel (Score:5, Interesting)
AMD cheerleading (Score:2, Insightful)
My next laptop will probably be AMD.
Yeah yeah there always are people who think it really matters somehow. What leads you to believe that their stuff is in any way more secure? Nothing against AMD but I see no reason to believe nor any evidence that their processors are provably more secure than Intel's. Use AMD if you like their products but I think it's naive to think they don't have their own bugs and security issues.
Re:AMD cheerleading (Score:4, Insightful)
Re: (Score:1)
AMD isn't ideal in regards of security but they have somewhat fewer known issues and AMD spectre type bugs are less severe, the applications can't read kernel memory, only the user mode memory. AMD is just the lesser of two evils. .
Yes, fewer KNOWN issues. Do these researchers put the same time and resources into exploiting AMD chips? Or are they focusing on Intel because there are so many more of those out there, and that's why the Intel vulnerabilities are being found?
Re: (Score:2)
Re: (Score:2)
My guess yes they do probably put the effort into AMD chips because guess what EPYC is pretty darn popular for cloud hosts and big virtualization farms.
Intel might have more market there but AMD has a pretty darn big presence in the market place where the really really valuable targets live. Certainly big enough to attract the attention of both black hats and white hats.
The reality is AMD does have some important architectural differences that are serving them well with regard to both these side channel, c
Re: (Score:3)
Yes, fewer KNOWN issues. Do these researchers put the same time and resources into exploiting AMD chips? Or are they focusing on Intel because there are so many more of those out there, and that's why the Intel vulnerabilities are being found?
Guess you haven't been paying attention to these issues at all. Remember how some Intel-related researchers in Israel reported AMD's vulnerability to some of these exploits? And how they exaggerated it? You can bet your ass that Intel themselves continues to look for vulnerabilities in AMD processors, but yes, there are lots of people looking for vulnerabilities in both, and ARM processors as well. Finding such a vulnerability is an instant road to some small publicity. Also, even if the original researcher
Re: (Score:2)
AMD spectre type bugs are less severe
I live in a part of the world that is far from the equator, it makes meteor strikes killing me far less likely as there's more atmosphere to burn through.
Picking AMD for security in any general purpose, especially a laptop, is making a similar decision. I'm willing to bet you never analyse the risk of any other part of your life down to this level.
Re: (Score:2)
Re: (Score:3)
All those bugs are related to AMD "secure processor". They need administrative access to exploit. That access is not typically available not even in virtual machines. They are a smaller problem than Spectre or Meltdown.
Masterkey, Ryzenfall, and Fallout are firmware bugs (not CPU bugs).
Re: (Score:2)
and AMD has its own vulnerabilities, namely RyzenFall, MasterKey, Fallout and Chimera.
Are you talking about those overblown bugs from that shill "security" company?
Re: (Score:2)
Re: (Score:2)
There is a difference when an error is published for Intel CPUs but not for AMD CPUs. You are slightly better with an AMD CPU because more effort needs to be put into the exploit code for them. The additional effort may make it not profitable to attack.
It is likely something similar exists for AMD processors. But will black hats bother to develop it? You have definitely ruled out at least all the low level attackers for now.
Re:AMD cheerleading (Score:4, Informative)
AMD CPUs are architected differently than Intel. Though AMD and almost everyone else with a speculative execution engine were susceptible to several variants of the Spectre exploits there were several that were also Intel only, including possibly this variant.
Most of the Intel-only Spectre exploits were sloppy design that was meant to increase speed at the expense of security. Meltdown was a perfect example of this where AMD and ARM did the right thing at the expense of speed. To me the Spectre exploits have proved this without a doubt, Intel processors simply aren't safe until they change this design methodology and there is no evidence they have. They are doing what microsoft did in the 90's, trying to paper over the mistakes without changing the methodology of development.
Speed at any cost, including security is stupid when almost every computer in the world is running code (JS) off the internet. Most of the Spectre variants can be executed from within a browser javescript sesion and that should scare the crap out of everyone. Do you trust every Javascript your computer executes?
Re: (Score:3)
Meltdown was a perfect example of this where AMD and ARM did the right thing at the expense of speed.
Some ARM processors are vulnerable to both meltdown and spectre.
Re: (Score:2)
This is one of those things that seems to be "true," except there is a big lie hidden in the middle.
If you gave the context, it would clearly be an irrelevant edge case, but you left out the context; and you have to know that context, and a bunch of details, to be making the claim you're making.
So on a scale of "true" to "horse shit," this is clear horse shit.
I'm sure you'll defend it anyways; but you sure as fuck won't teach the controversy, because if you did, your comment would clearly be shit.
Re: (Score:2)
Some ARM processors are vulnerable to both meltdown and spectre.
Where is the lie?
If you gave the context, it would clearly be an irrelevant edge case,
It is very far from irrelevant. All A75 cores are vulnerable to MELTDOWN, which proves that ARM pulled the same kind of nefarious bullshit as Intel for performance reasons. They are not remotely trustworthy.
Re: (Score:2)
Most of the Intel-only Spectre exploits were sloppy design that was meant to increase speed at the expense of security. Meltdown was a perfect example of this where AMD and ARM did the right thing at the expense of speed.
You mean where Intel did the right thing at the expense of security. The risk posed by Spectre and Meltdown is virtually non-existant for the vast majority of computer use cases.
To me the fact that you live in a house and don't hide away in a bank vault all your life is evidence to me that you only take security seriously when talking on online forums, and not in real life.
Hypocrite.
AMD FTW! (Score:4, Interesting)
Re: AMD FTW! (Score:1)
Even better... I haven't replaced my computer in more than 8 years!
Re: (Score:3, Interesting)
slow down, cowboy!
I bought (and had to return!) an amd 1700 system due to a glaring bug that was a show stopper. any high load work (make -j16) would cause either silent corruption or seg faults during gcc.
I bought this JUST as a build server. 100% untrustable ;(
its not all amd cpus (threadripper is ok, it seems) but you have to be careful with WHICH amd you buy, now. I won't go back again, it was a horrible experience and I wasted 2 weeks trying to get that build server reliable. no fix in sight. amd
Re: (Score:3)
While it IS possible that you hit a buggy CPU, faulty RAM is vastly more likely. That affects Intel and AMD equally.
You should be complaining to your server vendor, not to AMD.
Re: (Score:2)
no, it was not ram.
if you search enough, you'll find lots of articles on the cpu series the 1700 was from. it was a 65w 16 thread cpu, and my interest was to run it fanless with heatpipes (my current 65w i7 needs replacing, as I would have preferred -j16 to -j4 or -j8).
nothing to do with chipset or mobo or video or nvme ssd.
it was all about the cpu.
as was posted, if you returned your cpu, amd would send you another but some users still had issues. I could not afford that much time to sort this out.
Re: (Score:2)
It sounds like you bought a crap motherboard and were overheating something and it didn't notice.
CPU returning inconsistent results would be a major headline, there is no fucking way that happened and that you actually traced your problem to that. You can search "AMD 1700 bug" and you do find a compiler bug where Rizen 1700 CPUs from the first 25 weeks of production caused segfaults on some compiler jobs. So if you really did hit a CPU bug, this is more likely what it was, and your build system had some lef
Re: (Score:2)
amd would send you another but some users still had issues.
Are you saying ryzentest would fail on the replacements? That's the first I've heard of this.
Re: (Score:2, Informative)
There was an issue with AMD cpu's when they first launched where high cpu load while compiling the linux kernel would cause errors. These CPU's can be RMA'd to get a fixed one and since then the original issue has been resolved.
I tried to look up a supporting article but all I can find are the ones complaining about the issue, sorry.
Re:AMD FTW! (Score:4, Insightful)
I bought (and had to return!) an amd 1700 system due to a glaring bug that was a show stopper. any high load work (make -j16) would cause either silent corruption or seg faults during gcc.
I had the same bug and AMD replaced CPU for free. Got a brand new CPU shipped to me with advanced replacement and returned mine after installing it. No issues since.
Re: (Score:2)
From what I heard it was only an early production that had the flaw. They've fixed it since.
But your point stands. AMD can't throw the first stone.
Still took them quite a few months to publicly accept that their early batch had a big flaw.
And I got burnt by buying a first generation dual Opteron 2xx system (that was a bit before Athlon64x2 existed) which didn't work properly in dual sockets. They were supposed to work but there was an inter-cpu cache coherency bug that randomly corrupted memory.
This time ar
Re: (Score:2)
Define "better". Slower single threaded performance. Lack of vPro management features, and given the complete non-issue these side channel attacks present you're not going to win over the corporate world.
Re: (Score:2)
The Chromium team has opted to disable hyperthreading in 74 and look for more options 75 and beyond.
https://www.chromium.org/Home/... [chromium.org]
Back to 6502s (Score:5, Interesting)
Re: Back to 6502s (Score:2)
The 6502 is vulnerable to fixed address stack space attack between $0100 and $01FF.
Lets go back to Zilog Z80 instead!
Re: Back to 6502s (Score:4, Informative)
It's also subject to a trivial timing attack: Memory accesses to addresses below 0x100 are significantly faster than other addresses, and these faster addresses are usually the ones that hold important OS variables.
By searching for memory that loads faster, you can pinpoint the most important information in a 6502 system.
Re: (Score:1)
Mmmmm. Z80. I have one around here someplace hooked up to a 1 MHz clock chip and I think 64K worth of memory. Wire wrap computer.
Probably still works with whatever I had on the eeprom last.
Re: (Score:2)
false, Ultrasparc, Itanium, Some ARM Cortex, Risc-V are not.
Re: (Score:2)
Re: (Score:2)
the last generation just came out (which had nothing different than prior generation other than clock speed improvement) and orders for machines will be taken on Jan 2020
so, yeah, it's almost dead
Re: (Score:2)
false, Ultrasparc, Itanium, Some ARM Cortex, Risc-V are not.
False. Ultrasparc is vulnerable to SPECTRE.
Re: (Score:2)
it's the the oracle T4 and newer that has vulnerability if firmware update not applied. The older CPU don't have the speculative architecture to exploit.
Do I have this right? (Score:2, Troll)
1) There seems to be a near-endless stream of serious vulnerabilities affecting the vast majority of CPUs.
2) Many of these are fundamental flaws, where best-effort patches can only mitigate, not fix.
3) If you are on a cloud server, there is no way to tell from within the virtual environment how vulnerable the system is, short of trying to find exploits yourself, which would be a felony.
4) We are years away from seeing CPUs that don't have these vulnerabilities coming into the market.
5) Hordes of companies a
Re: (Score:3)
For people doing tasks where this sort of security actually matters (probably mostly government and military), they can switch to hardware which doesn't have the vulnerability but is slower. Or run t
Re: (Score:2)
Re: (Score:2)
Or the Russians. Or the Chinese. Or the Iranians. Or the French. (Just thought Iâ(TM)d throw them in there.) Or the [fill in the blank]. Then suddenly, you might just matter.
Yeah, the whole "you're not important" argument has been bullshit essentially since the invention of the computer, and the adoption of computerized records and communications. Suddenly, it's become cheap to spy on everyone — and to attack everyone. Nobody is going to spend any money on plebs except when given a reason to do so, but now they don't have to spend any money to hack you and spy on you.
Re: (Score:2)
I find it all so tiresome. It's the endless search for ultimate security vs.the constant pressure to reduce costs.
I also wonder -- let's say Intel really wanted to find these exploits -- how much would just finding them cost? I'm presuming that the super smart people who design CPUs actually don't want killer exploits, and actually give an E for Effort when designing CPUs in the hope of avoiding them, meaning that finding these bugs is hard, or at least hard until the first one is found.
Since many of thes
Potentially a major performance issue (Score:4, Informative)
Re: (Score:2)
Incorrect Headline (Score:2)
Re:Does this still require root? (Score:5, Informative)
What are you talking about? Spectre and Meltdown don't require root. In the paper there's a Javascript exploit. As in on a web page.
Re:Does this still require root? (Score:5, Insightful)
And of course we're now at a point where websites are basically cross-linked Javascript Hell.
I've run plugins for the mass-disabling and select re-enabling of Javascript, Flash, and others, and it's gotten extremely difficult to use the Internet with these plugins with the festering ecosystem that is Javascript.
Re: (Score:2)
it's gotten extremely difficult to use the Internet with these plugins with the festering ecosystem that is Javascript.
You could always stop using the internet and have fun in this new fangled thing called... real life. It doesn't run on JavaScript so it should suit your personal preferences nicely. Cheers!
Ok... then why aren't we seeing exploits (Score:2)
I admit I haven't followed it that closely, but something missing. Like I said, if there was a 'sploit that hit 80% of PCs and could let you run arbitrary code by serving up JavaScript I wouldn't be typing this, my computer would have been pwned 8 ways from Sunday.
Re:Does this still require root? (Score:4, Insightful)
And what does it get you? A random dump of some memory contents which are completely variable on any system. Whoop de fucking do. You going to dump all 16GB of RAM over the internet and then look through it finding my 1024bit encryption key?
The GP was wrong that you require root, what you actually require is shell access for a long time in an attempt to characterise and categorise the system in order to plan a detailed complicated and targetted attack. Having anything short of complete access to a system running on the hardware (e.g. a co-located VM) makes Spectre / Meltdown completely irrelevant in terms of general purpose computing. If you're a cloud provider then be worried, if you're anyone else in the entire world then don't go taking out insurance policies against meteor strikes. You have far bigger concerns.
I'm just going to send some idiot admin a phishing email. Far more effective.
Re: (Score:2)
There's a difference between underestimating requirements for a function, and recognising that there is a far more efficient way of achieving a goal. If you could passively send all your RAM contents over the internet without knowledge of your victim in an easy way Spectre still wouldn't make any sense outside of a very specific and very sophisticated targeted attack.
Re:Does this still require root? (Score:5, Informative)
Meltdown let you read the entire system memory, including all private information on the system, and you didn't need anything like Root to do that.
I'm still skeptical about Spectre being a risk, since it only affects scripts on webpages getting access to the browser's memory for that process. Just put the sensitive information into another process, and you're all mitigated.
Re: (Score:2)
Meltdown let you read the entire system memory, including all private information on the system, and you didn't need anything like Root to do that.
And what are you going to do with it? If you know my encryption key then you don't need to scan my memory to find it. If you don't know then are you going to ex-filtrate 16GB and hope for good luck?
Unless you're running a co-located VM and are interested in attacking another VM Spectre and Meltdown are 100% irrelevant to the consumer. No one, and I mean no one would go through the effort of using these attacks if there are thousands of easier to execute attacks you can use. There's a good reason no practica
Re: (Score:2)
and if an attacker already has your system infected
I stopped reading there.
Re: (Score:2)
I may retort to your vague statement with some witty reply, but I'm not actually going to give you anything meaningful. But trust me, you just got burned, you'll just have to take my word for it.
Re: (Score:3)
Re: (Score:3)
Or predict the malloc for keys, sniff and parse, and the machine is yours. Either attack can be potentially a can opener.
How the attack finds its way to a machine is somewhat moot-- if it gets there, it can work, then go to work delivering the goods.
This is why network traffic analyzers and parses will prove to be crucial, along with zero-trust models. Why? We'll forever need to watch for anomalous traffic as hints that ANY Intel machine has been breached.
Re: (Score:2)
We'll forever need to watch for anomalous traffic as hints that ANY Intel machine has been breached.
Thankfully, I'm in the position of not having any Intel processors. I do have a vulnerable ARM though (in the Pine64). But regardless of that, we should be doing that anyway, because that sort of thing is the only way to guard against 0-days.