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

[TomL]

...in den Fuß schießt.

Welche Lösung gibts denn dafür? Ich weiss mir da keinen Rat mehr. Ich kann doch nur versuchen, meine Systeme so schlank wie möglich zu halten, sie möglichst logisch (Anwenderseits) zu isolieren, bei der Sofwareauswahl sehr kritisch zu sein und diese Vorsicht auch in mein Surfverhalten einzubringen. Das ist ja auch der Grund dafür, warum ich keine Standard-Desktops verwende, sonder einen ziemlich dünnen Eigenbau, der auf der Debian-Basis-Installation ohne GUI aufsetzt und nur das bereit hält, was wir tatsächlich nutzen. Aber ich stelle mir die Frage, wenn man sich doch angeblich sowieso nicht schützen kann, ob die Aufregung um diesen einen neuen (von vielen alten) Bug nicht völlig sinnlos ist... weil man eh nix am Dilemma ändern kann? Und das will ich noch nicht glauben.

[DeletedUserReAsG]

Natürlich ist’s vollkommen falsch, mit „ach, da könnten eh so viele andere Bugs drin sein, da interessiert mich der Eine nun auch nicht mehr“ anzukommen. Richtig ist, zuzusehen, dass die Updates zeitnah eingespielt werden und dass ggf. möglicherweise bereits kompromittierte, sensible Daten ausgetauscht werden (etwa Schlüssel für VPN und so …). Viel mehr wird man als Anwender auch nicht machen können, aber das Wenige sollte man dann doch schon machen.

[guennid]

Ich baue mir meine Vanilla-Kerne meistens selbst. Wenn ich da auf S.8 was Richtiges aufgeschnappt habe, dann sollte das Kernel-Modul PAGE_TABLE_ISOLATION fest einkompiliert sein. Und wenn ich weiter recht sehe, dann funktioniert das nur mit x86_64. (Sourcen 4.14.12) Aber in den Sourcen für 4.9 (LTS) sehe ich das gleiche.

Code: Alles auswählen

Symbol: PAGE_TABLE_ISOLATION [=n]
Type  : boolean
Prompt: Remove the kernel mapping in user mode
Location:
  (1) -> Security options
   Defined at security/Kconfig:57
   Depends on: X86_64 [=n] && !UML

Ich würde gern den Kern für diese Maschine anpassen:
cat /proc/cpuinfo:

Code: Alles auswählen

model name	: Intel(R) Atom(TM) CPU N270   @ 1.60GHz

Dann funktioniert das wohl nicht.
Ist diese CPU eigentlich betroffen?

[jue]

Ist diese CPU eigentlich betroffen?

Nix genaues weiß man nicht, aber ich meine, diese CPU ist nicht betroffen. Siehe oben.

[guennid]

"oben" ist ziemlich dehnbar, bei mittlerweile neun Seiten. Kannst du vielleicht die Seite angeben, auf der ich deine Stelle finde? Ich habe mir auch schon mal die im Netz veröffentlichte Intel-Liste angesehen, habe ich aber auf meine Verhältnisse nicht anzuwenden vermocht.

[jue]

"oben" ist ziemlich dehnbar, bei mittlerweile neun Seiten.

ja, klar - sorry. Hier ein Link:
https://www.heise.de/newsticker/meldung ... 34667.html

[guennid]

Tja, was hab' ich denn da jetzt für eine "Serie"?

[jue]

Tja, was hab' ich denn da jetzt für eine "Serie"?

N = Nettop-Atom?

[guennid]

Wie sagtest du oben: Nix Genaues weiß man nicht! Aber "N" scheint nicht unplausibel! Vielleicht kommt noch jemand, der mehr weiß.

[dufty2]

Die Atoms, welche zwischen 2008 und 2011 hergestellt wurden, gehören zu den legacy CPUs:
https://ark.intel.com/products/series/1 ... Processors
Man erkennt sie z. B. daran, dass sie nur 3 Ziffern haben.
Dazu gehört Dein N270 von 2008, die Serie lief unter dem codename "diamond".
Mein Atom N450 von 2010 ist ein bischen neuer (codename "pineview"), kann z. B. 64Bit, aber auch nix besonderes.

Die im heise-Artikeln aufgeführten betroffenen Atoms sind neueren Datums, z. B. ein Atom C2338 von 2013.
(die haben dann 4 Ziffern: 2338).

Vgl. auch https://en.wikipedia.org/wiki/List_of_I ... processors

[ingo2]

Nochmal eine Frage, speziell zu spectre:

Da stehen ja diverse Patches an verschiedenen Stellen an, u.a. auch dem Microcode.
Da wird bei Debian schon eifrig gewerkelt: https://packages.qa.debian.org/i/intel-microcode.html

jetzt die Frage: wie kommt das Paket intel-microcode denn auf meinen PC?
Bisher habe ich davon keines installiert, obwohl das derzeit aktuellste von Intel: https://downloadcenter.intel.com/downlo ... -Data-File ja doch recht neu ist und einen Blob für meinen i5-3570K enthält.
Wird dieses Microcode-Update dann über debian-security automatisch (z.B. als "required") installiert, obwohl es bisher nicht installiert war?
So eine Situation hatte ich bisher ja noch nicht - oder?

