News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)

Die Ausgabe von lscpu (zen2) unter Linux, aktueller Kernel .14.0-AMD mit amd Patches

Code: 
Schwachstellen:                   
  Itlb multihit:                   Not affected
  L1tf:                            Not affected
  Mds:                             Not affected
  Meltdown:                        Not affected
  Spec store bypass:               Mitigation; Speculative Store Bypass disabled
                                    via prctl and seccomp
  Spectre v1:                      Mitigation; usercopy/swapgs barriers and __us
                                   er pointer sanitization
  Spectre v2:                      Mitigation; Full AMD retpoline, IBPB conditio
                                   nal, STIBP conditional, RSB filling
  Srbds:                           Not affected
  Tsx async abort:                 Not affected

Wie es bei Zen3 mit dem geänderten L3 aussieht weiß ich nicht. Das ganze ist anscheinend eine längere Baustelle.
 
Sieht doch jetzt mal gut aus. Simpel und effektiv mit den zero overwrites der verwendeten register. Die Einstiegdshürde ist zumindest mal nach oben verschoben worden.
 
Es gibt eine Lücke im AMD PSP-Chipsatz-Treiber. Es sind einige Prozessoren betroffen, aber nur bis Zen 1000.
Die haben aber lange gebraucht für den fix, wenn die CVE schon im Januar 2021 in einer Debian-Security Liste aufgetaucht ist(Link).

AMD-SB-1009
Severity
Medium

Low privileged malicious users may be able to access and leak data through the AMD Chipset Driver.

CVE-2021-26333
An information disclosure vulnerability exists in AMD Platform Security Processor (PSP) chipset driver. The discretionary access control list (DACL) may allow low privileged users to open a handle and send requests to the driver resulting in a potential data leak from uninitialized physical pages.

Affected Products

6th Generation AMD FX APU with Radeon™ R7 Graphics
AMD A10 APU with Radeon R6 Graphics
AMD A8 APU with Radeon R6 Graphics
AMD A6 APU with Radeon R5 Graphics
AMD A4-Series APU with Radeon Graphics
AMD Athlon™ X4 Processor
AMD E1-Series APU with Radeon Graphics
AMD Ryzen™ 1000 series Processor
Zum Vergrößern anklicken....
Quelle: https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1009
 
Aktuell gibt es eine "Lücke" in ACPI in der WPBT-Tabelle, die es ermöglicht Treiber in Windows nachzuladen und worüber schon, wie bei Lenovo, die Software "Superfish"(heise.de) ausgeliefert wurde.

Microsoft WPBT flaw lets hackers install rootkits on Windows devices - bleepingcomputer.com

Everyone Gets a Rootkit - securityboulevard.com

The Eclypsium research team has identified a weakness in Microsoft’s WPBT capability that can allow an attacker to run malicious code with kernel privileges when a device boots up. WPBT is a feature that allows OEMs to modify the host operating system during boot to include vendor-specific drivers, applications, and content. Compromising this process can enable an attacker to install a rootkit compromising the integrity of the device.
...
This weakness can be potentially exploited via multiple vectors (e.g. physical access, remote, and supply chain) and by multiple techniques (e.g. malicious bootloader, DMA, etc). Organizations will need to consider these vectors, and employ a layered approach to security to ensure that all available fixes are applied and identify any potential compromises to devices.
Zum Vergrößern anklicken....

Quelle: Everyone Gets a Rootkit - eclypsium.com
 
Falscher Thread?
 
Hier sind eigentlich nur die Side-Channel Attacken zusammengefaßt ;)

Das ist ja ein MS eigenes Tool das Windows Software nachlädt.
ACPI hat hier ja keine Lücke, sondern mit der API wird OEM-Software (Treiber/Firmware/Bloatware) von Microsoft supported:
Aus Deiner verlinkten Quelle: https://securityboulevard.com/2021/09/everyone-gets-a-rootkit/
WPBT — The OEM Rootkit
Windows Platform Binary Table (WPBT) is an ACPI table first introduced in Windows 8. And while ACPI was originally intended to give the OS more control, WPBT can give the firmware a foothold in the OS. Microsoft describes WPBT as follows:

The WPBT is a fixed Advanced Configuration and Power Interface (ACPI) table that enables boot firmware to provide Windows with a platform binary that the operating system can execute. The binary handoff medium is physical memory, allowing the boot firmware to provide the platform binary without modifying the Windows image on disk.
  • Source: Microsoft, Windows Platform Binary Table (.docx)
This functionality was intended to let OEMs include important files, drivers, or executables for the system without needing to modify the Windows image on disk. The technology has been used by a number of vendors including Lenovo, ASUS, and many others. However, by executing files and modifying the operating system, this type of functionality can be seen as a vendor-specific rootkit. Acclaimed researcher and co-author of Windows Internals, Alex Ionescu, has been calling out the dangers of WPBT as a rootkit as early as 2012 and continues to do so today.
Zum Vergrößern anklicken....
Und das führt dann eben zu häufigen Unachtsamkeiten bei so vielen OEMs:
Several public incidents have provided examples of vendor-supplied code in firmware putting systems at risk. Lenovo’s Superfish adware and vulnerable Lenovo Service Engine (LSE) use WPBT to install software on devices, as does Absolute Software’s Computrace/LoJack. This LoJack software was later trojanized by attackers, resulting in the now infamous LoJax UEFI rootkit.
Zum Vergrößern anklicken....
 
Wenn ich das richtig verstehe, dann halten die den HPET für so kaputt, dass sie den komplett raus patchen wo immer es möglich ist.
HPET zu deaktivieren war mal ein Performance Tipp bei Zen1, der von AMD mit Zen+ gefixed wurde. Tatsächlich benötigt angeblich der Ryzen Master und andere Software anscheinend den synchronisierenden Hardware-Taktgeber um alle Daten korrekt darzustellen.
Auf meinem 3700X ist HPET deaktiviert (gechecked mit CPU-Z) und Ryzen Master macht keine Probleme.
Anandtech hat AMD zu dem Thema befragt und es wurde von AMD mitgeteilt, dass Ryzen Master HPET im BIOS aktiviert bei Installation, was den Neustart nötig macht, um es im OS zu aktivieren. Ich habe allerdings nach der Ryzen Master Installation BIOS Updates durchgeführt und diese scheinen HPET auf meinem MSI-Board wieder deaktiviert zu haben. Ich hatte noch keine Zeit mir das im BIOS anzusehen.
www.anandtech.com

A Timely Discovery: Examining Our AMD 2nd Gen Ryzen Results

www.anandtech.com www.anandtech.com
For those that remember the Ryzen 7 1000-series launch, about a year ago from now, one point that was lightly mentioned among the media was that in AMD’s press decks, it was recommended that for best performance, HPET should be disabled in the BIOS. Specifically it was stated that:

Make sure the system has Windows High Precision Event Timer (HPET) disabled. HPET can often be disabled in the BIOS. [T]his can improve performance by 5-8%.

The reasons at the time were unclear as to why, but it was a minor part in the big story of the Zen launch so it was not discussed in detail. However, by the Ryzen 5 1000-series launch, that suggestion was no longer part of the reviewer guide. By the time we hit the Ryzen-2000 series launched last week, the option to adjust HPET in the BIOS was not even in the motherboards we were testing. We cycled back to AMD about this, and they gave the following:

The short of it is that we resolved the issues that caused a performance difference between on/off. Now that there is no need to disable HPET, there is no need for a toggle [in the BIOS].

Interestingly enough, with our ASUS X470 motherboard, we did eventually find the setting for HPET – it was not in any of the drop down menus, but it could be found using their rather nice ‘search’ function. I probed ASUS about whether the option was enabled in the BIOS by default, given that these options were not immediately visible, and was told:

It's enabled and never disabled, since the OS will ignore it by default. But if you enable it, then the OS will use it – it’s always enabled, that way if its needed it is there, as there would be no point in pulling it otherwise.

So from an AMD/ASUS perspective, the BIOS is now going to always be enabled, and it needs to be forced in the OS to be used, however the previous guidance about disabling it in the BIOS has now gone, as AMD expects performance parity.

