SSB: Yet another security hole due to speculative execution

For discussions about security.
Post Reply
Message
Author
User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

SSB: Yet another security hole due to speculative execution

#1 Post by prehistoric »

Just when you thought you might be able to trust the hardware you are running, after patching for Meltdown, Specter and variants, there is a new exploit named SSB that finds timing differences caused by storing results of speculative execution.

The problem comes from fetching things before you can be sure of the address. If the predicted address is wrong, the natural fix is to dump the fetched data as invalid. Unfortunately, this still means you can get data from addresses that should be forbidden to a process into a register available to the microarchitecture, but not in the idealized machine model. Once there the difference in the time required for operations allows data to leak to processes that should never have had it. If you didn't have cores performing billions of instructions per second I don't think this would be very practical, because of the low bandwidth channel it offers into other processes.

Only a determined paranoid would have guessed this one.
Last edited by prehistoric on Sun 24 Jun 2018, 14:47, edited 1 time in total.

User avatar
8Geee
Posts: 2181
Joined: Mon 12 May 2008, 11:29
Location: N.E. USA

#2 Post by 8Geee »

This is evidently a serious "inter-cache" problem. kernnel dot org as of May 25 updates is patching some flaws related. As usual this will be on-going. As I read it, it appears that a single cache split between data and info is also affected. Some Intel MPU/CPU have this split-cache, including a few ATOMS (the E600 series).

Regards
8Geee
Linux user #498913 "Some people need to reimagine their thinking."
"Zuckerberg: a large city inhabited by mentally challenged people."

ozsouth
Posts: 858
Joined: Fri 01 Jan 2010, 22:08
Location: S.E Australia

#3 Post by ozsouth »

From http://www.theregister.co.uk/2018/05/21 ... ft_google/

According to Intel, mitigations already released to the public for variant 1, which is the hardest vulnerability to tackle, should make attacks leveraging variant 4 much more difficult. In other words, web browsers, and similar programs with just-in-time execution of scripts and other languages, patched to thwart variant 1 attacks should also derail variant 4 exploits.

backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

#4 Post by backi »

Hi !
Bodhi Linux shut down Distribution`s Forum due GDPR :
https://www.bodhilinux.com/2018/06/03/f ... e-to-gdpr/
https://www.eugdpr.org/

See also Distrowatch :
https://distrowatch.com/weekly.php?issue=20180604#news

I am no Expert ....what are the Consequences ......could PuppyLinux Forum also be affected ?

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#5 Post by rufwoof »

Since it is a security risk OpenBSD have opted to disable Intel's hyperthreading by default https://www.mail-archive.com/source-cha ... 99141.html and opine that generally the performance hit can be low, if any ...
Note that SMT doesn't necessarily have a positive effect on performance;
it highly depends on the workload. In all likelihood it will actually slow down most workloads if you have a CPU with more than two cores.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

cache vulnerability without speculative execution

#6 Post by prehistoric »

We have several different topics in this thread, like the GDPR, which belong in separate topics.

What I'm adding to this is a mention of a new vulnerability in Intel processors due to caches used to implement hyperthreading. It does not depend on speculative execution, but it does use a timing side channel. Modern Intel processors have two complete sets of registers in the microarchitecture to hold state for rapid context switches. This exploit allows information to leak from one to the other.

At this point it does not seem to apply to AMD processors and their hypertransport which is a very different machine model from hyperthreading that does not give programmers the appearance of multiple processors. Only the "hyper" prefix seems to connect these architectures.

So far it appears that the OS would have to be infected with malware to make this possible. Once this happens malware could grab cryptographic keys used for things like HTTPS. Disabling hyperthreading will defeat this.

Post Reply