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

[katzenfan]

Wie läßt sich denn herausbekommen, wann welche Prozessoren auf den Markt gekommen, bzw. in PC verbaut worden sind?

[dufty2]

Wie läßt sich denn herausbekommen, wann welche Prozessoren auf den Markt gekommen, bzw. in PC verbaut worden sind?

Warum ist das für die Lückenbehebung wichtig?
Anyway, Du machst auf Deiner Kiste ein

Code: Alles auswählen

$ cat /proc/cpuinfo | grep "model name"

postest die Ausgabe in die Suchmaschine Deiner Wahl und erhälst (im Falle von harakiri):
https://ark.intel.com/products/53442/In ... e-2_40-GHz
Dort sehen wir,
dass die CPU Q1'12 ge-lancht wurde, also jetzt 6 Jahre alt ist.

[dufty2]

So, das update für meltdown für testing, ähem sid, ist da:

Code: Alles auswählen

# uname -a
Linux host 4.14.0-3-amd64 #1 SMP Debian 4.14.12-1 (2018-01-05) x86_64 GNU/Linux
# grep -i CONFIG_PAGE_TABLE_ISOLATION /boot/config-*
/boot/config-4.14.0-3-amd64:CONFIG_PAGE_TABLE_ISOLATION=y
# dmesg | grep -i isolation
[    0.000000] Kernel/User page tables isolation: enabled
# cat /proc/cpuinfo | grep bugs
bugs		: cpu_insecure
bugs		: cpu_insecure

Hey, mein Atom ist doch gar nicht betroffen!

[schorsch_76]

Bei Heise [1] gibt es eine schöne verständliche Beschreibung was eigentlich passiert.

[1] https://heise.de/-3935124

[reox]

Ein Xeon von mir wird bei Intel genannt, aber bei bugs steht nix... Das spectre tool hab ich dort auch erfolgreich testen können... Also ganz funktionieren tuts wohl nicht?

[dufty2]

Ein Xeon von mir wird bei Intel genannt, aber bei bugs steht nix... Das spectre tool hab ich dort auch erfolgreich testen können... Also ganz funktionieren tuts wohl nicht?

Wie? Was? Wo? Wovon sprichst Du?
"bei Intel genannt": ist der o. g. Link von Intel bei aufgeführten CPU-Typen mit aufgeführt?
"Das sprectre tool": ist das Programm aus dem Anhang des spectre.pdf von G**gle?
Und was soll jetzt nicht funktionieren?
Welche kernel-Version verwendest Du überhaupts?

die "bugs: cpu_insecure" ist beim 4.14.11/.12 mit dabei, weiß nicht, ob sie in den
4.9er und 4.4er auch zurückportiert haben.
Das PTI/Kaiser schützt derzeit nur vor dem Meltdown-Attack,
für den Spectre sind sie noch am Tüfteln.

[katzenfan]

Warum ist das für die Lückenbehebung wichtig?

Beziehe mich bei meiner Frage auf Absatz 2 des folgenden heise-Artikels:

https://www.heise.de/newsticker/meldung ... 34667.html

[reox]

Ein Xeon von mir wird bei Intel genannt, aber bei bugs steht nix... Das spectre tool hab ich dort auch erfolgreich testen können... Also ganz funktionieren tuts wohl nicht?

Wie? Was? Wo? Wovon sprichst Du?
"bei Intel genannt": ist der o. g. Link von Intel bei aufgeführten CPU-Typen mit aufgeführt?

Sorry
Ja, gibt ja derzeit nur ein Security advisory von denen, oder? Also Konkret dieses hier: https://security-center.intel.com/advis ... geid=en-fr
wobei ja dort explizit nur CVE-2017-5715 genannt wird und CVE-2017-5753 sowie CVE-2017-5754 als Varianten. Letzteres ist Meltdown.
Und nur letzteres ist ja von dem Patch im Kernel überhaupt (teilweise) mitigiert: https://security-tracker.debian.org/tra ... kage/linux

"Das sprectre tool": ist das Programm aus dem Anhang des spectre.pdf von G**gle?
Und was soll jetzt nicht funktionieren?
Welche kernel-Version verwendest Du überhaupts?

