wikiPortSmash Side-Channel Vulnerability CVE-2018-5407
Am 2. November 2018 veröffentlichten fünf Forscher der Universitäten in Tampere (Finnland) und Havanna (Kuba) Informationen zu PortSmash - einer möglichen Seitenkanal-Attacke zum Auslesen von Daten eines parallel laufenden Threads in einer CPU.[1] Das Angriffsrisiko wird als moderat (CVSS v3 Score 4.8 von 10) bewertet. Zum Auslesen von Daten muss zuerst ein entsprechender Schadcode auf einem parallelen Thread des angegriffenen CPU Kerns ausgeführt werden. Ein Angriff ist also nur dann möglich, wenn der Angreifer Code auf einem parallelen Thread des betroffenen CPU Kerns ausführen darf.
Betroffene Systeme
Betroffen von der Sicherheitslücke sind potentiell Systeme mit aktiviertem Hyper-Threading.
Betroffene Hardware:
- Architekturen mit SMT/Hyper-Threading (nachgewiesen auf Intel Skylake und Intel Kaby Lake, es sind jedoch potentiell alle Produkte mit SMT/Hyper-Threading auch von anderen Herstellern betroffen).
Betroffene Software:
- OpenSSL <= 1.1.0h.
- Jede Software, die einen geheimen abhängigen Kontrollfluss bei einer beliebigen Granularität hat.
Lösungsmöglichkeiten
Aktuell (05.11.2018, 12:15h) ist die einzige Möglichkeit einen PortSmash Angriff auszuschließen das Deaktiveren von Hyperthreading. Da ein Angriff das Ausführen von Schadcode erfordert, sind aktuell am ehesten Systeme betroffen, auf denen nicht-vertrauenswürdige Dritte Code ausführen dürfen (z.B. in einer parallel laufenden virtuellen Maschine in einer Cloud-Umgebung).
Hyperthreading deaktivieren
Wie bereits bei CVE-2018-3646 von L1TF, unterbindet auch bei PortSmash das Deaktivieren von Hyperthreading (via BIOS oder Betriebssystem) die Möglichkeit eines Angriffes.
Softwareupdates
Die OpenSSL Versionen 1.1.1a-dev, 1.1.0j-dev und 1.0.2q-dev stellen Fixes für Seitenkanal-Angriffe (CVE-2018-0734, CVE-2018-0735) bereit.
Für weitere Informationen zu verfügbaren Software Updates folgen Sie den weiter unten verlinkten Informationen der Linux Distributoren.
Herstellerinformationen
Von Intel und AMD gibt es mit Stand vom 05.11.2018 die folgenden Statements.
Intel
Intel received notice of the research. This issue is not reliant on speculative execution, and is therefore unrelated to Spectre, Meltdown or L1 Terminal Fault. We expect that it is not unique to Intel platforms. Research on side-channel analysis methods often focuses on manipulating and measuring the characteristics, such as timing, of shared hardware resources. Software or software libraries can be protected against such issues by employing side channel safe development practices. Protecting our customers' data and ensuring the security of our products is a top priority for Intel and we will continue to work with customers, partners and researchers to understand and mitigate any vulnerabilities that are identified.[2]
AMD
At AMD, security is a top priority and we are continually working to ensure the safety of our users as new risks arise. We are investigating the PortSmash side-channel vulnerability report, which we just received, to understand any potential AMD product susceptibility.[3]
Linux Distributionen
Informationen zu den unterschiedlichen Linux Distributionen sind an den folgenden Stellen zu finden:
- Red Hat: CVE-2018-5407 (access.redhat.com) und Bug 1645695 - (CVE-2018-5407) (bugzilla.redhat.com)
- Debian: CVE-2018-5407 (security-tracker.debian.org)
- SUSE: CVE-2018-5407 (www.suse.com) und Bug 1113534 - (CVE-2018-5407) (bugzilla.suse.com)
- Ubuntu: CVE-2018-5407 (people.canonical.com)
FAQs
- Bin ich von der PortSmash Sicherheitslücke betroffen? Grundsätzlich sind alle Systeme mit aktiviertem Hyper-Threading potentiell von der Sicherheitslücke betroffen. Das Auslesen von Daten ist aber nur dann möglich, wenn auf einem parallelen Thread aktiv Schadcode ausgeführt wird. Potentiell am ehesten betroffen sind also Cloud-Lösungen, bei denen virtuelle Maschinen von unterschiedlichen Kunden parallel auf einem Host genutzt werden und gleichzeitig auf den Virtualisierungs-Hosts Hyper-Threading aktiviert ist.
- Soll ich Hyper-Threading deaktivieren? Wenn Sie ein System nur selbst oder gemeinsam mit vertrauenswürdigen Personen (z.B. Kollegen, die selbst ohnedies über Administrator-Rechte verfügen) verwalten sehen wir aktuell keine Erfordernis Hyper-Threading zu deaktivieren. Wenn Sie eine Cloud-Umgebung betreiben und unterschiedliche Benutzer parallel virtuelle Maschinen verwenden, ist derzeit das Deaktivieren von Hyper-Threading die einzige uns bekannte Möglichkeit, ein Abgreifen von Daten einer benachbarten virtuellen Maschine via PortSmash auszuschließen. Beachten Sie, dass ein Deaktivieren von Hyper-Threading im schlimmsten Fall die Prozessorlast verdoppelt.
- Handelt es sich bei PortSmash um einen Hardware-Bug oder Software-Bug? Diese Frage lässt sich aktuell nicht eindeutig beantworten.[4] Die Gefahr dieser Sicherheitslücke kann sowohl durch Hardwaremaßnahmen (Deaktivieren von Hyper-Threading) als auch Software-Maßnahmen (z.B. Sicherheitsupdates für OpenSSL) verringert werden.
- Wird es BIOS Sicherheitsupdates oder Intel Microcode Updates zum Schließen der Sicherheitslücke geben? Uns liegen aktuell keine Informationen für geplante Microcode-Updates vor.
Weitere Informationen
- Neue Schwachstelle in Intel-CPUs: Hyper-Threading anfällig für Datenleck (www.heise.de, 04.11.2018)
- Intel CPUs fall to new hyperthreading exploit that pilfers crypto keys (arstechnica.com, 03.11.2018)
- Intel CPUs impacted by new PortSmash side-channel vulnerability (www.zdnet.com, 02.11.2018)
Einzelnachweise
- ↑ CVE-2018-5407: new side-channel vulnerability on SMT/Hyper-Threading architectures (oss-sec Mailing Liste, 02.11.2018)
- ↑ PortSmash: A New Side-Channel Vulnerability Affecting SMT/HT Processors (CVE-2018-5407) (www.phoronix.com, 02.11.2018)
- ↑ PortSmash attack blasts hole in Intel's Hyper-Threading CPUs, leaves with secret crypto keys (www.theregister.co.uk, 02.11.2018)
- ↑ Re: CVE-2018-5407: new side-channel vulnerability on SMT/Hyper-Threading architectures (Alexander Peslyak, oss-sec Mailing Liste, 02.11.2018) I think the existence of this side-channel in SMT should be obvious to the extent that it's not considered a vulnerability, but a fully expected by-design property. Maybe the problem is it wasn't documented as such. Maybe we should have put more effort into making it more obvious to everyone in 2005, like it's finally done now.
 |
Autor: Werner Fischer Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.
|
