Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

[ingo2]

Ich habe jetzt nicht alle 10 Seiten gelesen, aber erfahren, dass mindestens einer der Bugs im Prinzip nicht gefixt werden kann. Ist das richtig? Vor ein paar Tagen hatte ich ein Kernel-Update (Stretch). Ich habe einen Intel Core-i5 Prozessor in meinem Notebook.

So isses. Das Kernel-Update fixt nur die Kernschmelze. Zusammen mit einem Microcode-Update wird offenbar auch Spectre-2 (Branch target injection) gefixt. Das sind die beiden gefährlichen Ostereier von Intel die eine "privilege escalation" erlauben. Da haben andere CPU-Hersteller sorgfältiger gearbeitet während Intel mit dem Speed-Vorteil marktbeherrschend wurde (jetzt bremsen die Patches Intel wieder). Wenn das auch noch die obscure Management-Engine umfaßt, dann Gute Nacht (die hatte ja auch in der letzten Zeit 2 bekanntgewordene Sicherheitslöcher, die stillschweigend gapatcht wurden). Und von de Bugs weiß Intel ja schon seit Mitte letzten Jahres!

Und Spectre-1 kannst du auf die Schnelle vergessen, das betrifft alle OoO und caching CPU's von (fast) allen Herstellern und ist einfach der jahrelangen Entwicklung zu immer schneller, immer weniger Leistungsaufnahme, .. geschuldet. Das kann praktisch nur auf Application-Ebene mit neuen Compilern, neuen Microcodes, ... gefixt werden, die eben bei kritischen Sachen die out-of-order Verarbeitung unterbinden.

So jedenfalls habe ich das verstanden.

[hikaru]

Ich habe jetzt nicht alle 10 Seiten gelesen, aber erfahren, dass mindestens einer der Bugs im Prinzip nicht gefixt werden kann. Ist das richtig?

Meltdown ist in allen noch untertützten Debian-Releases per KPTI gefixt (für Jessie im Backports-Kernel).

Ich habe einen Intel Core-i5 Prozessor in meinem Notebook.

Das sagt ohne Angabe der Generation leider gar nichts.
Bei Spectre kommt es offenbar darauf an, was du für eine CPU-Generation hast. Ab Haswell soll es Microcode-Fixes von Intel geben, Sandy und Ivy Bridge sind nach wie vor offen wie ein Scheunentor und es ist nicht absehbar, ob und wann Intel hier nachbessert. Für Nehalem hätte ich gar keine Hoffnung. Da ist aber zumindest für mich auch noch nicht klar, wie stark die Generation betroffen ist. Der unmittelbare Vorgänger Penryn lieferte zumindest bei mir keine klaren Ergebnisse.

Nur so aus neugier, sind den (Open)Power und Sparc-Prozessoren auch betroffen?

PowerPC ist im Prinzip von Spectre betroffen, in welchem Ausmaß weiß ich nicht. IBM hat für morgen Patches angekündigt. [1]
Sparc sollte vor dem T4 sicher sein, da das laut Wikipedia der erste Out-of-Order-Sparc ist. [2] Ob die Information zuverlässig ist und falls ja, ob das heißt, dass T4 und später verwundbar sind kann ich nicht mal erraten.

Wenn das auch noch die obscure Management-Engine umfaßt, dann Gute Nacht

Ich habe irgendwo aufgeschnappt, das AMDs PSP für Spectre anfällig sei. Ob da was dran ist weiß ich nicht.


[1] https://www.ibm.com/blogs/psirt/potenti ... er-family/
[2] https://en.wikipedia.org/wiki/SPARC_T4

[TRex]

Das kann praktisch nur auf Application-Ebene mit neuen Compilern, neuen Microcodes, ... gefixt werden, die eben bei kritischen Sachen die out-of-order Verarbeitung unterbinden.

So jedenfalls habe ich das verstanden.

Das versteh ich nicht. Wenn es im Usercode gefixt werden muss, dann ists kein Fix. Nur Malware ist ein Problem, alles andere eher weniger. Malware würde man nicht mit einem "gefixten" Compiler produzieren. Man kann den CPU-Bug nur im Kernel oder in der CPU (Hardware oder Microcode) fixen/absichern.

[hikaru]

Das versteh ich nicht. Wenn es im Usercode gefixt werden muss, dann ists kein Fix. Nur Malware ist ein Problem, alles andere eher weniger. Malware würde man nicht mit einem "gefixten" Compiler produzieren. Man kann den CPU-Bug nur im Kernel oder in der CPU (Hardware oder Microcode) fixen/absichern.

