Researchers Discover Seven New Meltdown and Spectre Attacks

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
Seven new Meltdown and Spectre attacks affecting AMD, ARM, and Intel CPUs were revealed by researchers this week. These include Meltdown-BR, which exploits an x86 bound instruction on Intel and AMD processors, and Meltdown-PK, which bypasses memory protection keys on Intel CPUs. ARM and Intel have already acknowledged the researchers’ findings.

Researchers say they've discovered the seven new CPU attacks while performing "a sound and extensible systematization of transient execution attacks" -- a catch-all term the research team used to describe attacks on the various internal mechanisms that a CPU uses to process data, such as the speculative execution process, the CPU's internal caches, and other internal execution stages. The research team says they've successfully demonstrated all seven attacks with proof-of-concept code.
 
Seven new Meltdown and Spectre attacks affecting AMD, ARM, and Intel CPUs were revealed by researchers this week. These include Meltdown-BR, which exploits an x86 bound instruction on Intel and AMD processors, and Meltdown-PK, which bypasses memory protection keys on Intel CPUs. ARM and Intel have already acknowledged the researchers’ findings.

Researchers say they've discovered the seven new CPU attacks while performing "a sound and extensible systematization of transient execution attacks" -- a catch-all term the research team used to describe attacks on the various internal mechanisms that a CPU uses to process data, such as the speculative execution process, the CPU's internal caches, and other internal execution stages. The research team says they've successfully demonstrated all seven attacks with proof-of-concept code.
Holy crap. So what is the running count for each cpu? Did Intel or AMD fix any of them with their new cpu's that came out or just fixes that slow it down?
 
Spectre and Meltdown, the gifts of Christmas past that keep on giving for the whole year.

Holy crap. So what is the running count for each cpu? Did Intel or AMD fix any of them with their new cpu's that came out or just fixes that slow it down?
AMDs event for 7nm Epyc apparently has hardware fixes.
 
Looks like I'm never going to get a fix for the Spectre/Meltdown stuff on my 4790k as its up to mobo manufacturers to release the fixes via a bios update and Gigabyte isn't doing that for any of its boards unless they are Z170 or newer...
 
All of my CPU's are covered with tin foil. Neither Spectre or Meltdown is getting trough. The so called reaserchers and "Quackademia" needs to focus on issues that are slightly more pressing than the fake and meaningless shit they come up with.
 
All of my CPU's are covered with tin foil. Neither Spectre or Meltdown is getting trough. The so called reaserchers and "Quackademia" needs to focus on issues that are slightly more pressing than the fake and meaningless shit they come up with.


you clearly don't do anything really important with your systems
 
Important enough that its supporting me. We all have a choice in what we believe is true :D
 
you clearly don't do anything really important with your systems
Yeah, some do not. I know I do. I game and browse. Pretty important to me stuff. :)

I wonder if they have bios fixes? Already a reduction in performance from OS level and BIOS level fixes. I did update my BIOS, bit for the other small things it does.
 
Something that would eliminate this issue would be to have software contained in fully isolated VMs. That would also eliminate a lot of crashing problems, in that the software would not be able to have any libraries that overlap with other software, causing crashes on other software. Of course, this would also eliminate a lot of software that is put out as an addon to another program. (I've always hated that. Salesforce, for example, at least started as an addon to Outlook and MS Office, and completely failed to function reliably back in 2005-2006 and I was working with it. Shoretel's phone software did the same, and was absolutely horrible as well.) Perhaps these kind of vulnerabilities will finally convince people to develop software in a manner that is it completely isolated and contained so it doesn't step on other programs and can't get stepped on.
 
I just slapped another layer of this time name brand tin foil. Im pretty sure im double protected even for the upcoming yet not discovered crap. lol …:D
 
Something that would eliminate this issue would be to have software contained in fully isolated VMs. That would also eliminate a lot of crashing problems, in that the software would not be able to have any libraries that overlap with other software, causing crashes on other software. Of course, this would also eliminate a lot of software that is put out as an addon to another program. (I've always hated that. Salesforce, for example, at least started as an addon to Outlook and MS Office, and completely failed to function reliably back in 2005-2006 and I was working with it. Shoretel's phone software did the same, and was absolutely horrible as well.) Perhaps these kind of vulnerabilities will finally convince people to develop software in a manner that is it completely isolated and contained so it doesn't step on other programs and can't get stepped on.

Hey I use Salesforce at work! Its actually one of the more reliable systems now.
 
Jeez. More and more it seems like the end of virtual private servers is here. With all these exploits, who would use one?

It seems to me like the new paradigm is that everything has access to everything else if it resides on on same bare metal server.

Good bye virtualization. We hardly knew ye.
 
