Intel impacted by SWAPGS vulnerability

Gideon

2[H]4U
Joined
Apr 13, 2006
Messages
3,522
Report from OC3D that Intel has been informed of a new speculative attack on their cpu and will be software mitigated by Microsoft.

Intel Impacted by new SWAPGS Speculative Execution Attack
Researchers over at Bitdefender have uncovered a new side-channel attack which impacts Intel x86 processors. This new Speculative Execution attack is called SWAPGS, and has been designated the CVE-2019-1125 name.

Bitdefender has claimed that it has "worked with Intel for more than a year" before publically disclosing this new attack, stating that "the SWAPGS Attack affects newer Intel CPUs that use speculative execution". Red Hat has additionally claimed that vulnerability applies to x86-64 systems which use "either Intel or AMD processors".

SWAPGS allows attackers to gain access to information that's stored in kernel memory, which could extend to passwords, encryption keys and other pieces of important information. This vulnerability is said to only be available to local attackers, with the Linux OS being considered more secure from the vulnerability than Windows.

Users of Windows 10 should update their OS to ensure that their systems remain secure. On July 9th, Microsoft released an OS update that's designed to mitigate the effects of SWAPGS by changing how processors speculatively access memory.

AMD has responded to the reveal of SWAPGS with the following statement, claiming that they believe that their processors are not vulnerable to SWAPGS.

https://www.overclock3d.net/news/cp..._by_new_swapgs_speculative_execution_attack/1
 
At this point, I figure when they start to produce a real, significantly different and new architecture. As fast as the 4c 8t processors where, especially the 6700K, now we know at least in part it was because they were cutting corners to get there.
Power9?
 
So what's the tally now? My old man is on Windows 7 with a Sandy Bridge CPU and Z68 motherboard. Last I checked it still didn't have an updated BIOS for meltdown/spectre mitigation.
 
I understand the "AMD isn't as big of a target" argument, and there may be some merit to this; however, they're making x86 CPU's too.... and I find it dubious that the mitigation required also HAPPENS to have a significant impact on performance.....

If I were a Sandy/Ivy Bridge customer and I purchased an expensive CPU for which I now must disable hyperthreading or some other mitigation killed performance in my applications, I would be really effing pissed off.

Why? Because Intel is Facebooking its customers... 5+ years after the sale there is this HUGE "gotcha" or series of "gotchas" that springs out of the bushes. You trusted this company the whole time, only to realize that your trust was misplaced and their negligence put you/your company at risk.

IMO if you're doing the buying for a company and you are still buying Intel CPU's you are doing it wrong and you should be fully ready to accept whatever security vulnerabilities you get hit with going forward. This should be part of your disaster recovery plan.

The Facebook equivalent is "surprise! we've been selling your personal information to everyone on the planet! you are now compromised!"
 
I love how they make a big deal out of all these vulnerabilities that require physical access to the affected machine. Unless you're a target of corporate espionage then it's not that big a deal.

Kinda wrong there. Drive by browser exploits are a thing. Add a privesc and you are pwnd. All of these speculative execution exploits can be used to privesc.
 
What do we anticipate would be the most obvious attack vector/s?

I've seen a few people mention (here and elsewhere) that "physical access" is required, but the terminology is a bit different in the IS world. Does "local access" mean the attacker needs to be physically at the machine, or that they need local admin rights?
 
What do we anticipate would be the most obvious attack vector/s?

I've seen a few people mention (here and elsewhere) that "physical access" is required, but the terminology is a bit different in the IS world. Does "local access" mean the attacker needs to be physically at the machine, or that they need local admin rights?
^^^
 
I understand the "AMD isn't as big of a target" argument, and there may be some merit to this; however, they're making x86 CPU's too.... and I find it dubious that the mitigation required also HAPPENS to have a significant impact on performance.....

If I were a Sandy/Ivy Bridge customer and I purchased an expensive CPU for which I now must disable hyperthreading or some other mitigation killed performance in my applications, I would be really effing pissed off.

Why? Because Intel is Facebooking its customers... 5+ years after the sale there is this HUGE "gotcha" or series of "gotchas" that springs out of the bushes. You trusted this company the whole time, only to realize that your trust was misplaced and their negligence put you/your company at risk.

IMO if you're doing the buying for a company and you are still buying Intel CPU's you are doing it wrong and you should be fully ready to accept whatever security vulnerabilities you get hit with going forward. This should be part of your disaster recovery plan.

The Facebook equivalent is "surprise! we've been selling your personal information to everyone on the planet! you are now compromised!"
^^^

I'm pretty sure that If people tried to hack Ryzen CPUs there would be waaay les exploits...Intel is just being fat and lazy, AMD can't afford to do that, if the roles were reversed, AMD would be out of business probably...
 