Disclaimer: Ich schwimme hier selbst beim Verständnis.

Folgendes Szenario:
Du hast irgendeine 3rd-Party-Firefox-Komponente (Addon, webseitiges Javascript, etc.) das von Firefox ausgeführt wird und in dem Zuge bekommt die Komponente Zugriff auf die Firefox-Speicherbereiche. Meinem Verständnis nach könnte so eine Komponente nach dem Spectre-Prinzip Zugriff auf Passwörter im Firefox-Speicher bekommen.
Um das zu verhindern wird irgendwas an Firefox geändert (Quellcode, Compilerschalter, etc.), das den 3rd-Party-Bereich wirksam vom Passwort-Bereich abschirmt. Prinzipiell könnte da das KPTI-Prinzip benutzt werden (nur einer der beiden Bereiche kann jeweils im CPU-Cache sein).

Dieser Usercode-Fix (der für jedes potenziell betroffene Programm individuell gegangen werden muss) ist sowas wie die Quick&Dirty-Lösung für Spectre. Sie funktioniert mit aktueller Technik, ist aber wegen der mangelnden Reichweite eine Sisyphosaufgabe.
Eine saubere Lösung könnte sein, Spekulations- und Commit-Cache physisch zu trennen. Dafür braucht es aber neue Hardware, ist also auf die Schnelle nicht umsetzbar. Ich vermute, sowas können wir frühestens ab der übernächsten CPU-Generation erwarten.
Mit Microcode-Fixes geht vielleicht ein Mittelweg: Temporäre Cacheseparierung in Spekulations- und Commitbereiche (reines Hirngespinst meinerseits)

[Harakiri]

Mit Microcode-Fixes geht vielleicht ein Mittelweg

Ich verstehe das auch so dass der aktuelle Intel-Microcode eine Teillösung ist, welche eine Schadensbegrenzung bewirken soll. So ist es kein kompletter Fix. Im letzten Changelog steht unter anderem drin:

intel-microcode (3.20171215.1) unstable; urgency=high

* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
New upstream microcodes to partially address CVE-2017-5715

CVE-2017-5715
https://cve.mitre.org/cgi-bin/cvename.c ... -2017-5715

[hikaru]

Info am Rande:
ARM-Cortex-A7- und -A8-Kerne arbeiten "in Order". Die auf diesen Architekturen basierenden Chips, wie z.B. Allwinner A10 (A8; Cubieboard) und A20 (A7; Cubieboard 2, Cubietruck) sind also sicher vor Spectre.

Korrektur:
Cortex A8 arbeiten zwar "in Order", tun das aber "superskalar" [1], was offenbar ausreicht um sie für Spectre anfällig zu machen. [2]
Auch der A7 arbeitet superskalar. Warum ARM den nicht aufführt, weiß ich nicht.


[1] https://de.wikipedia.org/wiki/Superskalarit%C3%A4t
[2] https://developer.arm.com/support/security-update

[BenutzerGa4gooPh]

Wäre mal interessant, welche Gelder so für eigene Fehler zu Anderen fließen: Intel-Hardware fehlerhaft, AMD-HW (etwas geringer) fehlerhaft, ARM, Qualcomm. Alle müssen patchen. Die "Guten" korrigieren Fehler der "Bösen". Oder haben diese "Guten" (doch lange und ihnen bekannten Risiken) lange Zeit nur hingenomen - einschließlich unser aller Linux-Gott mit dem Stinkefinger?

[ChronoBoost]

What Spectre and Meltdown Mean For WebKit

[hikaru]

Theo de Raadt unterstellt Vorsatz bei Intel:
https://www.itwire.com/security/81338-h ... raadt.html

[whiizy]

Vielleicht stand es hier schon irgendwo, aber Debian wheezy hat jetzt wohl auch erste work-arounds bekommen. Nach dem upgrade auf linux-image-3.2.0-5-amd64 habe ich hier bisher keine Probleme.

Aus dem changelog des Pakets:

linux (3.2.96-3) wheezy-security; urgency=high