It is worth noting that AMD’s tool, Ryzen Master, requires a system restart when the user first loads it up. This is because Ryzen Master, the overclocking and monitoring tool, requires HPET to be forced in order to do what it needs to do. In fact, back at the Ryzen 7 launch in 2017, we were told:

AMD Ryzen Master’s accurate measurements present require HPET. Therefore it is important to disable HPET if you already installed and used Ryzen Master prior to game benchmarking.

Ultimately if any AMD user has Ryzen Master installed and has been run at any point, HPET is enabled, even if the software is not running or uninstalled. The only way to stop it being forced in the OS is with a command to chance the value in the BCD, as noted above.

For the Ryzen 2000-series launch last week, Ryzen Master still requires HPET to be enabled to run as intended. So with the new guidance that HPET should have minimal effect on benchmarks, the previous guidance no longer applies.
Zum Vergrößern anklicken....
Hier ein interessanter Beitrag der das Thema beleuchtet:
community.amd.com

Has AMD addressed the issue of Microsoft's Windows 8 and 10 having problems reading the correct clock speed from the Real-Time Clock on the South Bridge so that the same MHz on core, regardless of how the clock was made (by changing base clock and mu

I was recently reviewing the document covering the presentation at ISSCC and noticed that the RTC for Zen dies is located on the South Bridge. It was discovered about a year ago that Microsoft incorrectly reads the timer on the RTC when a base clock change occurs, which then can throw off...
community.amd.com community.amd.com
CPU-Z lässt sich nutzen um zu checken ob HPET aktiv ist auf dem eigenen System - Aufruf erfolgt über Tools:

large


Lässt man den Timer-Test einige Minuten laufen sieht man die immer größere Abweichung des RTC-Timers.

Sollte das deaktivieren des HPET-Timers die einzige Mitigation sein für den Bug, dann kommen auf Intel schwere Zeiten bei Gamingbenchmarks zu:
8700KGPU_575px.png


Für AMD ist das weniger problematisch in Gaming:
2700XGPU_575px.png


Die Tests auf Seite 4 bei Anantech: https://www.anandtech.com/show/12678/a-timely-discovery-examining-amd-2nd-gen-ryzen-results/4

Given that the difference between the two sets of data is related to the timer, one could postulate that the more granular the timer, the more the effect it can have: on both of our systems, the QPC timer is set for 3.61 MHz as a baseline, but the HPET frequencies are quite different. The AMD system has a HPET timer at 14.32 MHz (~4x), while the Intel system has a HPET timer at 24.00 MHz (~6.6x). It is clear that the higher granularity of the Intel timer is causing substantially more pipeline delays – moving from a tick-to-tick delay of 277 nanoseconds to 70 nanoseconds to 41.7 nanoseconds is crossing the boundary from being slower than a CPU-to-DRAM access to almost encroaching on a CPU-to-L3 cache access, which could be one of the reasons for the results we are seeing, along with the nature of how the HPET timer works.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
AMD hat eine Side-Channel-Lücke für alle ihre Prozessoren bekannt gegeben, die Lücke ist in der x86 Prefetch-Funktion.

Side-channels Related to the x86 PREFETCH Instruction
AMD-SB-1017
Potential Impact Leaked kernel address space information
Severity Medium

Researchers from Graz University of Technology with CISPA Helmholtz Center for Information Security have demonstrated timing and power-based side channel attacks leveraging the x86 PREFETCH instructions on some AMD CPUs. The attacks discussed in the paper do not directly leak data across address space boundaries. As a result, AMD is not recommending any mitigations at this time.

CVE-2021-26318
A timing and power-based side channel attack leveraging the x86 PREFETCH instructions on some AMD CPUs could potentially result in leaked kernel address space information.

Affected Products
All AMD CPUs
Zum Vergrößern anklicken....

Quelle - amd.com

*edit*
LEN-65528 AMD x86 PREFETCH instruction related side-channels CVE-2021-26318 AMD-SB-1017 2021-10-12 2021-10-12
Zum Vergrößern anklicken....
Quelle - lenovo.com
 
Zuletzt bearbeitet:
cve.report

CVE-2021-26318

A timing and power-based side channel attack leveraging the x86 PREFETCH instructions on some AMD CPUs could potentially result in leaked kernel address space information.
cve.report cve.report