Ja, bzw auch hier ohne es aus dem PDF zu kopieren: https://gist.github.com/ErikAugust/724d ... 2a9e3d4bb6
Ich war der Meinung, dass cpu_insecure gleichzusetzen ist mit dem erfolgreichen ausführen dieses tools - daher hatte es mich gewundert, dass ich cpu_insecure nicht sehe aber das Tool geht...

die "bugs: cpu_insecure" ist beim 4.14.11/.12 mit dabei, weiß nicht, ob sie in den
4.9er und 4.4er auch zurückportiert haben.

... was gut sein kann, denn ich verwende den stable kernel 4.9.65-3+deb9u2
Mit dem Kernel:

Code: Alles auswählen

$ egrep (bugs|model name) /proc/cpuinfo | sort -u 
bugs		:
model name	: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz

Gegen CVE-2017-5715 gibt es ja teilweise Microcodes, so wie mir scheint aber nur für neuere Prozessoren...

edit: mit dem 4.14.12-1 auf meiner Workstation sehe ich das cpu_insecure.

[dufty2]

Warum ist das für die Lückenbehebung wichtig?

Beziehe mich bei meiner Frage auf Absatz 2 des folgenden heise-Artikels:

https://www.heise.de/newsticker/meldung ... 34667.html

Ok, also vermutlich auf den Satz: umfasst dabei sämtliche Prozessoren der Intel-Core-Generation (seit 2008)

Wie reox gerade eben schon daraufhingewiesen hat, bezieht sicht die Intel-Note eigentlich nur auf Spectre(-I) (und nicht auch auf Meltdown, wie im Heise-Artikel angegeben).
Die Verwirrung kommt evtl. daher, dass ein "Intel Core 2" keine "2nd generation Intel® Core™ processors" ist,
die Families kannst Du hier einsehen:
https://www.intel.com/content/www/us/en ... mbers.html

Ich mach's mir einfach und sage "ab Nehalem".
Die Nehalems haben auch den auf der vorigen Seite erwähnten Maschinenbefehl,
welcher mein Atom, obwohl von 2010, gar nicht kennt.

[dufty2]

Was mich recht verwirrt, ist der Artikel von Red Hat:
https://access.redhat.com/articles/3311301
Der macht den Eindruck, als hätten sie alles schon gepatcht:
Spectre-I und Spectre-II und Meltdown.

Bisher war mein Verständnis eher dem der Telekom angelegt:
https://imagefactory.otc.t-systems.com/ ... pecExLeak/
insbesondere der dort aufgeführten Tabelle mit der Mitigations.

Das jetzt Red Hat Spectre-I mit einen einzigen Kernel-patch erschlägt, mmh.

[reox]

Naja sie sagen ja, dass für die Spectre #2 auch Microcode patches benötigt werden. Heißt vermutlich soviel wie: Die paar CPUs die gepatched wurden sind jetzt sicher, der große rest nicht.

edit:

Die US-Firma will bis zum Ende der ersten Jänner-Woche einen Fix für mehr als 90 Prozent der Prozessoren liefern

siehe http://derstandard.at/2000071595567/CPU ... huetzt-ist

Na da bin ich gespannt...

[Harakiri]

Anbei ein interessanter Blogeintrag vom Kernelentwickler Greg Kroah-Hartman zum aktuellen Stand der Dinge.

http://kroah.com/log/blog/2018/01/06/meltdown-status/

[dufty2]

Anbei ein interessanter Blogeintrag vom Kernelentwickler Greg Kroah-Hartman zum aktuellen Stand der Dinge.

http://kroah.com/log/blog/2018/01/06/meltdown-status/

Danke für Link!
War interessant.

[ingo2]

Anbei ein interessanter Blogeintrag vom Kernelentwickler Greg Kroah-Hartman zum aktuellen Stand der Dinge.
http://kroah.com/log/blog/2018/01/06/meltdown-status/

Danke für den Link, das ist eigentlich das was einen normalen User wie mich interessiert!
Was noch interessant wird, ist, welch Konsequenzen das nach sich ziehen wird, sowohl juristisch als auch technisch für zukünftige CPU-.Generationen.

Debian Stretch:

cat /boot/config-4.9.0-5-amd64 | grep PAGE_TABLE
CONFIG_PAGE_TABLE_ISOLATION=y

Für Jessie sieht es danach wohl nicht so gut aus? Auch ein kernel aus backports wird da nicht besser dran sein?