* [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
(CVE-2017-5754)
* Bump ABI to 5 and apply deferred stable changes:
- Input: i8042 - break load dependency between atkbd/psmouse and i8042
- Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
- ACPICA: Utilities: split IO address types from data type models.
- ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks
- libata: Align ata_device's id on a cacheline
- libata: Ignore spurious PHY event on LPM policy change
- net/ipv6: add sysctl option accept_ra_min_hop_limit
* USB: core: prevent malicious bNumInterfaces overflow (CVE-2017-17558)
* [x86] KVM: Fix stack-out-of-bounds read in write_mmio (CVE-2017-17741)
* crypto: salsa20 - fix blkcipher_walk API usage (CVE-2017-17805)
* crypto: hmac - require that the underlying hash algorithm is unkeyed
(CVE-2017-17806)
* KEYS: add missing permission check for request_key() destination
(CVE-2017-17807)

-- Ben Hutchings <ben@decadent.org.uk> Sat, 06 Jan 2018 22:07:04 +0000

[TRex]

Ein Artikel, der mir beim Verständnis geholfen hat: https://ds9a.nl/articles/posts/spectre-meltdown/

[nudgegoonies]

An welcher Stelle im Boot-Prozess wird der Microcode eigentlich auf die CPU geladen? So wie ich es verstehe, müsste der Microcode vor dem Kernel in die CPU geladen werden. Ich überlege gerade was mit den neuen CPU_ID und MSR Flags geschieht die mit den Microcode Update kommen werden (QEMU muss die für die VM Sicherheit beachten). Kann Linux damit umgehen, dass sich im laufenden Betrieb die CPU bezüglich der CPU Features ändert? Soweit ich das gesehen habe, wird der Microcode in der initialen RAM-Disk geladen. Also wenn Linux schon läuft - und sich aufgrund der vorher vorhandenen CPU Flags anders konfiguriert hat.

[inne]

Theo de Raadt unterstellt Vorsatz bei Intel:
https://www.itwire.com/security/81338-h ... raadt.html

Kannst du bitte auf deutsch zusammenfassen wie er das herleitet und begründet!? Immerhin sind andere vermeintlich außenstehende auch auf diesen Fehler gekommen. Ist das im "Mit der Zeit gewachsen" entstanden und war nicht absehbar, oder warum hat man das bei Intel und Co. nicht auch kommen sehen?

[schwedenmann]

Hallo

@Inne

aus dem @hikaru verlinkten Artikel von de Raadt:

"Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies – so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk," he said.

mfg
schwedenmann

P.S.
Ist nur komisch, das alle bisher jedenfalls den Intel weg als falsch und unsicher betitelt habne, ich meine in der Vergangenheit, seit Intel dieses feature intergriert hat.

[jue]

Ich habe einmal gelesen, dass Intel von allem wusste, aber aus Gründen der Performance nichts geändert hat, weil das einen Marktvorteil gebracht hat. Ich weiß nicht mehr, woher ich das habe, es ist aber nachvollziehbar.
Zum Teil wurde das mit dem VW-Dieselbetrug verglichen.
http://www.elektroniknet.de/design-elek ... 49200.html

[novalix]

In dem weiter oben verlinkten Blog-Post von Greg Kroah-Hartmann war ja auch schon zu erkennen, dass die Kernelentwickler alles andere als zufrieden waren, mit dem "Krisenmanagement".
Ein Entdecker dieser Bugs war ja ein Team von der TU Graz. Mit einem Mitglied hatte der Spiegel wohl ein Interview geführt.

Daniel Gruss sagte, er finde es "beunruhigend", dass sein Forscherteam aus Graz nur eines von mehreren sei, die die Angriffe unabhängig voneinander und ungefähr zeitgleich entdeckt haben sowie ihr Wissen öffentlich gemacht haben. "Da stellt sich natürlich die Frage, wie viele andere das Problem noch entdeckt und nicht gemeldet haben", sagt Gruss. "Inwiefern Geheimdienste davon gewusst haben, können wir überhaupt nicht einschätzen." Im Nachhinein lasse sich auch nicht eindeutig klären, "ob das ein Bug oder eine Backdoor war".

[whiizy]

Jetzt ist auch Debian Jessie nicht mehr auf einen Backports-Kernel angewiesen:

https://security-tracker.debian.org/tra ... -2017-5754

Gerade, bei einem dist-upgrade, ist linux-image-3.16.0-5-amd64 bei mir eingelaufen.

Changelog:

Code: Alles auswählen

linux (3.16.51-3+deb8u1) jessie-security; urgency=high

  * dccp: CVE-2017-8824: use-after-free in DCCP code
  * Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with
    l2cap socket
  * Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with
    l2cap socket (CVE-2017-15868)
  * media: dvb-usb-v2: lmedm04: Improve logic checking of warm start
    (CVE-2017-16538)
  * media: dvb-usb-v2: lmedm04: move ts2020 attach to dm04_lme2510_tuner
    (CVE-2017-16538)
  * ipsec: Fix aborted xfrm policy dump crash (CVE-2017-16939)
  * netfilter: nfnetlink_cthelper: Add missing permission checks
    (CVE-2017-17448)
  * netlink: Add netns check on taps (CVE-2017-17449)
  * netfilter: xt_osf: Add missing permission checks (CVE-2017-17450)
  * USB: core: prevent malicious bNumInterfaces overflow (CVE-2017-17558)
  * [armhf,arm64,x86] KVM: Fix stack-out-of-bounds read in write_mmio
    (CVE-2017-17741)
  * crypto: salsa20 - fix blkcipher_walk API usage (CVE-2017-17805)
  * crypto: hmac - require that the underlying hash algorithm is unkeyed
    (CVE-2017-17806)
  * KEYS: add missing permission check for request_key() destination
    (CVE-2017-17807)
  * [x86]  KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
    (CVE-2017-1000407)
  * bluetooth: Prevent stack info leak from the EFS element.
    (CVE-2017-1000410)
  * Bump ABI to 5 and apply deferred stable changes:
    - Input: i8042 - break load dependency between atkbd/psmouse and i8042
    - Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
    - ACPICA: Utilities: split IO address types from data type models.
    - [arm64] Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
    - block: fix bdi vs gendisk lifetime mismatch
    - cgroup: make sure a parent css isn't offlined before its children
    - libata: Align ata_device's id on a cacheline
    - libata: Ignore spurious PHY event on LPM policy change
    - net/ipv6: add sysctl option accept_ra_min_hop_limit
    - quota: Store maximum space limit in bytes
    - quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units
    - [s390*] Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
    - scsi: scsi_error: count medium access timeout only once per EH run
    - [x86] panic: replace smp_send_stop() with kdump friendly version in panic
      path
  * [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
    (CVE-2017-5754)

 -- Ben Hutchings <ben@decadent.org.uk>  Mon, 08 Jan 2018 22:13:59 +0000
 

Danke!

[hikaru]

Mir kam über Nacht im Halbschlaf eine Idee zur Spectre-Abmilderung auf Kernel-Ebene:

Mozilla hat ja zumindest in FF 57 die Genauigkeit seines Timers von 5 auf 20 Microsekunden reduziert, um die für Spectre nötige Zeitmessung von Speicherzugriffen zu erschweren. [1]
Was wäre, wenn man die Genauigkeit der Software-Uhr des Linux-Kernels entsprechend reduziert? Müsste das nicht den selben Effekt haben, und zwar für alle Programme?

Aktuelle Kernel nutzen wohl eine Auflösung von einer Nanosekunde:

Code: Alles auswählen

$ grep -m 1 resolution /proc/timer_list
  .resolution: 1 nsecs

Aber wenn ich es richtig verstehe, dann waren in Kernel 2.4 noch 10 Millisekunden üblich. [2]
Es war also offenbar zumindest in grauer Vorzeit kein Problem, ein Linux-System mit einer noch viel geringeren Software-Uhr-Auflösung zu betreiben. Geht das (von Spezialfällen abgesehen) auch heute noch und wenn ja, was müsste man dafür ändern?

Hat vielleicht noch jemand ein potenziell für Spectre anfälliges System, das mit Kernel 2.4 (bis Sarge) lauffähig ist, auf dem er die Spectre-Attack-Demo mal testen könnte? Ich könnte das auf meinem Merom-Notebook versuchen. Das könnte für Sarge allerdings schon zu neu sein.

Oder bringe ich hier etwas durcheinander und schon mein theoretischer Ansatz ist fehlerhaft?


[1] https://www.mozilla.org/en-US/security/ ... sa2018-01/
[2] https://elinux.org/High_Resolution_Time ... _kernel.29

[RobertDebiannutzer]

Was ist eigentlich mit hidepid? Nützt das was?
Aus "man proc":

hidepid=n (since Linux 3.3)
This option controls who can access the information in /proc/[pid] directories. The argument, n, is one of the following values:

0 Everybody may access all /proc/[pid] directories. This is the traditional behavior, and the default if this mount option is not specified.

1 Users may not access files and subdirectories inside any /proc/[pid] directories but their own (the /proc/[pid] directories themselves remain visible). Sensitive files such as /proc/[pid]/cmdline and /proc/[pid]/status are now protected against other users. This makes it impossible to learn whether any user is running a specific program (so long as the program doesn't otherwise reveal itself by its behavior).

2 As for mode 1, but in addition the /proc/[pid] directories belonging to other users become invisible. This means that /proc/[pid] entries can no longer be used to discover the PIDs on the system. This doesn't hide the fact that a process with a specific PID value exists (it can be learned by other means, for example, by "kill -0 $PID"), but it hides a process's UID and GID, which could otherwise be learned by employing stat(2) on a /proc/[pid] directory. This greatly complicates an attacker's task of gathering information about running processes (e.g., discovering whether some daemon is running with elevated privileges, whether another user is running some sensitive program, whether other users are running any program at all, and so on).

[Ellison]

Hat vielleicht noch jemand ein potenziell für Spectre anfälliges System, das mit Kernel 2.4 (bis Sarge) lauffähig ist, auf dem er die Spectre-Attack-Demo mal testen könnte? Ich könnte das auf meinem Merom-Notebook versuchen. Das könnte für Sarge allerdings schon zu neu sein.

Wenn das bis zum Wochenende warten könnte, würde ich das mal probieren. Habe noch einen Amilo A 1640 mit Intel Sempron auf dem Dachboden. Der lief 2005/2006. Sarge habe ich noch auf DVD rumfliegen.

[inne]

Hallo

@Inne

aus dem @hikaru verlinkten Artikel von de Raadt:

"Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies – so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk," he said.

Danke! Also ist das broken by design und alle sind sehenden Auges ins Dilemma gelaufen, was wir nun haben...

[hikaru]

Wenn das bis zum Wochenende warten könnte, würde ich das mal probieren.

Spectre wird bis dahin nicht verschwunden sein.

Habe noch einen Amilo A 1640 mit Intel Sempron auf dem Dachboden. Der lief 2005/2006. Sarge habe ich noch auf DVD rumfliegen.

Sehr gut!
Falls da etwas anderes als eine 100%ige Erkennung des Opferstrings rauskommt, dann wäre ein Vergleich mit einem aktuellen Debian auf dem Gerät interessant, denn unter Stretch hatte ich ja auf dem Merom (übrigens ein Amilo Si 1520) nur eine ca. 50%ige Erkennung. Man müsste also ausschließen, dass ein möglicher Effekt von der CPU selbst herrührt, insbesondere, da sich ein AMD vielleicht ohnehin anders verhält als ein Intel.

Also ist das broken by design und alle sind sehenden Auges ins Dilemma gelaufen, was wir nun haben...

Könnte man so sehen. Das ist auch die einzige Grundlage, auf der ich mir Hoffnungen für einen Microcode-Fix für Sandy/Ivy Bridge mache.
Falls das Absicht war, dann wird vielleicht eine der Sammelklagen in den USA Erfolg haben, in deren Folge Intel dann in VW-Manier auch für ältere CPUs einen Fix für billiger hält als die Sache auszusitzen.

[Ellison]

Das ist auch die einzige Grundlage, auf der ich mir Hoffnungen für einen Microcode-Fix für Sandy/Ivy Bridge mache.

Dito. Mein X220 fällt, wenn das mit den 5 Jahren stimmt, was man aktuell so liest, dann auch hinten über. Bin ebenfalls Sandy geschädigt.

[inne]

Kann mir bitte jemand was zu diesen CPUs sagen. U.a. ob die gefixed werden? Betroffen ist der erste auf jedenfall, soweit ich gesehen habe wird die CPU im PDF genannt. Die microcode Pakete und aktuelle Kernel habe ich installiert.

Code: Alles auswählen

$ lscpu | grep "^Model name:"
Model name:          Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Code: Alles auswählen

$ ssh acme 'lscpu | grep "^Model name:"'
Model name:            Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz

// Ganz allgemein wäre am Ende, wenn das Thema durch ist ein Zusammenfassung für den Enduser interessant. Welche Hardware wurde gefixed, welche nicht und was kauft man in der Zukunft für Hardware.

[ingo2]

Check doch einfach mit dem neuesten "intel-microcode" und schau mit "dmesg" nach, welches Datum die Updates haben - sollt nach Juni 2016 liegen
Die 1. CPU ist ein Ivy-Bridge, die 2. ein Haswell