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

[Crashtest]

Adminrechte erforderlich? Wenn Adminrechte mit im Spiel sind ist eh schon viel verloren (außer bei VMs bisher)

 

[tomturbo]

VMs werden immer mit Adminrechten erzeugt und verwaltet, sonst geht da nicht recht viel.

 

[Complicated]

Naja, die Zusage eines technischen Schutzes gegen "malicous Admins" ist für mich so oder so nicht ernst zu nehmen im produktivem Betrieb.

 

[Jackpot]

Amd hat eine Arbitrary Code Execution Lücke in AMD Secure Encrypted Virtualization. Damit diese Lücke ausgenutzt werden kann, werden Admin-Rechte benötigt.

Bulletin ID AMD-SB-1004
Potential Impact Arbitrary Code Execution
Severity Medium
Summary

AMD is aware of 2 research papers related to AMD’s Secure Encrypted Virtualization (SEV) which will be presented at this year’s 15th IEEE Workshop on Offensive Technologies (WOOT’21).

In the paper titled “SEVerity: Code Injection Attacks against Encrypted Virtual Machines,” researchers from Fraunhofer AISEC, in partnership with Technical University of Munich, make use of previously discussed research around the lack of nested page table protection in the SEV/SEV-ES feature which could potentially lead to arbitrary code execution within the guest.

In the paper titled “undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation,” researchers from University of Lubeck demonstrate that in the SEV/SEV-ES feature, memory can be rearranged in the guest address space that is not detected by the attestation mechanism which could be used by a malicious hypervisor to potentially lead to arbitrary code execution within the guest.

The exploits mentioned in both papers require a malicious administrator to have access in order to compromise the server hypervisor.

Quelle: https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1004

Quelle: https://www.amd.com/de/corporate/product-security
CVE-2020-12967, CVE-2021-26311

Noch ein Artikel zur Lücke
AMD untersucht Sicherheitslücken in EPYC-Prozessoren - hardwareluxx.de

Dann kündigt sich schon, meiner Meinung nach, ein nächster dicker Bug an.

AMD versteckt fragwürdige Funktionen in PCI-Treiber

Für einige Ryzen-CPUs nutzt AMD wohl im PCI-Treiber Funktionen, die wegen CPU-Fehlern deaktiviert sein sollten. Das kann zu Abstürzen führen.
...
Laut Ionescu verändert ein AMD PCI Driver genannter Treiber dabei unter anderem abhängig vom Namen des ausgeführten Prozesses Werte in sogenannten MSR (Model-Specific Register) der CPU. Dabei sei weder dieses Verhalten des Treibers dokumentiert noch die eigentliche Funktion der Register.

Der Treiber biete darüber hinaus keinen hinreichenden Schutz vor einer Übernahme der Funktionen und beinhalte eine Ioctl-Schnittstelle ohne jede Ausnahmebehandlung (SEH), die wiederum Zeiger derefenziere. Der Sicherheitsforscher nutzt diese schlechten Sicherheitsvorkehrungen, um das Ryzen-System mit nur einer einzigen Zeile Powershell-Code zum Absturz zu bringen.
Versteckte Funktions-Patches im PCI-Treiber...
...
Ionescu macht keinen Hehl daraus, dass er das Vorgehen von AMD mit dem Treiber durchaus fragwürdig findet. Er schreibt: "Das sollte nicht akzeptabel sein, und AMD sollte hier mit etwas Transparenz aufwarten. Dies hätte auch nicht als PnP-PCI-Treiber WHQL-zertifiziert werden dürfen".

Quelle(Zitat): golem.de

Dabei ist ihm aufgefallen, dass der Treiber bestimmte Werte der MSR (Model-Specific Register) verändert und diese veränderten Werte an den Prozessor weitergibt. Dies ist eigentlich recht ungewöhnlich, zumal hier Register dabei waren, die eigentlich laut Dokumentation über das BIOS gesetzt und danach (bzw. nach dem Boot-Vorgang) nicht wieder verändert werden sollten. Die dazu verwendete Ioctl-Schnittstelle (wird für Systemaufrufe für gerätespezifische Eingabe- / Ausgabeoperationen verwendet) ist zudem nicht abgesichert und so kann ein manipulierter Treiber beliebige Werte setzen, was in einem ersten Schritt dazu genutzt wurde, das System über einen Powershell-Befehl komplett zum Absturz zu bringen. Alleine dies sollte schon besorgniserregend sein.