im finding it a little suspicious that out of all of these vulnerabilities none of them affect AMD.
 
I understand the "AMD isn't as big of a target" argument, and there may be some merit to this; however, they're making x86 CPU's too.... and I find it dubious that the mitigation required also HAPPENS to have a significant impact on performance.....

If I were a Sandy/Ivy Bridge customer and I purchased an expensive CPU for which I now must disable hyperthreading or some other mitigation killed performance in my applications, I would be really effing pissed off.

Why? Because Intel is Facebooking its customers... 5+ years after the sale there is this HUGE "gotcha" or series of "gotchas" that springs out of the bushes. You trusted this company the whole time, only to realize that your trust was misplaced and their negligence put you/your company at risk.

IMO if you're doing the buying for a company and you are still buying Intel CPU's you are doing it wrong and you should be fully ready to accept whatever security vulnerabilities you get hit with going forward. This should be part of your disaster recovery plan.

The Facebook equivalent is "surprise! we've been selling your personal information to everyone on the planet! you are now compromised!"


The worst part is they are still releasing new generation CPUs that still haven't mitigated any of the major vulnerabilities that came out the past couple years. I can't believe anyone would be considering purchasing intel at this point, since you have to neuter the shit out its performance with software 'patches'.
 
It's all about how the Intel Processors execute Code vs how AMD does. Intel has the breadth of the vulnerabilities because they only cared about speed. Security be damned. AMD however, has been building in security since at least 2013:
https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor

PSP has nothing to do with this class of exploits (meltdown, spectre and friends). They are considered micro architectural exploits as they take advantage of micro arch vulnerabilities (mostly residual state after certain instructions) inside the CPU pipeline itself.

PSP and IME are more of a system level security layer - verifying bootloaders, checking and generating keys, etc and I guess inspecting coherent traffic(?). Ironically, PSP and IME are a threat in and of themselves because they have access to all HW (including Ethernet, wifi, peripherals etc) and run completely independently of the OS and by extension user. Arguably this makes PSP as risky or even more than the micro arch exploits (as those are limited to extracting core state).

While I certainly think intel is being shitty - I can’t really blame the engineers. My belief is AMD got lucky by virtue of their design - as basically nobody in the industry was really looking into these kinds of attacks previously - assuming incorrectly that OS and stuff like PSP/IME are sufficient.
 
The worst part is they are still releasing new generation CPUs that still haven't mitigated any of the major vulnerabilities that came out the past couple years. I can't believe anyone would be considering purchasing intel at this point, since you have to neuter the shit out its performance with software 'patches'.

...but the "neutered" performance is (or at least should be if you have competent reviewers) built in to launch day reviews, so you know the level of performance you are buying.

Where this really hurts is when these explits and su sequebt patches come out after you ha e already bought and put a system or CPU in place...
 
im finding it a little suspicious that out of all of these vulnerabilities none of them affect AMD.
That's because they're not putting AMD processors under the microscope. Don't fall for the plausible deniability PR spin.

When your neighbor's house is being raided by the FBI, it's easy to say "Well, we're safe. They're going after them not us!"
 
Isn't physical access a game over scenario anyway?

That depends on the defenition of Physical access.

Does a remote console count?

Does a VM on a host count?


Lets say best case scenario and it actually has to be local access to the hardware with a interactive OS.

If you have guest logins to that system it could be an issue. Especially if you have multiple logins to the same system where people leave things suspended. Really the biggest risk here is from Kiosk machines being compromised. Especially if you were collecting potentially valuable data about users with them.
 
That's because they're not putting AMD processors under the microscope. Don't fall for the plausible deniability PR spin.

When your neighbor's house is being raided by the FBI, it's easy to say "Well, we're safe. They're going after them not us!"

AMD stated they don't see how that exploit can be done on their architecture. They didnt say it was impossible but you almost never going to get a statement like that as it can lead to being sued if someone can prove them wrong. So for now AMD is immune until proven otherwise.
 
That depends on the defenition of Physical access.

Does a remote console count?

Does a VM on a host count?


Lets say best case scenario and it actually has to be local access to the hardware with a interactive OS.

If you have guest logins to that system it could be an issue. Especially if you have multiple logins to the same system where people leave things suspended. Really the biggest risk here is from Kiosk machines being compromised. Especially if you were collecting potentially valuable data about users with them.

Physical access would be actual physical access (real world) to the system. Everything else is a mimic of physical access, you have the software side, but no ability to interact directly with hardware.
 
That's because they're not putting AMD processors under the microscope. Don't fall for the plausible deniability PR spin.

