ANOTHER Intel vulnerability... SWAPGS

https://www.phoronix.com/scan.php?page=news_item&px=CVE-2019-1125-SWAPGS

And, yes, it does look like it will impact performance… Benchmarks being worked on.

3 Likes

I REALLY want to see the Bulldozer FX vs the same era and beyond Intel benchmarks now.

5 Likes

So do i.

I reckon bulldozer would hold up to a contemporary i7 once all the broken security is patched.

To be fair, a phenom II probably would. The current problems are inherent in the design of those CPUs. I’m pretty sure that those aren’t easily fixable. And since most of the performance improvements come from either HT or Speculative Execution, and only disabling them would really fix this mess, there isn’t much sustance left after that.

That said, most of this stuff is only relevant in virtualised environments where you share hardware between parties that don’t trust eachother.

Yup, and that’s the point.

For the past 10-15 years, intel has been short-cutting on security vs. performance. AMD has not. They’ve still had spectre to deal with (which was pretty much industry wide) but intel has been deliberately speculatively executing stuff prior to validating whether or not it should even run (on the assumption they can roll back the results - and meltdown, etc. demonstrates they didn’t account for a bunch of ways that this doesn’t happen) - for performance reasons.

Diagree.

Some of this stuff has been demonstrated to be exploitable via javascript (on un-patched systems). You’re running un-trusted code in your browser every day…

Also… app virtualisation is the way forward for security (see, the new sandboxed version(s) of edge - for one example. see Qubes for another). VM escape via this sort of thing is a real problem that is, and will become more relevant on the desktop in the coming years.

Sure, it’s MORE of a concern for datacentre, don’t get me wrong. but as a desktop user, this is still relevant.

Only true in hindsight. It wasn’t clear that the way this got exploited was possible at all. The way most of this stuff gets now exploited has a lot to do with nanosecond timing and variances in execution times.
You can’t claim 100% security until its tested. Nothing is 100% secure in tech. Intel did something that improved performance and now, after looking into it, it’s not secure. You can’t possibly now such things beforehand (at least not every way things can break).

The only thing i hold against them, is not opening up their design, microcode and code to be reviewed by independent parties. But that’s true for both CPU manufacturers.

That’s why i said “most”. Sure some of this is a real problem, but 90% of the stuff that got fixed with performance impact is utterly irrelevant for a normal Desktop user.

It is, but not on your local machine. Even in Qubes all the VMs are run by you. You are not letting an unknown User us a VM on your Machine.

The point is, the exploitation of this stuff is really hard to do, time consuming and yields random results.
If anyone is able to run such code on your local machine they have WAY better and easier options to get what they want. This is really only relevant if you need stuff from a virtualised server that you can’t get to any other way.
You don’t need spectre or meltdown to extract information from a desktop PC. There are easier ways to do that.

Article from BleepingComputer on the situation with Linux, Android and ChromeOS.
TLDR: This time, unlike with Spectre and Meltdown, Linux has actually been kept in the loop, so they’ve had a chance to also patch alongside Microsoft. No word on BSD though. I’m thinking they aren’t far behind when the Linux devs have a fix now.

Red Hat said in a statement that the vulnerability affected both Intel and AMD chips and urged users to update systems “as soon as errata are available.” Bitdefender researchers, for their part, said they tested two AMD processors and “neither exhibited speculative behavior for the SWAPGS instruction.” In a statement, AMD officials wrote:

AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1.
Bitdefender researchers described two attack scenarios. The first is when SWAPGS isn’t being executed speculatively when it should and the second is just the opposite, when SWAPGS is being executed speculatively and should not be.

Each scenario had two variants: (1) when the attacker detects a value located at a specific kernel address and (2) when the attacker finds a value at a random kernel address. AMD’s statement indicates that its processors are affected only by the second variant of of the second scenario. The statement also indicates that existing Spectre mitigations are effective in this case.

3 Likes

I did read the news from phoronixs and only skimmed it but I do remember its and intel and AMD vulerability this time.

However MANY of the reported flawes since this began tossed AMD under the bus with intel because intels hired fake news makers and movers (hows it going at intel PCPER etc)

2 Likes

The best quote from that article tho:

The Bitdefender paper said researchers first reported the vulnerability to Intel 12 months ago, on August 7, 2018. Intel responded three weeks later by saying it already knew of the vulnerability and had no plans to fix it. Bitdefender said it spent the next eight months insisting to Intel that the behavior was problematic. Intel finally confirmed the leak of kernel memory on April 2 and indicated that a fix would come from fixes in operating systems.