Quelle(Zitat): hardwareluxx.de

 

[tomturbo]

Wenn das im Treiber passiert, dann ist das tatsächlich nicht akzeptabel.
Sowas muss AMD in der firmware unterbinden.

 

[Jackpot]

Es ist zwar keine direkte Lücke in der CPU, aber passt dennoch hier ganz gut rein.

Google hat eine neue Rawhammer-Technik namens "Half-Double" gefunden, die bisherige TTR-Schutzmaßnahmen wirkungslos macht.

Rowhammer "Half-Double" attackiert DDR4-Speicher: Google hat eine weitere Rowhammer-Technik vorgestellt, welche den bisherigen Target Row Refresh (TRR) als Schutz zunichtemacht. Damit werden für Rowhammer anfällige Speicherzellen markiert, eine Auffrischung dieser verhindert den Bitflip - wenngleich sich das per TRRespass umgehen lässt. Google hat dieses Verfahren nun so verfeinert, dass auch nicht direkt angrenzende Zeilen attackiert werden und dort Bits kippen können. Das Speichergremium Jedec hat zwei Mitigationen mit Google erarbeitet.(ms)
Quelle: https://www.golem.de/news/einstein-...4-speicher-mittels-rowhammer-2105-156799.html

NEAR-TERM DRAM LEVEL ROWHAMMER MITIGATION
SYSTEM LEVEL ROWHAMMER MITIGATION

Winzige Chip-Strukturen verschlimmern Hardware-Angriff Rowhammer - heise.de

 

[eratte]

M1RACLES: Apples erster Prozessor Silicon M1 hat einen Designfehler (au-ja)

 

[Denniss]

Mal schauen ob das die Apple-Jünger aus ihren Wolken holt, ihr "Heilsbringer" hat einen dicken Fehler der zum Mißbrauch einlädt wenn Schadsoftware sich eingeschlichen hat.

 

[Jackpot]

Es gibt wieder ein paar Bugs in Intel-CPUs. Dieses Mal betrifft es mitunter die Intel VT-d Iommu.

"High": Updates für VT-d, BIOS und mehr
Der höchste CVSS-Score unter den "High"-Lücken im Juni, nämlich 8.8, wurde CVE-2021-24489 zugeordnet. Die Lücke steckt in Intels VT-d (Virtualization Technology for Directed I/O) und könnte, sofern auf dem betreffenden System I/O-Virtualisierung verwendet wird, von einem lokalen authentifizierten Angreifer missbraucht werden, um seine Zugriffsrechte auszuweiten.
Quelle: https://www.heise.de/news/Patchday-...h-viele-Downloads-fuer-Endnutzer-6066243.html

Im Blog von Fefe gibt es einen Kommentar zur Lücke: https://blog.fefe.de/?ts=9e3f94c5

 

[Jackpot]

Jetzt ist AMD(*edit*Intel ist auch betroffen) wieder mit zwei Lücken dabei (CVE-2021-26313/CVE-2021-26314). Herausgefunden hat es die VUsec group(Universität Amsterdam). Beide Lücken kommen durch die spekulative Codeausführung zustande.

Es sollen alle zur Zeit unterstützten CPUs betroffen sein. Die Lösung die AMD anbietet, ist, dass der Softwarehersteller seinen Code auf potentielle Schwachstellen, die zur spekulativen Codeausführung führen können, überprüfen soll.

Der Firefox hatte einen Bug der FPVI betrifft.

Floating-Point Value Injection (FPVI) exploit in Firefox

Our FPVI exploit leaking arbitrary browser memory from JavaScript.

Quelle: Youtube
vusec.net

Bulletin ID AMD-SB-1003
Potential Impact Data Leakage
Severity Medium

Summary

AMD is aware of research from the VUsec group at Vrije Universiteit Amsterdam and believes that these issues are only exploitable in conjunction with software vulnerabilities related to incorrect speculation of specific sequences as described below. AMD is not currently aware of any instances of such vulnerabilities in commercially available software.

