Side-channel vulnerability called PortSmash detailed

[HEXUS]

Researchers used this vulnerability as a vector to steal private decryption keys.

Read more.

[Tabbykatze]

Requiring to be run on the same core as the target is a massive stretch. Not sure how much risk i would associate with this vulnerability.

[philehidiot]

Requiring to be run on the same core as the target is a massive stretch. Not sure how much risk i would associate with this vulnerability.

Yeh, I was thinking this... It's not exactly the biggest vulnerability in the world ever.

[CAT-THE-FIFTH]

No bother since Intel has switched off SMT for almost its whole consumer range now - what a coincidence(sorry at the cheap shot).

I wonder if Ryzen is affected??

[philehidiot]

I wonder if Ryzen is affected??

Sounds like they think it will be. Guessing they went for the easy option first by hacking Intel and then decided to move onto AMD.

Another cheap shot.

[CAT-THE-FIFTH]

Sounds like they think it will be. Guessing they went for the easy option first by hacking Intel and then decided to move onto AMD.

Another cheap shot.

I know just the people!!

[Tabbykatze]

I wonder if Ryzen is affected??

Not sure how much it will be affected because of the way they handle inter core and thread security but we will have to see what they come out with. Because this is not a speculative execution vulnerability but is instead inside core thread handling it could be.

[EN1R0PY]

I get that it's important to say that it could affect other SMT implementations and AMD is the only other real player with SMT but mentioning AMD in the first sentence and saying "other architectures featuring SMT, especially AMD Ryzen systems, are also vulnerable to PortSmash style exploits" is misleading. The results are only about intel and there's nothing about ryzen's SMT implementation that makes it 'especially' vulnerable other than it has SMT. Using the word 'especially' instead of 'like' changes the context from "possibly also affects other SMT implementations which include AMD" to "AMDs SMT implementation will be affected more than others".

Not making any accusations but if I wanted to get hold of a brown envelope stuffed with cash I might just start writing articles about CPUs and just wait for the guy in the trench coat to turn up. Or maybe I could start benchmarking CPUs? Or maybe I could open up a security analysis lab? I reckon Intel spend more on "creative marketing" than r&d, that's why they haven't cracked 10nm!

[Tabbykatze]

I get that it's important to say that it could affect other SMT implementations and AMD is the only other real player with SMT but mentioning AMD in the first sentence and saying "other architectures featuring SMT, especially AMD Ryzen systems, are also vulnerable to PortSmash style exploits" is misleading. The results are only about intel and there's nothing about ryzen's SMT implementation that makes it 'especially' vulnerable other than it has SMT. Using the word 'especially' instead of 'like' changes the context from "possibly also affects other SMT implementations which include AMD" to "AMDs SMT implementation will be affected more than others".

Not making any accusations but if I wanted to get hold of a brown envelope stuffed with cash I might just start writing articles about CPUs and just wait for the guy in the trench coat to turn up. Or maybe I could start benchmarking CPUs? Or maybe I could open up a security analysis lab? I reckon Intel spend more on "creative marketing" than r&d, that's why they haven't cracked 10nm!

Looks like the wording may have been changed as now it just says "and possibly AMD".

[Corky34]

It will almost certainly effect AMD CPUs as it basically makes use of a vulnerability that's been known about for over a decade, if you attempt to use the same resource you can detect a conflict through timing differences. It's more to do with bad code than bad hardware as the storing of cryptography stuff shouldn't have an effect on the code you're running.

[philehidiot]

When I read it I got the impression that the people who had done it were fairly confident it could translate across to AMD but frankly, the whole thing is probably beyond my understanding.

A computer scientist was trying to teach me how to use logic gates to build an adder.

I asked how you make chips slither.

He stopped trying to teach me soon after.

[Tabbykatze]

It will almost certainly effect AMD CPUs as it basically makes use of a vulnerability that's been known about for over a decade, if you attempt to use the same resource you can detect a conflict through timing differences. It's more to do with bad code than bad hardware as the storing of cryptography stuff shouldn't have an effect on the code you're running.

It will affect the technology but AMD may have already got security implementations in place to prevent cross thread access. As with Spectre and Meltdown, Meltdown was null on AMD simply because they do not allow any call to be run without the appropriate security level whereas Intel sacrificed security for performance allowing some calls while authority was checked.

We shall have to see if PoC is established on AMD processors.

[Corky34]

This isn't a cross thread access thing, it's a timing thing, technically Spectre and Meltdown wasn't a thread access thing either as a malicious program couldn't access the code.

All of these types of attack depend on speculating, in the case of Spectre and Meltdown an attempt to run code would be requested and while privilege levels where being checked the CPU would start running that code despite the privilege level not being known at the time, while that malicious code is attempting to run and its privilege level is being checked the time it takes to access certain resources is measured. While the malicious code ultimately fails because it fails a privilege check we can deduce what resources would have been used by looking at the varying times of accessing certain resources.

At a completely inaccurate hypothetical level if i ask the CPU to load the alphabet one letter at a time i can detect if the CPU was already working on the letters HACK because those letters loaded far quicker than the other letters, PortSmash is similar in that it runs code to detect what resources are in use. It's all a bit like how we know black holes are a thing despite not being able to see them.

[philehidiot]

This isn't a cross thread access thing, it's a timing thing, technically Spectre and Meltdown wasn't a thread access thing either as a malicious program couldn't access the code.

All of these types of attack depend on speculating, in the case of Spectre and Meltdown an attempt to run code would be requested and while privilege levels where being checked the CPU would start running that code despite the privilege level not being known at the time, while that malicious code is attempting to run and its privilege level is being checked the time it takes to access certain resources is measured. While the malicious code ultimately fails because it fails a privilege check we can deduce what resources would have been used by looking at the varying times of accessing certain resources.

At a completely inaccurate hypothetical level if i ask the CPU to load the alphabet one letter at a time i can detect if the CPU was already working on the letters HACK because those letters loaded far quicker than the other letters, PortSmash is similar in that it runs code to detect what resources are in use. It's all a bit like how we know black holes are a thing despite not being able to see them.

That's pretty impressive.

[DanceswithUnix]

I wonder if Ryzen is affected??

I expect it will be.

The interesting ones would be IBM Power and Sun SPARC chips, as they have more than 2 threads per core so whilst the information is leaked from one thread you might need to instrument the other 3 threads on Power or the other 7 threads on a Sparc to recover the data.

Edit: Changed 15 threads to 7 on Sparc as Niagra was too dumb to port block, but later 8 thread designs were finer grained.

[Dashers]

I expect it becomes less practical as core counts go up. The odds of your process running on a thread that is on the same physical core as another when you've got a crazy number of cores becomes unlikely.

Of course, it's another tool in the arsenal. And all the more reason not to use cloud or virtual services.