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

Zuletzt bearbeitet:
Ich sehe da kein FUD, völlig ok zu überprüfen was es für Auswirkungen auf ZEN2 hat. Ist ja nicht so das die CPUs keiner mehr nutzt.
 
_semmel schrieb:
betrifft das den normalo eigentlich?
Zum Vergrößern anklicken....
Kann ich dir nicht sagen. Eine exploit chain mit am Ende "arbitrary code execution" in SMM hört sich nicht gut an. Ob man davon etwas mitbekommt und wie das ausgenutzt wird und werden kann, weiß ich nicht. Ich würde persönlich aber immer, wenn möglich, die aktuellen Sicherheitspatches verwenden.
 

Fefes Blog

blog.fefe.de
Intel und ARM bauen fröhlich neue Side Channels in ihre CPUs ein.

Weil man über solche Seitenkanäle in Krypto-Code gerne mal Schlüsseldaten extrahieren kann, haben ordentliche Libraries auf Code umgestellt, der unabhängig von den Daten immer konstant viel Zeit braucht.

Dabei gehen dann z.B. datenabhängige Table-Lookups nicht mehr, weil das den Cache involviert, und das ist ein Seitenkanal. Viele Algorithmen werden dadurch deutlich langsamer, aber das ist eine Kröte, die man dann halt frisst.

Und jetzt stellt sich raus, dass selbst bei bislang als risikolos geltenden Instruktionen wie Additionen und XOR plötzlich die Laufzeit von den konkreten Werten abhängt.

Schlimmer noch: Die AES-Instruktionen sind bei Intel plötzlich nicht mehr constant time. Da gibt es nun echt GAR keine Ausrede. Es gibt kein Szenario, in dem man die AES-Instruktionen nicht constant time haben will.

Update: Was an der Meldung besonders bemerkenswert ist: Addition und XOR sind bereits jetzt maximal schnell, zumindest auf x86. Die haben laut Handbuch eine Latenz von einem Takt. Nicht nur das: Bei XOR ist nicht mal offensichtlich, wie das schneller gehen soll, wenn man etwas über den Operanden weiß. Das ist schon die einfachste Operation, die man auf einer CPU durchführen kann, und sie läuft bereits mit maximalem Durchsatz und minimaler Latenz. Was kann da noch wegoptimiert werden?
Zum Vergrößern anklicken....
Originalquelle: https://www.openwall.com/lists/oss-security/2023/01/25/3
Non-constant-time instructions break cryptographic code that relies on
constant-time code to prevent timing attacks on cryptographic keys -- i.e., most
cryptographic code. This issue may also have a wider impact on the ability of
operating systems to protect data from unprivileged processes.

For Intel, processors with Ice Lake and later are affected by this issue.

The fix for this issue is to set a CPU flag that restores the old, correct
behavior of data-independent timing: DIT on Arm, and DOITM on Intel.

Linux v6.2 will enable DIT on Arm, but only in the kernel. Without any
additional patches, userspace code will still get data-dependent timing by
default. See https://git.kernel.org/linus/01ab991fc0ee5019

No patch has been merged to enable DOITM on Intel processors. Thus, as-is, it's
not really possible to safely execute cryptographic algorithms on Linux systems
that use an Intel processor with Ice Lake or later. (I'd guess that the same is
true for other operating systems too; Linux is just the one I'm looking at.)
Zum Vergrößern anklicken....
 
AMD hat eine mögliche Lücke in SMT.
Cross-Thread Return Address Predictions

Bulletin ID: AMD-SB-1045
Potential Impact: Information Disclosure
Summary

AMD internally discovered a potential vulnerability where certain AMD processors may speculatively execute instructions at an incorrect return site after an SMT mode switch that may potentially lead to information disclosure. AMD believes that due to existing mitigations applied to address other speculation-based issues, theoretical avenues for potential exploit of CVE-2022-27672 may be limited only to select virtualization environments where a virtual machine is given special privileges. As of this notice, AMD is not aware of any actual real-world exploits based on this behavior. Quelle
Zum Vergrößern anklicken....

Intel hat auch wieder welche im Angebot, in SGX... Ein Microcode Update gibt es in Ubuntu 22.04 dafür schon.

Intel Posts Updated CPU Microcode For Two More SGX Vulnerabilities, Privilege Escalation Bug
 
Naja, die Lücke ist relevant, wenn spezifisch VMs erhöhte Privilegien erhalten - also eine Konfigurationswarnung, die bestehende Mitigationen überbrückt versehentlich.
 
Zuletzt bearbeitet:
Auf der Seite tarnkappe.info ist ein Artikel zu einem weiteren Seitenkanal-Angriff auf Intel-CPUs erschienen:

Sicherheitslücke entsteht im EFLAGS-Register der Intel-CPU
Der eigentliche Fehler entsteht im sogenannten EFLAGS-Register der betroffenen Prozessoren. Dieses Register enthält verschiedene Flags, die auf den aktuellen Zustand der CPU hindeuten.


Kommt es zu einer Änderung des dort gespeicherten Inhalts, so kann dies das Timing von JCC-Anweisungen beeinträchtigen. Letztere wiederum ermöglichen eine bedingte Verzweigung (Jump on Condition Code) auf Basis der Zustände im EFLAGS-Register. Verzögerungen in der Ausführungszeit sind vom Angreifer messbar, was es ihm schließlich erlaubt, Daten zu entschlüsseln.


In ihren Experimenten konnten die Forscher durch einen gezielten Angriff auf die Schwachstelle in den Intel-CPU-Typen i7-6700 und i7-7700 eine Erfolgsrate von 100 % erreichen. Als Betriebssystem kam dabei Ubuntu 16.04 mit Linux-Kernel-Version 4.15.0 zum Einsatz.
Zum Vergrößern anklicken....
Auch bleepingcomputer.com haben einen Artikel dazu veröffentlicht
Intel CPUs vulnerable to new transient execution side-channel attack

Transient execution timing attack​


The new side-channel attack presented in a technical paper published on Arxiv.org describes a flaw in the change of the EFLAGS register in transient execution, affecting the timing of JCC (jump on condition code) instructions.


The EFLAGS register is a CPU register that holds various flags related to the processor’s state, while the JCC instruction is a CPU instruction that allows conditional branching based on the content of the EFLAGS register.


The attack is carried out in two phases, the first being to trigger transient execution and encode secret data through the EFLAGS register, and the second is to measure the execution time of the KCC instruction to decode the data.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Update mit Statement von AMD:
“AMD is aware of the research report attacking our firmware trusted platform module which appears to leverage related vulnerabilities previously discussed at ACM CCS 2021. This includes attacks carried out through physical means, typically outside the scope of processor architecture security mitigations. We are continually innovating new hardware-based protections in future products to limit the efficacy of these techniques. Specific to this paper, we are working to understand potential new threats and will update our customers and end-users as needed.” — AMD spokesperson to Tom's Hardware.
Zum Vergrößern anklicken....
 
This includes attacks carried out through physical means, typically outside the scope of processor architecture security mitigations
Zum Vergrößern anklicken....
Auch eine Möglichkeit für die Lösung.
Ist das durch die Hardware bedingt?
 

Ä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