[rendegast]

Für Jessie sieht es danach wohl nicht so gut aus? Auch ein kernel aus backports wird da nicht besser dran sein?

https://packages.debian.org/linux-image-4.9.0-0.bpo
linux-image-4.9.0-0.bpo.5 bislang auch nur für amd64

[whiizy]

Vielen Dank für die Info!
Hat den Backport-Kernel für Jessie schon jemand installiert?
Keine Probleme damit gehabt? (bei mir läuft unter Jessie bisher üblicherweise der normale Jessie-Kernel).

[buhtz]

Es wird ja nun geraten, alle Accounts bzw. Passwörter als kompromitiert anzusehen und diese entsprechend zu ändern.

Meine Frage wäre, ob jetzt nicht noch etwas zu früh ist. Müsste man nicht auf einen Fix (wie auch immer der aussieht) warten, bevor man alle Passwörter ändert?

[reox]

Es wird ja nun geraten, alle Accounts bzw. Passwörter als kompromitiert anzusehen und diese entsprechend zu ändern.

Müsste man nicht auch alle GPG und SSH Keys als kompromitiert ansehen? Das würde auch heißen, es sind alle Rechner die mit den SSH Keys zugänglich sind bereits kompromitiert. Und wenn GPG Keys kompromitiert wurden, wer sagt dann, dass die Updates tatsächlich Updates sind?

[TomL]

Es wird ja nun geraten, alle Accounts bzw. Passwörter als kompromitiert anzusehen und diese entsprechend zu ändern.

Müsste man nicht auch alle GPG und SSH Keys als kompromitiert ansehen?

Durch wen kompromittiert? Ist es bei diesem Bug nicht ein bisschen so ähnlich, wie es bei einem Auto wäre, wenn wg. einem Steuerelektronik-Bug die Seitenscheibe runterfährt, wenn man außen auf den rechten Blinker klopft ...?... und das erst dann wirklich eine Gefahr für die in der Mittelkonsole liegenden Brieftasche besteht,wenn ein Dieb ins Auto reingreift? Und ist es nicht auch so ähnlich, dass die offene Scheibe nicht so wirklich kritisch ist, wenn das Auto gerade in der verschlossenen Garage steht.... so ähnlich wie sich mein PC hinter einem Router befindet und von mir deshalb und auf Grund meiner sonstigen Sorgfalt als sauber und unkompromittiert eingeschätzt werden kann.... trotz vielleicht manchmal "offener Scheibe"?

[reox]

Ah sorry, glaube ich hatte da was missverstanden. Es kann ja nur aus dem Addressraum des Prozesses extrahiert werden, der angegriffen wird. Also wenn man annimmt, dass bereits JS Angriffe laufen, so würde es höchstens den Browser betreffen. Dort sollten ja keine GPG oder SSH Keys liegen.

[buhtz]

Durch wen kompromittiert? Ist es bei diesem Bug nicht ein bisschen so ähnlich, wie es bei einem Auto wäre, wenn wg. einem Steuerelektronik-Bug die Seitenscheibe runterfährt, wenn man außen auf den rechten Blinker klopft ...?... und das erst dann wirklich eine Gefahr für die in der Mittelkonsole liegenden Brieftasche besteht,wenn ein Dieb ins Auto reingreift?

Wenn die Brieftasche weg ist, merkst du es aber. Bei Daten ist das anders. Ob die jemand gezogen hat kannst du (i.d.R.) nicht nachvollziehen.

[TomL]

Ah sorry, glaube ich hatte da was missverstanden. Es kann ja nur aus dem Addressraum des Prozesses extrahiert werden, der angegriffen wird. Also wenn man annimmt, dass bereits JS Angriffe laufen, so würde es höchstens den Browser betreffen.

Ich habe das auch so verstanden. Mein Server kennt kein Java, keinen Browser, kein Desktop-Environment, keine Anwendersoftware. Also, selbst wenn er diesen CPU-Bug hat, wo ist da ein Angriffsszenario? Da laufen nur die benötigten Dienste drauf.... wenn ich also von einer bereits erfolgten Kompromittierung ausgehe, müsste ich unterstellen, dass Samba, Cups, OpenVPN, systemd-* ... also einer von diesen Kandidaten meine GPG-Passwörter grapscht, wenn mein Script meine zu sendende Datei mit GPG verschlüsselt. Also wenn das wirklich so wäre, dann kann ich doch auch sofort alle Ports im Router öffnen... macht ja dann auch keinen Unterschied mehr.... oder?

