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

Doppel-Aua - Will Intel so seine Umsätze erhöhen und die alte Generation endgültig abschießen?
 
Ich habe vorsichtshalber bei den Rechnern mit aktiver IGPU (Ivy Bridge Generation) die tatsächlich neu zum Download anstehenden Treiber erneuert.

Beim Server mit 2008 R2 muss ich mir eh noch was einfallen lassen für die Zukunft.
 
CacheOut: Leaking Data on Intel CPUs via Cache Evictions

We present CacheOut, a new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries. We show that despite Intel's attempts to address previous generations of speculative execution attacks, CPUs are still vulnerable, allowing attackers to exploit these vulnerabilities to leak sensitive data.

Für mehr siehe Q&A auf der Webseite.

--- Update ---

CacheOut: Erneute Sicherheitslücke bei Intel greift den Cache an (HardwareLUXX)
 
Junge junge, Spectre und Co bekommt man ja mit deaktiviertem HT gut in den Griff. Aber jetzt auch noch den Cache abschalten? Da liegt man ja wieder auf Augenhöhe mit dem Pentium 3.. :P
 
Researchers Find Unfixable Vulnerability Inside Intel CPUs (TechPowerUp)

Every CPU manufactured in the last 5 years is subject to exploit, except the latest 10th generation, Ice Point-based chipsets and SoCs. The only solution for owners of prior generation CPUs is to upgrade to the latest platform as a simple firmware update can not resolve this. The good thing, however, is that to exploit a system, an attacker must have physical access to the hardware in question, as remote exploitation is not possible.

--- Update ---

Sicherheitslücke in CSME: Vertrauen in Intels Technologien schwindet (Computerbase)
 
Zuletzt bearbeitet:
Bei Endanwender schwindet das Vertrauen kaum noch, weil die AMD schon fast alle im Sack hat.
Die Serverhersteller- und Betreiber muss Intel bei Laune halten :] was viel schwieriger ist, weil die von den Lücken potentiell bedroht sind und sie nicht ignorieren können, wie Endanwender, die davon nichts zu befürchten haben.
 