CVE-2021-26313
Potential speculative code store bypass in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution of overwritten instructions, may cause an incorrect speculation and could result in data leakage.

CVE-2021-26314
Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage.

Quelle: amd.com - amd-sb-1003

 

[eratte]

Sicherheitsupdate bremst einige Intel-Prozessoren leicht (heise)

 

[Jackpot]

Sicherheitsupdate bremst einige Intel-Prozessoren leicht (heise)

Es kam nun heraus, dass mit dem Microcode-Update Intel TSX aufgrund von Fehlern deaktiviert wird.

Intel deaktiviert TSX in Skylake und Coffee Lake
Nach Fehlern in den Haswell-Chips deaktiviert Intel nun auch TSX in den Skylake- und Coffee-Lake-CPUs. Grund sind Speicherfehler.

Quelle: https://www.golem.de/news/transacti...x-in-skylake-und-coffee-lake-2106-157726.html

 

[Complicated]

Ist ja schon länger bekannt, dass das ganze TSX sowieso kaputt ist.

TSX broken again

In march 2019 intel published a new white paper discussing a new bug they have found inside TSX and the proposed fix. Even in whiskey lake, TSX is still somewhat broken. The fix that intel has rolled out consists of two parts. They have disabled the Hardware Lock Elision (HLM) variant of TSX and...

erik.science

 

[tomturbo]

Braucht das nicht das SAP?

 

[Complicated]

SAP HANA inMemory Database hat Zertifizierung für TSX, braucht es aber nicht zwingend.

Innovation Squared with Intel and SAP: Persistent Memory Technology and SAP HANA

The Intel and SAP partnership is thriving, with SAP HANA as the first database platform optimized for the new Intel Optane DC persistent memory technology.

news.sap.com

SAP HANA was used to test the multi-core CPUs. When SAP added transaction capabilities to SAP HANA, we added a new feature — Intel® Transactional Synchronization Extensions (Intel® TSX) — to speed up transaction time by 500 percent.

Nur war halt nie etwas von 500% Beschleunigung angekommen in der Praxis bisher.

 

[eratte]

Auch bei CB angekommen:

Anhaltende Probleme: Intel deaktiviert TSX bei Skylake bis Coffee Lake (Computerbase)

 

[eratte]

Bit-Rauschen, der Prozessor-Podcast: Aktuelle CPU-Sicherheitslücken (heise)

 

[Jackpot]

AMD hat neue Bugs in AMD SEV, die sich über Spannungsmanipulation(voltage vault injection) ausnutzen lassen.

Angriff mittels manipulierter Spannung
Über eine sogenannte voltage fault injection, also einer veränderten Spannung, die zu den bekannten Side-Channel-Attack-Varianten gehört, lassen sich Parameter verändern, die den Chip so beispielsweise Informationen falsch interpretieren oder gar komplett überspringen lassen. Der Chip oder dessen Firmware ist per se sicher, aber diese Sicherheit lässt sich durch die externe Manipulation von Spannungen aushebeln: In diesem Fall wird die sichere Firmware der SEV durch eine manipulierte ausgetauscht, die über die Entschlüsselung des Speichers für eine vermeintlich sichere VM Angriffe ermöglicht. Dazu sei wiederum nicht einmal Zugriff auf das System von Nöten, weil sich die geheimen Schlüssel der mit der CPU verknüpften CPUs auslesen lassen.
Die Forscher schlussfolgern: AMDs SEV ist bis dato nicht dazu in der Lage, vertrauliche Daten in Cloud-Umgebungen vor von „Insider-Attacken“ wie kriminellen Administratoren zu schützen.
...
Immerhin bedarf es zur Ausnutzung der Lücke des Zugriffs auf das System, wenngleich die Ausnutzung dann relativ einfach vonstatten gehen soll, heißt es in der Analyse. Malicious administrators, wie AMD sie zuletzt auch nannte, könnten den Angriff in Rechenzentren oder bei sonstigem Serverzugriff deshalb problemlos umsetzen.

Quelle -computerbase.de

Transient Execution of Non-canonical Accesses - amd.com