[jue]

jetzt die Frage: wie kommt das Paket intel-microcode denn auf meinen PC?

Code: Alles auswählen

apt-get install intel-microcode

[dufty2]

Die microcode-updates helfen für den Spectre-II, m.W. aber nicht für den Spectre-I-Angriff.
intel-microcode gehört zu "non-free" und ich wüsste nicht, wie z. B. ich - welcher nur "main" in seiner /etc/apt/sources.list hat,
automatisch das Teil geladen bekommt, wenn man es nicht selbst installiert

Helfen tut übrigens nur das von 20171215, auf der Intel-Seite wird leider nur das von November angegeben

[smutbert]

Es existiert auch schon vor Sprectre und Meltdown eine große Menge an Fehlern unter denen man leiden könnte, wenn man intel-microcode (oder bei AMD-CPUs amd64-microcode) nicht installiert hat, aber nachdem das unfreie Updates sind wird Debian sie bestimmt nicht per Default irgendwo installieren - die muss man schon selbst installieren.
Obendrein werden diese Updates ja auch von neueren BIOS/UEFI-Versionen geladen (wenn der Mainboardhersteller ein solches BIOS-Update bereitstellt) und die Updates können meines Wissens auch bereits in grub geladen werden.

[reox]

Weiß eigentlich wer was zu den AMD CPUs? insbesondere AMD G-T40E, AMD Turion(tm) II Neo N54L und AMD E-350?
Ich versteh diesen Artikel: https://www.amd.com/en/corporate/speculative-execution so, dass nur Variante I funktioniert und die durch den Kernel gepatched wird - dafür aber alle (?!) AMD CPUs betrifft?

[ingo2]

Obendrein werden diese Updates ja auch von neueren BIOS/UEFI-Versionen geladen (wenn der Mainboardhersteller ein solches BIOS-Update bereitstellt) und die Updates können meines Wissens auch bereits in grub geladen werden.

Ich bezweifle aber, dass Intel für mein fast 6 Jahre altes MoBo DH77EB noch BIOS-Updates liefern wird. Da bleibt doch wohl nur das Laden des gefixten Microcodes per GRUB.

[dufty2]

Weiß eigentlich wer was zu den AMD CPUs? insbesondere AMD G-T40E, AMD Turion(tm) II Neo N54L und AMD E-350?
Ich versteh diesen Artikel: https://www.amd.com/en/corporate/speculative-execution so, dass nur Variante I funktioniert und die durch den Kernel gepatched wird - dafür aber alle (?!) AMD CPUs betrifft?

Und wieder empfehle ich den "telekom-artikel" https://imagefactory.otc.t-systems.com/ ... pecExLeak/

Spectre-I ist insofern der "schlimmste", da es schon horror-meldungen gab, das nur mit einen speciellen gcc die komplette distri neu durch-kompiliert werden muss.
Wir werden sehen

[hikaru]

Letztendlich beruhen die beiden erwähnten proggies auf dem im
https://spectreattack.com/spectre.pdf
angegebenen Programm im Anhang "A Spectre Example Implementation".
Das habe ich mal sauber raus-kopiert aus dem PDF und lässt sich auf einen Atom N450 auch sauber kompilieren:

Code: Alles auswählen

$ gcc -std=c99 -O0 spectre.c -o spectre
$ ./spectre 
Reading 40 bytes:
Ungültiger Maschinenbefehl

Das Problem ist 'rdtscp', das es erst ab Nehalem-CPUs gibt (glaube ich).
In den Beispielen wird das durch 'rdtsc' ersetzt und nun geht die Ausführung.
Brauchbare Ergebnisse erhalte ich dann aber auch nicht,
bin aber viel zuwenig in der Thematik drin, ob die "rdtscp=>rdtsc"-Ersetzung noch den "korrekten" Exploit für Atom-CPUs (und älter) darstellt resp. - wie von jue erwähnt - auf Atoms gar nicht gehen würde.

Mit der Änderung von rdtscp zu rdtsc (Danke für den Hinweis) konnte ich das Programm auf Merom (T7600; 2,33GHz Dual-Core; 3GB RAM) und Penryn (Q9550; 2,8GHz-Quad-Core; 6GB RAM) kompilieren und erhielt auch halbwegs brauchbare Ergebnisse.
"Halbwegs", weil nur ein Teil des Opferstrings korrekt decodiert werden konnte. Beim Merom war es etwa die Hälfte, beim Penryn ein Viertel. Die Teile die decodiert werden konnten änderten sich von Durchlauf zu Durchlauf. Die ersten 2-4 Zeichen des Opferstrings schienen mir dabei leicht überdurchschnittlich oft erraten worden zu sein.


Hat jemand technisch gehaltvolle Infos zu den Spectre-Fixes?
Ich war am Wochenende mal wieder hinter'm Mond und bin daher nicht ganz auf dem Laufenden. Ich habe nur mitbekommen, dass es da wohl irgendwelche Fortschritte gab.