When your neighbor's house is being raided by the FBI, it's easy to say "Well, we're safe. They're going after them not us!"

Neighbors include ARM and IBM too, or is no one looking at them either?
 
That's because they're not putting AMD processors under the microscope. Don't fall for the plausible deniability PR spin.

When your neighbor's house is being raided by the FBI, it's easy to say "Well, we're safe. They're going after them not us!"

This is some strange whataboutism (and supported by a strange example...if the FBI raided a neighbor's home you'd think they're coming to raid your home next?). You're claiming the results of your experiments with two CPUs will be the same even though you know they have different architectures and you've only got the data from one test.
 
While I certainly think intel is being shitty - I can’t really blame the engineers. My belief is AMD got lucky by virtue of their design - as basically nobody in the industry was really looking into these kinds of attacks previously - assuming incorrectly that OS and stuff like PSP/IME are sufficient.

I wish I had saved the quote but in one earlier technical articles about some of these exploits they interviewed one the head people involved with CPU design at AMD and he said that when they were working on speculative execution they sacrificed speed in many cases because they were concerned about data leaking. He also specifically claimed that this was why AMD has been vulnerable to less of these exploits.

He might have been talking out of his ass but the facts tend to support his claim. It's also fairly damning if true because it either means that Intel with their massive R&D budget didn't see the potential issues or more likely saw the potential and made the decision to forego security for performance and hope it didn't get noticed.
 
I wish I had saved the quote but in one earlier technical articles about some of these exploits they interviewed one the head people involved with CPU design at AMD and he said that when they were working on speculative execution they sacrificed speed in many cases because they were concerned about data leaking. He also specifically claimed that this was why AMD has been vulnerable to less of these exploits.

He might have been talking out of his ass but the facts tend to support his claim. It's also fairly damning if true because it either means that Intel with their massive R&D budget didn't see the potential issues or more likely saw the potential and made the decision to forego security for performance and hope it didn't get noticed.

Definitely possible and if true more kudos to AMD. If you find the article please post a link as I’d be interested to read the full interview.
 
Physical access would be actual physical access (real world) to the system. Everything else is a mimic of physical access, you have the software side, but no ability to interact directly with hardware.


I understand the meaning. BUT.. some of the previous variants of this would work across VM's. As I manage some vmware clusters that's something I'm aware of. Especially because I've lost half of my logical processors to these freaking vulnerabilities.
 
This is some strange whataboutism (and supported by a strange example...if the FBI raided a neighbor's home you'd think they're coming to raid your home next?). You're claiming the results of your experiments with two CPUs will be the same even though you know they have different architectures and you've only got the data from one test.
It's called overgeneralization. You're reading way too much into it.

It has nothing to do with comparing either's results or even the specifics involved. It's highlighting the misguided false sense of security that is presented by those not under the spotlight. And don't read that as AMD making a statement - it's, again, an observation of some of the reactions here to such news.

Intel and AMD aren't drug cartels anyway.
 
Definitely possible and if true more kudos to AMD. If you find the article please post a link as I’d be interested to read the full interview.

I did take another look for that article but I couldn't find it(what I wouldn't give for an old school google that doesn't try to outsmart me). The closest I came was this article about Spectre and Meltdown that briefly discusses how Intel's speculative execution is more aggressive than AMD's which is why their CPUs are more susceptible to some of these attacks, this was basically what the engineer was discussing but obviously without the quotes it doesn't address whether it was intentional on AMD's part.
 
Too many but hey doesn't matter if you can turn they key without the key once you're in my car because you can't open the door .... (like you were the target anyway)

doesn't matter if i'm the target or not.

when someone keeps kicking holes in a locked door anyone can be pwned.
 
doesn't matter if i'm the target or not.

when someone keeps kicking holes in a locked door anyone can be pwned.

Yeah well that was my point, your actual PC might not be the target but all the services you may use also use Intel CPU and they might be real target which in the end means 100k of targets.
I'm just sick of the argument "well you need physical access for XYZ", a vulnerability is a vulnerability and may be used to cause you problem on so many levels other than your personal PC.

We need secure systems but I have to admit, the CPU isn't the first thing I would fix lol... it would be company overlooking at security.. which in the end means still buying XEON in 2019.
 
When I overpaid for my 6800k just before the Ryzen launch (wanted quad channel memory), I took solace in the initial benchmarks that showed my 6800k outperforming the 1800x in most workloads.

After all these patches.. ugh.
 
I know I'm pretty much asking for them to reinvent the wheel, and us all to buy into it, but remember when patching something was meant to fix a hole in something you wanted to save? Let it die already and reinvent the wheel. Sooner or later we'll all buy in just so we can move on.
 
Back
Top