Jeez. More and more it seems like the end of virtual private servers is here. With all these exploits, who would use one?

It seems to me like the new paradigm is that everything has access to everything else if it resides on on same bare metal server.

Good bye virtualization. We hardly knew ye.

The trendy cloudy fellas!
 
Not cool. Image often and have a strict re-image policy before adding in new software and then after.
 
Something that would eliminate this issue would be to have software contained in fully isolated VMs. That would also eliminate a lot of crashing problems, in that the software would not be able to have any libraries that overlap with other software, causing crashes on other software. Of course, this would also eliminate a lot of software that is put out as an addon to another program. (I've always hated that. Salesforce, for example, at least started as an addon to Outlook and MS Office, and completely failed to function reliably back in 2005-2006 and I was working with it. Shoretel's phone software did the same, and was absolutely horrible as well.) Perhaps these kind of vulnerabilities will finally convince people to develop software in a manner that is it completely isolated and contained so it doesn't step on other programs and can't get stepped on.

Do you realize how wrong you are here. A key component of some of the... specter or was it meltdown vulnerabilities is exploiting the speculative execution to access hardware level memory addressing and read what is in memory. This means a system running in a VM that is compromised can read what is happening in memory on other guests on the same host.

So your trick of different VM's is specifically bypassed by what these vulnerabilities allow. If your local VM administrator is telling you otherwise they haven't bothered to educate themselves... OR they have already patched their systems to address known vulnerabilities with their Hypervisor provider.

That is what makes these vulnerabilities so specifically dangerous.

If you want to go into more detail around these I can explain more and why cloud vendors specifically HATE these vulnerabilities.
 
that's why you just subscribe to whatever enterprise offers, then sue them if it gets broken. ( i mean, if you are a customer that is)

now if only legislators can churn out a law to protect ordinary consumers.
 
There are 174 ways someone can break into your house. Still you don't burn it down and move into a cave.

The question is not how many ways are there to break in, but how likely is a break-in to occur.
 
AMDs event for 7nm Epyc apparently has hardware fixes.

Researchers found that current fixes for Spectre can be bypassed and (as I suggested many months ago) AMD is not invulnerable to Meltdown:

We also debunk implicit assumptions including that AMD processors are immune to Meltdown-type effects, or that serializing instructions mitigate Spectre Variant 1 on any CPU
 
Looks like I'm never going to get a fix for the Spectre/Meltdown stuff on my 4790k as its up to mobo manufacturers to release the fixes via a bios update and Gigabyte isn't doing that for any of its boards unless they are Z170 or newer...

You might find this usefull: VMware CPU Microcode Update Driver
Applies to Windows 7 and 8 but NOT Win 10. Microsoft is pushing some microcode updates / mitigation via windows 10 updates.

And some other relevant links:
 
Jeez. More and more it seems like the end of virtual private servers is here. With all these exploits, who would use one?

It seems to me like the new paradigm is that everything has access to everything else if it resides on on same bare metal server.

Good bye virtualization. We hardly knew ye.


Everyone, because most people do not care about this stuff or even know about it. MS, AWS are not just going to up and shut down because of this stuff
 
Do you realize how wrong you are here. A key component of some of the... specter or was it meltdown vulnerabilities is exploiting the speculative execution to access hardware level memory addressing and read what is in memory. This means a system running in a VM that is compromised can read what is happening in memory on other guests on the same host.

So your trick of different VM's is specifically bypassed by what these vulnerabilities allow. If your local VM administrator is telling you otherwise they haven't bothered to educate themselves... OR they have already patched their systems to address known vulnerabilities with their Hypervisor provider.

That is what makes these vulnerabilities so specifically dangerous.

If you want to go into more detail around these I can explain more and why cloud vendors specifically HATE these vulnerabilities.

You do realize that VMware's ESXi is completely invulnerable to these because of how it has handled VMs from its inception, as well as VirtualBox, right? It would not be a problem for VMs if the hypervisor is developed right from the start.
 
You do realize that VMware's ESXi is completely invulnerable to these because of how it has handled VMs from its inception, as well as VirtualBox, right? It would not be a problem for VMs if the hypervisor is developed right from the start.

You are incorrect. They specifically had to patch these out. How do I know... the five different ESXi Clusters I am responsible for. Whomever told you they haven't been vulnerable to these was incorrect. Even the latest hyperthreading sidechannel vulnerability required that you both patch (included in 6.5 u2, and turn on an option due to potential performance impact of the vulnerability.)