Nun ist es zwar ganz nett, Meldungen im BIOS-Update-Stil zu lesen ("Wir haben Problem X behoben, verraten aber nicht wie."), aber ich hätte doch schon gern eine technische Erklärung, wie genau verhindert wird, dass Prozess A die Zugriffzeiten von durch Prozess B spekulativ geänderten Speicher misst.

[hikaru]

Darauf, dass Out-of-Order-Execution potenziell gefährlich sein kann, möchte ein Professor der Columbia-Universität schon 2012 hingewiesen haben. [1]

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.

Edit (Gestrichenes s.):
viewtopic.php?f=37&t=168134&start=150#p1160009


[1] https://twitter.com/TheSimha/status/949361495468642304

[dufty2]

Mit der Änderung von rdtscp zu rdtsc (Danke für den Hinweis) konnte ich das Programm auf Merom (T7600; 2,33GHz Dual-Core; 3GB RAM) und Penryn (Q9550; 2,8GHz-Quad-Core; 6GB RAM) kompilieren und erhielt auch halbwegs brauchbare Ergebnisse.
"Halbwegs", weil nur ein Teil des Opferstrings korrekt decodiert werden konnte. Beim Merom war es etwa die Hälfte, beim Penryn ein Viertel. Die Teile die decodiert werden konnten änderten sich von Durchlauf zu Durchlauf. Die ersten 2-4 Zeichen des Opferstrings schienen mir dabei leicht überdurchschnittlich oft erraten worden zu sein..

Das C-Programm gehört also zum Spectre-1, CVE-2017-5753, richtig?
Da Merom/Penryn aus der prä-Nehalem-Ära stammen, also zu "Intel Core 2"-Familie, dann bildet die Intel-Seite tatsächlich nur Spectre-2, CVE-2017-5715 betroffene CPUs ab, denn die "Intel Core 2" taucht ja da gar nicht auf.

[hikaru]

Das C-Programm gehört also zum Spectre-1, CVE-2017-5753, richtig?

Meinem Verständnis nach, ja.

Auf meinem Sandy-Bridge funktioniert das ursprüngliche C-Programm übrigens vorzüglich. Der gesamte Opferstring wird ausgelesen, zusätzlich noch ein Teil des funktionalen Codes: 40120
Ersetze ich rdtscp gegen rdtsc kommt hingegen nur Müll raus: 40121

Auf meinem T530 mit i5-3360M (Ivy Bridge) sieht die Sache ganz genauso aus. Dabei war jeweils intel-microcode aus Sid bereits installiert, wo ja zumindest für einige CPUs schon Spectre-Fixes drin sein sollen. Allerdings soll das wohl erst ab Haswell gelten. [1] Da kann ich als Hobby-IT-Archäologe nur hoffen, dass Intel irgendwann aus dem Tee kommt und auch mir großzügig diesen undokumentierten BLOB zukommen lässt, von dem ich noch vor zwei Wochen überzeugt war, ihn gar nicht zu brauchen.

Ein Nehalem wäre jetzt bezüglich der rdtsc/rdtscp-Thematik möglicherweise noch interessant.


[1] https://www.golem.de/news/spectre-und-m ... 31981.html

[ingo2]

Auf meinem T530 mit i5-3360M (Ivy Bridge) sieht die Sache ganz genauso aus. Dabei war jeweils intel-microcode aus Sid bereits installiert, wo ja zumindest für einige CPUs schon Spectre-Fixes drin sein sollen. Allerdings soll das wohl erst ab Haswell gelten.

Habe hier auch eine Ivy-Bridge. Ob du den Patch schon in dem sid-Paket auch dafür hast, ganz einfach:

Code: Alles auswählen

# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26

Das ist der BLOB aus stable. Das Datum, welches da genannt wird, ist das Release-Datum von Intel - habe ich so gelesen, frag bitte nicht, wo - ist aber logisch. Und BIOS-Updates für mein MoBo haben die auch 2014 engestellt - toller Service, nicht wahr

[hikaru]

Ob du den Patch schon in dem sid-Paket auch dafür hast, ganz einfach:

Code: Alles auswählen

# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26

Das ist der BLOB aus stable. Das Datum, welches da genannt wird, ist das Release-Datum von Intel - habe ich so gelesen, frag bitte nicht, wo - ist aber logisch. Und BIOS-Updates für mein MoBo haben die auch 2014 engestellt - toller Service, nicht wahr

Vom Sandy-Bridge-Desktop:

Code: Alles auswählen

# dpkg -l | grep microcode
ii  intel-microcode                       3.20171215.1                               amd64        Processor microcode firmware for Intel CPUs
ii  iucode-tool                           1.1.1-1                                    amd64        Intel processor microcode tool
# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x29, date = 2013-06-12
[    0.805066] microcode: sig=0x206a7, pf=0x2, revision=0x29
[    0.805354] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Ganz toll!

[rwkraemer]

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.

Edit: Habe ein Video enteckt, indem die Sachlage auch für Laien verständlich erklärt wird: https://www.youtube.com/watch?v=ZkLjMm7Nu7s

[Colttt]

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

Wenn nicht, ob's da jetzt nen Run drauf gibt?