CPU Side Channel Attack Index Page

Updated -

Issue

Starting with Spectre & Meltdown attacks that became public starting January 3rd, 2018, there have been a string of subsequent issues (directly and indirectly related) that have captured the public's interest. This article serves as a landing page for readers desiring to quickly have access to the numerous Red Hat artifacts that document our response to these issues.

Detection

For each CPU vulnerability which had a vulnerability response article there was also a detection script released. To simplify downloading and running all of these detection scripts you can use combined CPU vulnerability detection script. This script will download respective scripts and their GPG signatures, check the signatures, and allow user to run all these scripts in a batch. To verify the legitimacy of the script, you can download the detached GPG signature as well.

Resolution

CVE Alias Branded Name Affected Architectures Date Public Information
CVE-2017-5753 Variant 1 Spectre - Bounds Check Bypass Intel, AMD, ARM, POWER, s390x Jan. 3, 2018 Speculative Exec
Article: 3311301
CVE-2017-5715 Variant 2 Spectre - Branch Target Injection Intel, AMD, ARM, POWER, s390x Jan. 3, 2018 Speculative Exec
Article: 3311301
CVE-2017-5754 Variant 3 Meltdown Intel, POWER Jan. 3, 2018 Speculative Exec
Article: 3311301
CVE-2018-3639 Variant 4 Speculative Store Bypass Intel, AMD, ARM, POWER, s390x May 21, 2018 Speculative Bypass
How SSBD Works
CVE-2018-3665 N/A Lazy FPU Save/Restore Intel (only old processors) June 18, 2018 Solution: 3485131
No CVE N/A TLBleed Intel, AMD, ARM, POWER, s390x June 29, 2018 Solution: 3508581
TLBleed
CVE-2018-3693 N/A Bound Check Bypass Store Intel, AMD, ARM, POWER, S390x July 10, 2018 Solution: 3523601
No CVE N/A NetSpectre Intel, AMD, ARM, POWER, S390x July 27, 2018 NetSpectre
Blog
CVE-2018-3620 L1 Terminal Fault Attack Foreshadow Intel Aug. 14, 2018 L1TF
CVE-2018-3646 N/A L1 Terminal Fault Intel Aug. 14, 2018 L1TF
CVE-2018-5390 N/A SegmentSmack -NOT Side-channel related Kernel TCP/IP stack Aug. 7, 2018 Article: 35530611
CVE-2018-5391 N/A FragmentSmack- NOT Side-channel related Kernel TCP/IP stack Aug. 14, 2018 Article: 3553061
No CVE N/A RowHammer
SPOILER
DDR3/4 June 24, 2014 Article: 1377393
CVE-2018-12126 Microarchitectural Store Buffer Data Sampling MSBDS or Fallout Intel May 14, 2019 MDS
CVE-2018-12127 Microarchitectural Load Port Data Sampling MLPDS Intel May 14, 2019 MDS
CVE-2018-12130 Microarchitectural Fill Buffer Data Sampling MFBDS or RIDL or ZombieLoad Intel May 14, 2019 MDS
CVE-2019-11091 Microarchitectural Data Sampling Uncacheable Memory MDSUM Intel May 14, 2019 MDS
CVE-2019-1125 SWAPGS gadget SWAPGS Intel & AMD August 6, 2019 SWAPGS

8 Comments

The 'Combined' is incorrectly. At least i expected to download this 'combined' script and that was it. But it turned out that it was just a download-wrapper.

Now that it just a stupid download helper there is a paradox here on security. In security aware environments you do not have direct internet acess open.

Please re-think on this, either update the word to make it clear that this is just a downlaod helper. Or create a real single 'combined' script that does all the checks.

He Peter. I am sorry that the script did not meet your expectations.

Can you please explain how the paragraph currently describing the script purpose and usage is unclear? I think that the first three sentences are pretty accurate and I would like to know which parts are confusing so we can do it better. Or is it just the word "combined"?

Hi Stanislav,

Correct it is the word blue highligthed word 'combined' that sets for me a level of expectation. The rest of the paragraph is then noise including the word 'downloading'.

If the word 'combined' was changed with 'download wrapper' or 'download helper' then it gives a different expeaction level.

GPG keys not available, therefore script is failing.

gpgkeys: key 8B1220FC564E9583200205FF7514F77D8366B0D9 can't be retrieved gpg: no valid OpenPGP data found.

Hi Peter. The script tries to retrieve GPG key from either of the following servers: keys.gnupg.net , hkps.pool.sks-keyservers.net , pgp.mit.edu . Do you have access to any of these? Do you by any chance use http-proxy?

proxy details are provided on command line. but looks like proxy config is not allowing gpg to access key servers. need to do some more investigation here.

Line 90 needs to be changed to something like:

gpg2 --keyserver "$server" --keyserver-options http-proxy=proxy_address:proxy_port --search-keys 8B1220FC564E9583200205FF7514F77D8366B0D9

We will update the script in the future to add a commandline option for this, but it may take some time. Can you try the above workaround and let me know?

as mentioned already it is proxy configuration itself in my case.