AMD Secure Encryption Virtualization (SEV) Information Disclosure - amd.com

 

[Tanzmusikus]

Danke für die Info @Jackpot!
Was ist denn nun richtig? Die Aussagen in Deinem Zitat widersprechen sich:

Dazu sei wiederum nicht einmal Zugriff auf das System von Nöten,

Immerhin bedarf es zur Ausnutzung der Lücke des Zugriffs auf das System

Grüße

 

[Complicated]

Also es ist kein Zugriff nötig, nachdem ein Admin mit Zugriff auf das System die Firmware ausgetauscht hat, um danach mittels voltage fault injection das System zu kompromittieren. Aus dem Paper:

For the attack scenarios presented in the previous section, the
attacker needs to execute custom code on the AMD-SP, either to
provide a custom SEV firmware, or to extract the endorsement keys.
As described in Section 3, the AMD-SP loads an RSA public key,
the ARK, from the SPI attached flash to validate the authenticity of
subsequent loaded firmware components. If an attacker would be
able to replace the original ARK, all firmware components would
be validated using the attacker-controlled key, thereby enabling the
attacker to execute code directly after the ROM bootloader stage.

AMD hat ja schon eine Mitigation für Zen3:
CVE-2020-12966 ist noch nichts ausgefüllt, sondern lediglich reserviert.

CVE - CVE-2020-12966

https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1013

AMD EPYC™ Processors contain an information disclosure vulnerability in the Secure Encrypted Virtualization with Encrypted State (SEV-ES) and Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). A local authenticated attacker could potentially exploit this vulnerability leading to leaking guest data by the malicious hypervisor.

Also das hört sich in erster Linie nach Geheimdienst Szenario an. Für andere wäre diese langfristige Plazierung für später, wenn man schon Zugriff auf das System hat, kaum sinnvoll.

 

[tomturbo]

Das ist durchaus gefährlich, wenn z.B. dem Serverhersteller bereits eine gehackte firmware untergejubelt wird.
Soll ja schon vorgekommen sein

 

[Complicated]

Ja da gab es diese Szenarien bei der Produktion, die ja auch alle Geheimdiensten zugeordnet wurden.

 

[eratte]

Meltdown-like Vulnerability Affects AMD Zen+ and Zen2 Processors (TechPowerUp)

 

[Jackpot]

Als Ergänzung zur vorherigen Nachricht.
1

Transient Execution of Non-canonical Accesses
Summary
AMD reviewed “Transient Execution of Non-Canonical Accesses“ submitted by a researcher demonstrating that AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits.
CVE-2020-12965
When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.

2

Mitigation
AMD recommends that SW vendors analyze their code for any potential vulnerabilities related to this type of transient execution. Potential vulnerabilities can be addressed by inserting an LFENCE or using existing speculation mitigation techniques as described in [2].

Quelle(Zitate 1/2): https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1010

Im Linux-Kernel ab Version 4.14 wurde eine neue Technik zur Abmilderung der Meltdown und Spectre Lücken eingefügt.
3

For those who decide that kernel testing is more fun than galas and balls and champagne, Linux 5.14 offers many tasty little tidbits.
Perhaps the most significant are memfd_secret and core scheduling because both are ongoing clean-up work to mitigate Intel's Spectre and Meltdown fiascos.
memfd_secret lets applications create an area of memory that only that application can access. Not even the kernel can access the designated area of memory. Which matters, because Spectre and Meltdown meant cached data could be accessed. memfd_secret is designed to provide a safe place for secrets like cryptographic keys or passwords to reside.
The new core scheduling code matters because one way to mitigate Spectre and Meltdown was to disable hyper-threading.

Quelle(Zitat 3): https://www.theregister.com/2021/08/30/linux_5_14/

 

[eratte]

CPU-Sicherheitslücke: AMD Ryzen und Epyc per Seitenkanal verwundbar (heise)

Intel-Prozessoren älterer Generationen, die von "ZombieLoad" betroffen sind (Microarchitectural Data Sampling/MDS), sind grundsätzlich auch von Transient Execution of Non-Canonical Accesses betroffen; da es dort aber simplere Angriffsvektoren gibt, hat das keine praktische Relevanz.