CVE dazu ist aktuell noch nicht öffentlich. Wurde schon im März eingereicht.
 
AMD schreibt dazu
CVE-2021-26318
A timing and power-based side channel attack leveraging the x86 PREFETCH instructions on some AMD CPUs could potentially result in leaked kernel address space information.
Zum Vergrößern anklicken....
Was einen lokalen Zugriff auf die Stromversorgung bedeutet zur Ausnutzung des Vektors.
 
Wichtig zu beachten:
It's also worth mentioning that besides AMD not recommending any mitigation changes at this time, external Linux kernel developers so far have not proposed any kernel patches changing any page table isolation behavior or the defaults. So for now just take these results for hypothetical scenario if KPTI needs to be flipped on for AMD CPUs or are very paranoid about security and side with the researchers about the need to enable it. It's also possible that should improved page table isolation become necessary, AMD or other parties may suggest enhancements or alternatives to the existing KPTI code.
Zum Vergrößern anklicken....
 
Soweit ich gesehen habe keine Sidechannel-Lücken dabei bei AMDs Epycs.

Das liest sich seltsam bei den Intel Lücken:
Besitzer von Computern mit Intel Hardware oder einem Mini-PC auf NUC-Basis sollten sicherstellen, dass die Firmware und Intel-Software auf dem aktuellen Stand sind. Die Entwickler haben nämlich mehrere mit dem Bedrohungsgrad "hoch" eingestufte Sicherheitslücken geschlossen.


Verwundbar sind unter anderem Prozessoren mit AMD-Grafik-Einheit, NUC-PCs, SSDs und Wifi-Software.
Zum Vergrößern anklicken....
Das wäre ja nur Kaby Lake, in diesem Fall.
 
Laut dem Linux-Skript spectre-meltdown-checker.sh ist die letzte version des AMD Microcode für Zen 2 CPUs vom 25.01.2020:
Code: 
CPU microcode is the latest known available version:  YES  (latest version is 0x8701021 dated 2020/01/25 according to builtin firmwares DB v191+i20210217)
Entweder sind die Zen 2 nicht davon betroffen oder es hat nichts mit dem Micro-Code zu tun.

Code: 
Spectre and Meltdown mitigation detection tool v0.44+

Checking for vulnerabilities on current system
Kernel is Linux 5.11.0-40-generic #44~20.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021 x86_64
CPU is AMD Ryzen 9 3900X 12-Core Processor

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates IBRS capability:  NO
    * CPU indicates preferring IBRS always-on:  NO
    * CPU indicates preferring IBRS over retpoline:  YES
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES
    * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates STIBP capability:  YES  (AMD STIBP feature bit)
    * CPU indicates preferring STIBP always-on:  NO
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (AMD SSBD in SPEC_CTRL)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO
    * CPU indicates L1D flush capability:  NO
  * CPU supports Transactional Synchronization Extensions (TSX):  NO
  * CPU supports Software Guard Extensions (SGX):  NO
  * CPU supports Special Register Buffer Data Sampling (SRBDS):  NO
  * CPU microcode is known to cause stability problems:  NO  (family 0x17 model 0x71 stepping 0x0 ucode 0x8701021 cpuid 0x870f10)
  * CPU microcode is the latest known available version:  YES  (latest version is 0x8701021 dated 2020/01/25 according to builtin firmwares DB v191+i20210217)