You are completely wrong here. They have not 'been invulnerable from the start' unless you started with 6.5 u2 or higher. AND are running a current BIOS. (edited to add the AND statement. Wouldn't want to be remiss and only give you a half solution.)

Next time you might want to double check your sources.

Here is a link to the Vmware kb article discussing the patches JUST IN CASE you are responsible for some ESXi hosts and didn't bother to do any actual research.

https://kb.vmware.com/s/article/52491?lang=en_US

Thank you have a nice day.

Also if you can't be bothered to do a modicum of research please stop posting things like this that are blatantly incorrect. You might actually cause a system administrator to think. 'Oh, ok cool I'm good some guy on a forum I trust said so.'
 
Last edited:
Researchers found that current fixes for Spectre can be bypassed and (as I suggested many months ago) AMD is not invulnerable to Meltdown:

So with new knowledge, and a completely new type of attack, that means you "knew AMD was vunerable as you suggested many months ago"...Yet, you, nor anyone else, could prove that meltdown had any affect on AMD products...You just crack me up man. You should consider a career in standup..You will be your biggest fan. :ROFLMAO::ROFLMAO::ROFLMAO::ROFLMAO::ROFLMAO:

It is going to be interesting to see how much moar performance is lost with the OS and BIOS level hack job defenses are...Cannot wait for Zen2!
 
It is going to be interesting to see how much moar performance is lost with the OS and BIOS level hack job defenses are...Cannot wait for Zen2!

There's bound to be some type of vulnerability in Zen2 that is just waiting to be discovered down the road.
 
There are 174 ways someone can break into your house. Still you don't burn it down and move into a cave.

The question is not how many ways are there to break in, but how likely is a break-in to occur.

I get what your saying but my state has a castle law. There may be 174 ways of getting in my house but only one way of getting out.
 
All of my CPU's are covered with tin foil. Neither Spectre or Meltdown is getting trough. The so called reaserchers and "Quackademia" needs to focus on issues that are slightly more pressing than the fake and meaningless shit they come up with.

Is that you Comixbooks?
 
So with new knowledge, and a completely new type of attack, that means you "knew AMD was vunerable as you suggested many months ago"...Yet, you, nor anyone else, could prove that meltdown had any affect on AMD products...You just crack me up man. You should consider a career in standup..You will be your biggest fan. :ROFLMAO::ROFLMAO::ROFLMAO::ROFLMAO::ROFLMAO:

Hahahaha!

When Meltdown was discovered. AMD claimed that Zen was invulnerable to Meltdown attacks, and researchers said something different:

At the moment, it is unclear whether AMD processors are also affected by Meltdown

What happened is that their specific vector of attack was only successful on Intel hardware, but modifying the attack could probably affect AMD CPUs as well. Nothing in Zen muarch really prohibited Meltdown attacks to work and researchers proved that a toy model they developed worked on both ARM and AMD. So my point, in older threads devoted to this topic, was that the invulnerability of AMD to Meltdown attacks was far from unproven... and new research just confirms they are affected.
 
IMO - the search for attack vectors in the hardware is just getting started.
The university I am at is flourishing with students looking into hardware exploits and staff as well right now. It is kind of the wild west that no one took a close look at until recently. The research is just finally getting into the right motivated people.
 
Hahahaha!

When Meltdown was discovered. AMD claimed that Zen was invulnerable to Meltdown attacks, and researchers said something different:

Actually it's still the same. The Meltdown/Spectre types that were revealed back then are still Intel only. (some ARM)

Intel has done well by spiting its tables to mitigate a lot of cross privilege exploits.

What happened is that their specific vector of attack was only successful on Intel hardware, but modifying the attack could probably affect AMD CPUs as well. Nothing in Zen muarch really prohibited Meltdown attacks to work and researchers proved that a toy model they developed worked on both ARM and AMD. So my point, in older threads devoted to this topic, was that the invulnerability of AMD to Meltdown attacks was far from unproven... and new research just confirms they are affected.

Welcome to monday morning hyperbole.

These are new attacks and do not cross privilege level and of these only the bound instruction works on AMD. This is for same or very near address space.

Guess what bound isn't valid for 64bit programs.

So 7 v 1 total. Cross Privilege exploits 4 v 0.
 
Last edited:
Actually it's still the same. The Meltdown/Spectre types that were revealed back then are still Intel only. (some ARM)

Intel had done well by spiting its tables to mitigate a lot of cross privilege exploits.



Welcome to monday morning hyperbole.

These are new attacks and do not cross privilege level and of these only the bound instruction works on AMD. This is for same or very near address space.

Guess what bound isn't valid for 64bit programs.

So 7 v 1 total. Cross Privilege exploits 4 v 0.

Ssssh, stop with facts. It makes him have to work overtime.
 
I got a new meltdown and specter attack I found... brake into someone's house and steal their drives and PC. Works on every system no one is safe.
 
Back
Top