New AMD Side Channel Attacks Discovered, Impacts Zen Architecture (tom's Hardware)

However, as spotted by Hardware Unboxed, the paper also says that "Additional funding was provided by generous gifts from Intel.

wie Endanwender, die davon nichts zu befürchten haben.

Sei nicht böse aber ich bezweifele das du die entsprechende Expertise hast um das beurteilen zu können (ich auch nicht aber ich mache auch nicht so eine Aussage). Wen wer eine der Lücken ausnutzen kann wird er damit nicht hausieren gehen.

Intel-Prozessoren: Hardware-Sicherheitsschlüssel in Gefahr (heise)

--- Update ---

AMD Ryzen und Epyc: Sicherheitslücke betrifft alle aktuellen AMD-Prozessoren (Computerbase)
 
Zuletzt bearbeitet:
Es scheint über ein Treiberupdate als Softwarelösung fixbar zu sein. IN dem Paper wird es beschrieben:
Uniformly-distributed Collisions.
While the previously described
countermeasures rely on either microcode updates or hardwaremodifications, we also propose an entirely software-based miti-gation. Our attack on an optimized AES T-table implementationin Section 5.4 relies on the fact that an attacker can observe the key-dependent look-ups to the T-tables. We propose to map such secret datantimes, such that the data is accessible viandifferent virtualaddresses, which all have a different?Tag. When accessing the data,a random address is chosen out of thenpossible addresses. The at-tacker cannot learn which T-table has been accessed by monitoringthe accessed?Tags, as a uniform distribution over all possibilitieswill be observed. This technique is not restricted to T-table imple-mentations but can be applied to virtually any secret-dependentmemory access within an application. With dynamic software di-versity [19], diversified replicas of program parts are generatedautomatically to thwart cache-side channel attacks
Und wenn ich das richtig verstehe, sollte eine aktivierte Speicherverschlüsselung keine brauchbaren Resultate ergeben. Darauf wird jedoch nicht eingegangen.

Die Funktion des "way predictors" ist Strom zu sparen beim herstellen der Cache-Kohärenz. Also würde das abschalten um die Lücke zu schließen den Stromverbrauch erhöhen durch mehr Zugriffe und weniger Powergating der Caches.
 
Zuletzt bearbeitet:
Mir scheint außerdem, dass dieses "Take a way" Dings im Grunde wieder auf einen "Spectre" Angriff zurückgeht.

https://www.computerbase.de/2020-03/amd-ryzen-epyc-sicherheitsluecke-cpu/

"We established a high-speed covert channel and utilized it in a Spectre attack to leak secret data from the kernel."

Also letztlich eine Variante eines Spectre V1 - der ja sowieso auch bei AMD CPUs schon immer ein Vektor war, und aufgrund der Art der Lücke eigentlich fast nicht zu 100% patchbar sein dürfte (außer via Software "hardening")

EDIT: Und wenn es wirklich eine Variante von Spectre V1 als Vektor ist MÜSSTEN dann nicht die schon ausgerollten Software Hardenings (vor allem im Browser) immer noch greifen ?
 
Zuletzt bearbeitet:
Das Paper beschreibt, wie der CPU Hardware-Tatkgeber für die Präzision verwendet wird. Das "Hardening" in Browsern basiert darauf die Taktgeber nicht mehr unnötig Präzise sein zu lassen. Das wird hier umgangen. Die Spectrre-Attacke wird dadurch erst möglich. Diese Vorarbeit wird als Etablierung eines Attack-Channels über den Cache bezeichnet.
Es wird auch beschrieben wie andere Taktgeber der CPU geschützt sind (durch ASML) und wie diese Schutzmechanismen spezifisch bei dem "way predictor" nicht greifen. Hier wird dann eine Präzision von 3 Takten erreicht, was den "Channel" auslesbar macht.
Interessantes Nebendetail des Papers ist die Beschreibung wie AMDs Victim-Cache-Design einige Angriffe verhindert, denen Intels CPUs mit inklusivem Cache ausgesetzt sind.
 
AMD Product Security

3/7/20

We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

AMD continues to recommend the following best practices to help mitigate against side-channel issues:

Keeping your operating system up-to-date by operating at the latest version revisions of platform software and firmware, which include existing mitigations for speculation-based vulnerabilities
Following secure coding methodologies
Implementing the latest patched versions of critical libraries, including those susceptible to side channel attacks
Utilizing safe computer practices and running antivirus software
 
Also nachdem ich das takeaway white paper nun gelesen habe, ich glaube bzw. verstehe es so: der Angriff ermöglicht zunächst einmal nur den Zugang zu definierten Adressräumen die kürzlich verändert wurden. KOMBINIERT man nun dieses mit einem Spectre V1 Angriff kann man also "gezielt" Adressbereiche scannen die verändert wurden (bzw. evtl. sogar gezielt zuerst nach Adressen "suchen" von einer Software auf die man es abgesehen hat (?).

Das passt auch zur Erklärung von AMD...der eigentlich Angriff erfolgt über Spectre V1, welcher ja schon mitigiert ist.
 
ups.. link schon da.
 
Wenn man sich bei CB mal den Forenthread dazu ansieht - da geht's richtig ab und mit einigen wohl auch richtig durch.
Viele freuen sich daß AMD auch mal was hat ohne zu verstehen was diese Angriffsmöglichkeit bedeutet/bewirkt. Ohne Kombination mit einem wirksamen(!) Spectre V1 Angriff können Angreifer keine nutzbaren Daten abgreifen. Meltdown/Zombieload und Co sind dort deutlichst mitteilungsfreudiger.
 
Das Niveau im Forum von CB und auch dem Luxx ist bei eigenen Themen sehr niedrig, da geht es nicht mehr um das Thema selber sondern um provozieren, Häme und draufhauen. Sachlich damit sich auseinander setzen ist nicht mehr gefragt - dazu tauchen da auch meist immer die selben Kandidaten auf.

Da sollte man auch besser sich nicht beteiligen so verschwendet man nur Zeit.

AMD processors from 2011 to 2019 vulnerable to two new attacks (zdnet)

https://twitter.com/PaulyAlcorn/status/1236755899781451779

Vedad Hadžic
Well, no. The way predictor still behaves like described in the paper. It leaks info on addresses and is not as severe as #meltdown. Aside from the ASLR breaks, the two attacks are just building blocks similar to Prime+Probe and Flush+Reload.

--- Update ---

Da ist wohl noch weitere Klärung nötig.

AMD widerspricht: Forscher finden Sicherheitslücken in AMD-Prozessoren (golem)

--- Update ---

Neue CPU-Sicherheitslücke in AMD-Prozessoren laut AMD gar nicht neu (heise)
 
Zuletzt bearbeitet:
Der Angriff erfolgt über SpectreV1 - daher ist da nichts neues in dem Paper.
Einen echten PoC der auch Daten ausliest und nicht nur Meta-Daten der Datenoperation enthüllt, wurde allerdings auch noch nicht gezeigt. So einfach ist es dann auch nicht die Timings in dem Angriffsscript zu nutzen und direkt die Daten automatisiert auszulesen. Bei Prime+Probe muss zudem der Thread des Scriptes auf dem selben Core ausgeführt werden.
Und das bei dem ständigen rotieren der genutzten Cores - also hier einen Zusammenhängenden Inhalt auszulesen möchte ich erst sehen - und dann bitte auch mit aktivierter RAM-Verschlüsselung. Denn wenn ASML ebenfalls erst einmal ausgehebelt werden muss, wie beschrieben in dem Paper, dann sehe ich hier keinen Weg lesbare Daten zu erhalten mit aktiver Verschlüsselung.
 
tom's Hardware haben ihren Artikel noch ein Update verpasst:

AMD responded for our request for more information and says there are no new mitigations required, as this issue is covered by the existing side channel attack mitigations.

The researchers do not agree, stating that this vulnerability is still active. Until the two sides agree it isn't possible to ascertain which viewpoint is more accurate. We'll update as necessary and keep an eye out for a CVE.
 
Und keine CVE-Nummer bisher gesehen... so lange hat AMD recht.
 
Zurück
Oben Unten