@buhtz
Egal ob Brieftasche oder Daten... es MUSS den Dieb geben, der zufällig auch genau diese Lücke bei MIR ausnutzt. Ohne Dieb kein Schaden ...und solange der Dieb sich nicht bereits auf meinen Rechner befindet (oder IN meiner Garage), sehe ich da auch keine gravierende Gefahr. Bitte lies noch mal, was ich geschrieben habe....

[DeletedUserReAsG]

Du gehst davon aus, dass die Software auf deinen Kisten jetzt und für immer sicher ist. In der Vergangenheit wurden auch in etablierten Sachen Sicherheitslücken gefunden und es wäre doch sehr naiv, anzunehmen, dass jetzt keine Fehler mehr drin wären. Ein Angreifer (viele stellen sich da ’nen Typen vor, der aktiv auf das Ziel zugreifen muss – tatsächlich sind’s Scripte/Bots, die massenhaft Maschinen automatisiert abgrasen) muss nur einmal in die Lage kommen, Code etwa im Kontext des Webservers auszuführen, und könnte dann u.U. den privaten Schlüssel für dein TLS abgreifen, oder Schlüssel für evt. verschlüsselte Partitionen, oder was auch immer. Wenn einen Tag später ein Patch für die genutzte Lücke kommt, hat der trotzdem noch die Schlüssel – oder generierst du die nach jedem Update neu?

[TomL]

Nein, ich gehe nicht davon aus, dass meine Rechner keine Sicherheitslücken haben... im Gegenteil, als Entwickler weiss ich, dass es fast unmöglich ist, fehlerfrei zu programmieren. Unter ich stelle mir auch keinen Typen vor, der irgendwo auf der Welt sitzt und sich gerade in mein System hackt. Ich weiss, dass das alles nur irgendwelche Bots sind, die quasi "mechanisch" die große Weide abgrasen, auf der Suche nach offenen Eingängen in irgendwelche Karnickelbauten.
Aber auch Du führst ein Beispiel an, was darauf basiert, dass schon vorher konkrete Türen bereit gehalten sind, durch die erst vorhandene Schwächen ausgenutzt werden können... und zwar den Webserver. Dieser Webserver ist doch eine der möglichen Grundlagen, die solche Angriffszenarien erst ermöglichen. Bei mir gibts aber nur einen einzigen offenen Port, und zwar für OpenVPN. Ich will das nicht verharmlosen, aber soweit ich das jetzt verstanden habe, bedarf es auch zwingend begünstigende Umstände, dass dieser Bug überhaupt genutzt werden kann... und die Tatsache, dass bereits Schadsoftware vorher schon eingeschleust war. Wenn man der Meinung ist, dass man keine begünstigenden Umstände geschaffen hat und auch keine Schadsoftware bereits installiert ist, ist meiner Meinung nach die Gefahr zwar vorhanden, aber individuell dann auch wieder eher unwahrscheinlich.

Ist das falsch?

Ich glaube, was uns viel mehr Sorge machen sollte, sind die Prozessoren in den Customer-Routern... denn bei dem handelt es sich um ein echtes Border-Device... und wenn da in der CPU das PWD vom Router drinsteht... und der hat ein Web-Interface.... auweia....

[DeletedUserReAsG]

Nein, ist nicht falsch, soweit ich das verstanden habe. Es ist halt nur so, dass auch auf ’nem eigentlich recht gut abgeschotteten System, „ohne Anwendersoftware“, eine Masse an Software vorhanden ist und teils läuft, und es keine Garantie geben kann, dass nicht bereits entsprechende Angriffe gelaufen, oder auch nur vorbereitet worden sind.

Ist einfach zuviel, das heutzutage auch auf ’nem „schlanken” System läuft, als dass jemand alles untersuchen und mit Sicherheit sagen könnte, dass da nix ausnutzbar kaputt wäre. Deswegen sehe ich „aber ich hab doch nur das eine da laufen, da bin ich doch sicher“ als problematisch an, und weise drauf hin, dass man sich mit dieser Einstellung u.U. in den Fuß schießt.