:joy:

6 Likes

Yeah we know, what of it? Oh and go fuck yourself this is not our problem! -Intel 2018

Just amazing, but keep buying those chips!


On the AMD side, it says existing spectre fixes are effective here. Is the same true for Intel?

4 Likes

Havent you read todays news intel is going to release a 56 core chip based on the -Intel 2018 tech. Its all new and full of all the problems but we are maxing it out at 56 cores and please never bench mark it vs AMD :slight_smile:

2 Likes

Nah mate. Anyone with a clue with security would (and did - there was discussion about it LONG before meltdown was a thing) red flag this years ago.

This was a conscious design decision, to risk security/correct behaviour for performance - make no mistake. And it is one that AMD did not make.

edit:
stealing things out of cache from another thread was discussed as far back (possibly further) as 2005 when hyperthreading was new (to intel, with the pentium 4) by FreeBSD’s long time security officer, Colin Percival:

A lot of the issues intel are currently fighting were discussed, albeit not actually exploited, long, long ago.

And how does this prevent untrusted code, running in your browser (by you), from exploiting you, by gaining access to a sandbox VM that is running as an entirely different virtual machine?

Stated another way: just because it is YOU running the browser on your machine, are you REALLY sure that all of the relevant javascript on a modern page in 2019 is

  • running non-malicious code, intentionally (i.e., it wasn’t written by a malicious third party)
  • is not accidentally including malicious code via a compromised ad network
  • has not been hacked and is now running malicious code inserted by a third party

Unless you’re throwing caution to the wind, and trusting the security of your box to every random ad network and half-assed wordpress site you may happen to visit on the internet (even in a Qubes disposable VM) this (class of vulnerabilities) is a big deal.

There’s been no javascript exploit FOUND in the wild yet, but the paranoia with this stuff last year is definitely justified. There was a javascript proof of concept for it.

1 Like

I’m not arguing it’s technical possibility, just it’s feasability. If you have access to a browser there is a lot of easier stuff you could do to gain access to what ever you want then trying to exploit Speculative Execution. There hasn’t been an exploit in the wild, because attackers have a million ways that are easier, faster and more reliable than this. Even social engineering and fishing are better options. It’s also only relevant for targeted attacks, so spreading this over an ad network is useless. Those exploits aren’t use to deploy Cryptominers or such. They are really only usefull in highly targeted attacks on infrastructure you can’t get to any other way (think DB server in a DMZ, or completely offline, but virtualised).

If you are using a browser, all bets are off and there are thousands of exploits you should worry more about than all the CPU Problems.

That doesn’t mean we shouldn’t fix those. Intel should. And AMD is gaining ground because of it, which is great. It’s just that the fear about those things is completely overblown for 99% of people and you probably will never have to worry about it. I do, because we run a virtualized environment for 200 odd customers on the same cluster. But on your personal machine, it’s a non issue (in a “how big is the actual danger” sense).

1 Like

I think you are misunderstanding. This javascript proof of concept could be hosted on a remote server/ad network, and compromise your client machine (theft of credentials) via you browsing to it. You don’t need to be sitting in from of the machine, with “access to a browser” to steal information with this exploit.

Ok, i think you’re misunderstanding :wink:
Access to a browser was meant in “the user uses a browser to visit your site”. That’s what you need to run the POC and that’s what you need for any of the other 100s of exploits available. No physical access needed.

What ever. Let’s agree to disagree on that. We both agree that this is a problem worth fixing. I just don’t think the real world implications on Desktop Machines are as severe as most media makes it look to be.

I might be proven wrong in a couple of months though, and i’ll happily admit that i was wrong.

a new variant of Spectre V1 that affects all operating systems and is believed to affect only Intel CPUs.

If it does affect AMD they aren’t disclosing it or can’t find out how.

https://www.phoronix.com/scan.php?page=article&item=swapgs-spectre-impact&num=1

1 Like

Indeed from the next days phoronix testing

Contrary to Red Hat’s report initially saying AMD CPUs are affected, the Linux kernel is not applying this SWAPGS mitigation to AMD hardware (AMD has also issued a statement that they believe they are unaffected by this new Spectre V1 variant).

Its always someone tossing AMD under the bus with intel.

2 Likes

If you think far enough back, all of these side channel exploits are AMDs fault. Intel’s plan was to jump from x86 32 bit to Itanium, but AMD created a backwards compatible x86_64 that the industry adopted. Had AMD not done this, we would all be running itanium which is not vulnerable to these side channel attacks.

5 Likes