* CPU vulnerability to the speculative execution attack variants
  * Affected by CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES
  * Affected by CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES
  * Affected by CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  NO
  * Affected by CVE-2018-3640 (Variant 3a, rogue system register read):  NO
  * Affected by CVE-2018-3639 (Variant 4, speculative store bypass):  YES
  * Affected by CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO
  * Affected by CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  NO
  * Affected by CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  NO
  * Affected by CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  NO
  * Affected by CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  NO
  * Affected by CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  NO
  * Affected by CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  NO
  * Affected by CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)):  NO
  * Affected by CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)):  NO
  * Affected by CVE-2020-0543 (Special Register Buffer Data Sampling (SRBDS)):  NO

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm64):  NO
* Kernel has array_index_nospec (arm64):  NO
> STATUS:  NOT VULNERABLE  (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: conditional, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  NO
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  NO
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  YES  (per-thread through prctl)
* SSB mitigation currently active for selected processes:  YES  (firefox geoclue irqbalance ModemManager pulseaudio systemd-journald systemd-logind systemd-resolved systemd-udevd upowerd)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  N/A
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: Not affected
* This system is a host running a hypervisor:  NO
* Mitigation 1 (KVM)
  * EPT is disabled:  N/A  (the kvm_intel module is not loaded)
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in kernel image)
  * L1D flush enabled:  NO
  * Hardware-backed L1D flush supported:  NO  (flush will be done in software, this is slower)
  * Hyper-Threading (SMT) is enabled:  YES
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO
* SMT is either mitigated or disabled:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2019-11135 aka 'ZombieLoad V2, TSX Asynchronous Abort (TAA)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* TAA mitigation is supported by kernel:  YES  (found tsx_async_abort in kernel image)
* TAA mitigation enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* This system is a host running a hypervisor:  NO
* iTLB Multihit mitigation is supported by kernel:  YES  (found itlb_multihit in kernel image)
* iTLB Multihit mitigation enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* SRBDS mitigation control is supported by the kernel:  YES  (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation)
* SRBDS mitigation control is enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer
 
NUC-PCs gibt es aber mit sehr unterschiedlichen CPUs
 
Das scheinen aber dicke Lücken zu sein.
CVE


Severity


Description
CVE-2020-12954

High


A side effect of an integrated chipset option may be able to be used by an attacker to bypass SPI ROM protections, allowing unauthorized SPI ROM modification.

CVE-2020-12961


High


A potential vulnerability exists in AMD Platform Security Processor (PSP) that may allow an attacker to zero any privileged register on the System Management Network which may lead to bypassing SPI ROM protections.

CVE-2021-26331


High


AMD System Management Unit (SMU) contains a potential issue where a malicious user may be able to manipulate mailbox entries leading to arbitrary code execution.

CVE-2021-26335


High


Improper input and range checking in the Platform Security Processor (PSP) boot loader image header may allow for an attacker to use attack-controlled values prior to signature validation potentially resulting in arbitrary code execution.
Zum Vergrößern anklicken....
Quelle: amd.com - amd-sb-1021

Summary:

A potential security vulnerability in some Intel® Processors may allow escalation of privilege. Intel is releasing firmware updates to mitigate this potential vulnerability.
Vulnerability Details:

CVEID: CVE-2021-0146

Description: Hardware allows activation of test or debug logic at runtime for some Intel(R) processors which may allow an unauthenticated user to potentially enable escalation of privilege via physical access.

CVSS Base Score: 7.1 High
Zum Vergrößern anklicken....
Quelle: intel.com

Betroffene CPUs: Intel Pentium, Celeron und Atom.
 
AluHut auf? ;) ja könnte man meinen aber denke nicht das es die Intention ist.
 

Ähnliche Themen

eratte
Notebook Copilot+ PC mit Snapdragon X Plus/Elite (ARM von Qualcom) - Reviewthread - Links in Post 1
2 3
Antworten
71
Aufrufe
4K
derDruide
derDruide
eratte
AMD Ryzen 9000 (ZEN5, AM5, DDR5, PCIe 5.0) Reviewthread - Links in Post 1
16 17 18
Antworten
429
Aufrufe
17K
eratte
eratte
eratte
AMD Ryzen AI 9 HX375/370/365 Notebook & Mini PC (ZEN5 12/10 Kerne, RDNA 3,5) Review und Diskussionsthread - Links in Post 1
2 3 4
Antworten
78
Aufrufe
4K
eratte
eratte
pipin
News Erste Exploits für CPU-Sicherheitslücke Spectre verfügbar
Antworten
3
Aufrufe
1K
Nero24
Nero24
eratte
Intel Raptor Lake-S Big/Little 8 + 16 Kerne (LGA1700, DDR5, PCIe 5.0, 6/7er Chipsatzserie) Reviewthread - Links in Post 1
7 8 9
Antworten
224
Aufrufe
18K
sompe
S
Zurück
Oben Unten