expertenaustausch > comp.* > comp.security.misc

Ulrich Maier (10.01.2018, 18:26)
Während sich die Nachrichten zu Meltdown und Spectre überschlagen und
ausgiebig darüber diskutiert wird, ob auch alte Pentium-Prozessoren
betroffen sind, die niemand mehr benutzt, hinterfragt niemand die reale
Gefährdung durch den angeblichen Supergau des Jahrhunderts.

Ich habe folgende beiden sehr guten Artikel gefunden:
- zu Meltdown:
- zu Spectre:

Meltdown: "We achieved average reading rates of up to
503 KB/s with an error rate as low as 0.02 % when using
exception suppression. For the performance evaluation,
we focused on the Intel Core i7-6700K..."

Spectre: "The unoptimized code in Appendix A reads approximately
10KB/second on an i7 Surface Pro 3."

Für eine Attacke muss man auf meinem Rechner überhaupt erst einmal ein
Programm zum Laufen bringen. In den vergangenen 20 Jahren hat das noch
keine Malware geschafft. Dann zieht es meine ca. 6 GB Hauptspeicher mit
einer Speed von 0,5 MB/s (Meltdown) bzw. vielleicht (optimiert) bis zu
0,05 MB/s ab. Mit dieser Speed lassen sich nicht ansatzweise die Daten
auslesen, die über CPU und Hauptspeicher rauschen, selbst wenn es
gelingt, sich auf interessante Datenbereiche zu beschränken.

Um an sinnvolle Daten heranzukommen, müsste man die Struktur der Daten
erkennen, um dann gezielt nach konkreten Daten suchen zu können. Aber
auch dann werden die Daten kaum so lange warten, bis sie abgeholt werden.

Ist unter diesen Umständen ein konkretes Angriffsszenario vorstellbar?

Tut man nicht am besten daran, die Patches, mit denen wir demnächst
zwangsbeglückt werden, gleich wieder abzuschalten, um sich unnötiger
Bremsen zu entledigen?

Was mich stutzig macht, ist, dass selbst die Hersteller die Prügel
klaglos einstecken - oder freuen die sich nur klammheimlich auf das
bevorstehende Ersatzgeschäft?

Ulrich
Chr. Maercker (11.01.2018, 10:12)
Ulrich Maier wrote:
> Während sich die Nachrichten zu Meltdown und Spectre überschlagen und
> ausgiebig darüber diskutiert wird, ob auch alte Pentium-Prozessoren
> betroffen sind, die niemand mehr benutzt, hinterfragt niemand die reale
> Gefährdung durch den angeblichen Supergau des Jahrhunderts.


Doch, ich hab mich anfangs gefragt, wie man an den Microcode von
Prozessoren rankommt, geschweige denn, ihn ändern könnte. Der ist nicht
unbedingt in Flash-PROMs etc. untergebracht. Das Vorhandensein
privilegierter Befehle eröffnet freilich gewisse Möglichkeiten, deren
sinnvolle bzw. missbräuchliche Nutzung jedoch (vorläufig) absoluten
Kennern des jeweils benutzten Betriebssystem vorbehalten bleibt.

> Ich habe folgende beiden sehr guten Artikel gefunden:
> - zu Meltdown:
> - zu Spectre:


Dito. Aber noch nicht zu Ende gelesen.

> Meltdown: "We achieved average reading rates of up to
> 503 KB/s with an error rate as low as 0.02 % when using
> exception suppression. For the performance evaluation,
> we focused on the Intel Core i7-6700K..."
> Spectre: "The unoptimized code in Appendix A reads approximately
> 10KB/second on an i7 Surface Pro 3."


> Für eine Attacke muss man auf meinem Rechner überhaupt erst einmal ein
> Programm zum Laufen bringen.

^^^^^^
Das soll tatsächlich schon gelungen sein, McMurphy zufolge aber sehr
selten. ;-)

> In den vergangenen 20 Jahren hat das noch keine Malware geschafft.


Auf *Deinem* Rechner, nehme ich an. Womöglich arbeitet der mit Linux?
Auf meinen diversen PCs isses einmal passiert, da war irknwie was bei
einem Malware-Test aus dem Ruder gelaufen. Und zu DOS-Zeiten hatte ich
WIMRE einmal Yankee-Doodle an Bord, Infektion via Server.

> Dann zieht es meine ca. 6 GB Hauptspeicher mit
> einer Speed von 0,5 MB/s (Meltdown) bzw. vielleicht (optimiert) bis zu
> 0,05 MB/s ab. Mit dieser Speed lassen sich nicht ansatzweise die Daten
> auslesen, die über CPU und Hauptspeicher rauschen, selbst wenn es
> gelingt, sich auf interessante Datenbereiche zu beschränken.


> Um an sinnvolle Daten heranzukommen, müsste man die Struktur der Daten
> erkennen, um dann gezielt nach konkreten Daten suchen zu können. Aber
> auch dann werden die Daten kaum so lange warten, bis sie abgeholt werden.
> Ist unter diesen Umständen ein konkretes Angriffsszenario vorstellbar?


Ähnliche Fragen stellen sich mir schon bei den ach so einfachen Buffer
Overflows. OK, man kann damit Schadcode in RAM-Bereiche einlagern, auf
die eigentlich kein Zugriff bestehen sollte, aaaber: wie ermittle ich in
einem System, das RAM völlig dynamisch zuteilt, die genaue Adresse und
vor allem wie bringe ich einen Rechner dazu, genau dorthin zu springen
und den Müll zu starten???
Was ich bisher in der Praxis gesehen habe, war deutlich einfacher gestrickt:
0. Dateiviren (Historia)
1. Macroviren
2. DAUs, die auf jeden, aber auch jeden Mailanhang klicken
3. stinkig verscriptete Webseiten, leider auch bei seriösen Sites üblich
und damit durch NoScript etc. kaum abzuwehren
4. Runterladen des Schadcodes mittels Javascript etc. Setzt Hauptursache
Nr. zwei voraus.
5. Würmer via Netzwerk (vor allem die benötigen echte Schwachstellen)
6. versaute CDs, DvDs, USB-Sticks, zusammen mit erlaubtem Autorun
Viel mehr war's nicht.

Ursache 1, 3 und 6 sind Folge meist überflüssiger "Features".

> Tut man nicht am besten daran, die Patches, mit denen wir demnächst
> zwangsbeglückt werden, gleich wieder abzuschalten, um sich unnötiger
> Bremsen zu entledigen?


Die bremsen beileibe nicht alle. Einzelne leider umso stärker und die
muss man erst mal ermitteln. Heftigst aufgefallen ist das bei WinXP,
aber ich hab nie rausbekommen, welche(r) HotFix(e) es war.

> Was mich stutzig macht, ist, dass selbst die Hersteller die Prügel
> klaglos einstecken - oder freuen die sich nur klammheimlich auf das
> bevorstehende Ersatzgeschäft?


Außerdem isses nicht nur *ein* Hersteller, die Konkurrenz trifft's also
auch. Bei KRACK hat auch niemand aufgeschrien, weil der Fehler den
Grundalgorythmus betrifft. Die aktuelle Schwachstelle ist ebenfalls
ziemlich grundlegender Natur und betrifft *deswegen* nicht nur den
Platzhirsch.
Andreas Kohlbach (11.01.2018, 22:49)
On Thu, 11 Jan 2018 10:12:31 +0100, Chr. Maercker wrote:
> Doch, ich hab mich anfangs gefragt, wie man an den Microcode von
> Prozessoren rankommt, geschweige denn, ihn ändern könnte.


Microcode?

Also hier in Debian Linux gibt es Microcode Dateien für die
verschiedensten Prozessoren. Ich musste den für AMD hier installieren, da
ich sonst nur Schnee (auch auf TTY) sehe. War lustig, das "blind" zu
machen.

Wenn das das ist, was du meinst, ist es öffentlich verfügbar.
Chr. Maercker (12.01.2018, 08:14)
Andreas Kohlbach wrote:
> Microcode?


Gemeint sind CPU-*interne* Befehle/Algorithmen, die zur Ausführung des
offiziellen Befehlssatzes dienen. Normalerweise sind die fest im Chip
einprogrammiert oder aber gar nicht vorhanden wie einst beim Z8000, weil
die Befehlsausführung mittels Logic-array etc. erfolgt.

> Also hier in Debian Linux gibt es Microcode Dateien für die
> verschiedensten Prozessoren. Ich musste den für AMD hier installieren, da
> ich sonst nur Schnee (auch auf TTY) sehe. War lustig, das "blind" zu
> machen.
> Wenn das das ist, was du meinst, ist es öffentlich verfügbar.


Dieser "Microcode" kann quasi den Befehlssatz von CPUs beeinflussen?
Müsste er können, falls wir das gleiche meinen. Und die CPU müsste einen
Programmiereingang haben oder einen programming mode oder so was.
Holger Marzen (12.01.2018, 08:47)
* On Fri, 12 Jan 2018 08:14:02 +0100, Chr. Maercker wrote:

> Dieser "Microcode" kann quasi den Befehlssatz von CPUs beeinflussen?
> Müsste er können, falls wir das gleiche meinen. Und die CPU müsste einen
> Programmiereingang haben oder einen programming mode oder so was.


Bei Debian/Ubuntu:

- Package: intel-microcode
Description-de: Prozessor-Microcode-Firmware für Intel CPUs

- Package: iucode-tool
Description-de: Intel-Prozessor-Microcode-Werkzeug
iucode_tool is a program to manipulate Intel® X86 and X86-64 processor
microcode collections, and to use the kernel facilities to upgrade the
--------------------------------
microcode on Intel system processors.
---------

Der Kernel kann den Code bei jedem Booten in die CPU einspielen. Die
Änderung ist flüchtig, d.h. muss bei jedem Booten erfolgen.
Ralph Angenendt (12.01.2018, 11:53)
Well, Holger Marzen <holger> wrote:
> Der Kernel kann den Code bei jedem Booten in die CPU einspielen. Die
> Änderung ist flüchtig, d.h. muss bei jedem Booten erfolgen.


Sogar beim Aufwachen aus dem Suspend.

Ralph
Andreas Kohlbach (12.01.2018, 20:55)
On Fri, 12 Jan 2018 07:47:13 +0000 (UTC), Holger Marzen wrote:
> * On Fri, 12 Jan 2018 08:14:02 +0100, Chr. Maercker wrote:
> Bei Debian/Ubuntu:
> - Package: intel-microcode
> Description-de: Prozessor-Microcode-Firmware für Intel CPUs


Bei mir kam der heute für AMD64 rein. Die changelog dazu sagt:

| amd64-microcode (3.20171205.1) unstable; urgency=high
|
| * New microcode updates (closes: #886382):
| sig 0x00800f12, patch id 0x08001213, 2017-12-05
| Thanks to SuSE for distributing these ahead of AMD's official release!
| * Add IBPB support for family 17h AMD processors (CVE-2017-5715)

<https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715>

[...]

| * WARNING: requires at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 (or
| a backport of commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf
| "x86/microcode/AMD: Add support for fam17h microcode loading")
| otherwise it will not be applied to the processor.

Die noch Kernel davor fahren, sind (vorerst?) angeschmiert.

> Der Kernel kann den Code bei jedem Booten in die CPU einspielen. Die
> Änderung ist flüchtig, d.h. muss bei jedem Booten erfolgen.


Weil die CPU ist kein EPROM. ;-)
Holger Marzen (13.01.2018, 09:33)
* On Fri, 12 Jan 2018 14:55:26 -0500, Andreas Kohlbach wrote:

[..]
>| "x86/microcode/AMD: Add support for fam17h microcode loading")
>| otherwise it will not be applied to the processor.
> Die noch Kernel davor fahren, sind (vorerst?) angeschmiert.


Und die, deren CPU ein Hauch zu alt ist, auch. Auf meinem Core i5-2200:

Intel(R) Core(TM) i5-2500T CPU @ 2.30GHz

iucode-tool -l -S /lib/firmware/intel-ucode
selected microcodes:
001: sig 0x000206a7, pf mask 0x12, 2013-06-12, rev 0x0029, size 10240
^^^^^^^^^^
Arno Welzel (13.01.2018, 12:28)
Ulrich Maier:

[...]
> Dann zieht es meine ca. 6 GB Hauptspeicher mit
> einer Speed von 0,5 MB/s (Meltdown) bzw. vielleicht (optimiert) bis zu
> 0,05 MB/s ab. Mit dieser Speed lassen sich nicht ansatzweise die Daten
> auslesen, die über CPU und Hauptspeicher rauschen, selbst wenn es
> gelingt, sich auf interessante Datenbereiche zu beschränken.
> Um an sinnvolle Daten heranzukommen, müsste man die Struktur der Daten
> erkennen, um dann gezielt nach konkreten Daten suchen zu können. Aber
> auch dann werden die Daten kaum so lange warten, bis sie abgeholt werden.
> Ist unter diesen Umständen ein konkretes Angriffsszenario vorstellbar?


Ja.

Erstens: man brauch nicht den kompletten Speicher, sondern nur den
Adressraum der relevanten Prozesse.

Zweitens: Die Struktur der Daten ist beim Angreifer bekannt. Der weiß
sehr genau, wo er hinsehen muss, da sich die Stellen, wo Passwörter,
Schlüssel etc. abgelegt werden, bzw. der Einstiegspunkt, wo man
nachsehen muss, um den aktuellen Ablageort zu kennen, nicht dauernd ändern.
Ulrich Maier (13.01.2018, 17:06)
Am 13.01.2018 um 12:28 schrieb Arno Welzel:

> Ja.
> Erstens: man brauch nicht den kompletten Speicher, sondern nur den
> Adressraum der relevanten Prozesse.
> Zweitens: Die Struktur der Daten ist beim Angreifer bekannt. Der weiß
> sehr genau, wo er hinsehen muss, da sich die Stellen, wo Passwörter,
> Schlüssel etc. abgelegt werden, bzw. der Einstiegspunkt, wo man
> nachsehen muss, um den aktuellen Ablageort zu kennen, nicht dauernd ändern.


Der Angreifer müsste also erst alle Prozesse durchgehen (bei mir auf
einen Windows 7 Rechner aktuell 128 Prozesse und 1615 Threads), sie
analysieren, um dann bei ihm bekannten Prozessen, die er dabei zufällig
findet, interessierende Daten gezielt auszulesen. Wie lang leben die
interessierenden Daten und Prozesse!? Wer startet einen solchen wenig
erfolgversprechenden Angriff (inkl. der Vorarbeiten, auf dem Rechner
überhaupt erstmal Code ausführen zu können)?

Realer halte ich da Angriffe in Cloud-Angeboten. Da kann ich mir eine VM
mieten und dann mein Programm ungestört stundenlang laufen lassen, um
andere VMs anzugreifen. Allerdings erreiche ich nur die VMs, die im
selben Server liegen. Welche das sind, darauf habe ich wenig Einfluss.
Sicher keine sonderlich interessanten, weil die interessanten Anbieter
ihre Server alleine betreiben.

Ulrich
Arno Welzel (14.01.2018, 01:44)
Ulrich Maier:

> Am 13.01.2018 um 12:28 schrieb Arno Welzel:
> Der Angreifer müsste also erst alle Prozesse durchgehen (bei mir auf
> einen Windows 7 Rechner aktuell 128 Prozesse und 1615 Threads), sie
> analysieren, um dann bei ihm bekannten Prozessen, die er dabei zufällig
> findet, interessierende Daten gezielt auszulesen.


Nein, nur den einen Prozess, der ihn interessiert.

> Wie lang leben die
> interessierenden Daten und Prozesse!? Wer startet einen solchen wenig
> erfolgversprechenden Angriff (inkl. der Vorarbeiten, auf dem Rechner
> überhaupt erstmal Code ausführen zu können)?


Die Malware könnte sich so eintragen im System, dass sie ständig im
Hintergrund läuft und nur darauf wartet, die Daten abzugreifen. Das ist
viel einfacher, als die Binaries der interessanten Prozesse direkt zu
verändern. Unter Windows ist das für Prozesse zumindest mit den Rechten
des aktuell angemeldeten Nutzers möglich - und das genügt für den
Angriff ja.
Ulrich Maier (14.01.2018, 02:33)
Am 14.01.2018 um 01:44 schrieb Arno Welzel:

>> Der Angreifer müsste also erst alle Prozesse durchgehen (bei mir auf
>> einen Windows 7 Rechner aktuell 128 Prozesse und 1615 Threads), sie
>> analysieren, um dann bei ihm bekannten Prozessen, die er dabei zufällig
>> findet, interessierende Daten gezielt auszulesen.

> Nein, nur den einen Prozess, der ihn interessiert.


Den muss er aber doch erst einmal finden! Die tragen ja wohl den Namen
nicht auf der Stirn?

Wie erkennt man unter den zahlreichen Chrome-Prozessen, mit welchem ich
gerade auf einen Shop zugreife. Und das tue ich ja außerdem nicht
ständig, sondern vielleicht erst übermorgen abend. Bis dahin muss die
Malware ja wohl die Prozesse beobachten.

Käme eine Malware, die sich erst einmal erfolgreich etabliert hat, nicht
viel einfacher an die Daten ran? Die Daten von anderen Prozessen
abzugreifen ist doch vor allem dann interessant, wenn diese Prozesse
anderen Benutzern gehören, oder gar anderen VMs.

Das heißt m.E.:

Szenario 1: Malware läuft auf meinem nur von mir genutzten Rechner: Dann
kommt sie einfacher an meine Daten.

Szenario 2: Malware will an die Daten anderer Benutzer kommen. Da muss
man sich dann aber fragen, mit welchem Ziel. Weitere Benutzer auf einem
Rechner laufen etwa auf Terminalservern und VMs, nicht auf Privat- und
Arbeitsplatzrechnern. In diesem Umfeld machen blinde Angriffe wenig
Sinn, man muss schon sehr genau wissen, was da läuft. M.E. also eher
Ziele für Wirtschaftsspionage, also sehr spezielle Angriffe.

Ich sehe immer noch nicht, wie man Meltdown und Spectre für
Massenangriffe sinnvoll nutzen kann.

Ulrich
Arno Welzel (14.01.2018, 15:34)
Ulrich Maier:

> Am 14.01.2018 um 01:44 schrieb Arno Welzel:
> Den muss er aber doch erst einmal finden! Die tragen ja wohl den Namen
> nicht auf der Stirn?


Doch, das tun sie. Gib mal in einem Konsole-Fenster den Befehl
"tasklist" ein.

> Wie erkennt man unter den zahlreichen Chrome-Prozessen, mit welchem ich
> gerade auf einen Shop zugreife. Und das tue ich ja außerdem nicht
> ständig, sondern vielleicht erst übermorgen abend. Bis dahin muss die
> Malware ja wohl die Prozesse beobachten.


So zahlreich sind die Chrome-Prozesse auch nicht. Und wer weiß, wie
Chrome intern aufgebaut ist, kann auch sehr schnell einfach mal die
handvoll Prozesse abklappern. Und neben Chrome gibt es ja noch diverse
andere Browser und lohnenswerte Ziele, wie E-Mail-Clients,
Homebanking-Programme, Passwort-Manager, Clients Clouddienste wie
Dropbox usw..

Ob einer der fraglichen Prozesse läuft, ist in Sekundenbruchteilen
festgestellt. Die relevanten Speicherbereiche nach den interessanten
Daten abzusuchen, dürfte auch nur eine Frage von Minuten sein.

> Käme eine Malware, die sich erst einmal erfolgreich etabliert hat, nicht
> viel einfacher an die Daten ran? Die Daten von anderen Prozessen
> abzugreifen ist doch vor allem dann interessant, wenn diese Prozesse
> anderen Benutzern gehören, oder gar anderen VMs.


Wie soll man z.B. an die Daten von KeePass herankommen? Oder dem
Passwortspeicher eines E-Mail-Clients usw.

> Das heißt m.E.:
> Szenario 1: Malware läuft auf meinem nur von mir genutzten Rechner: Dann
> kommt sie einfacher an meine Daten.


Und genau darum geht es. Denn nicht alle Daten liegen direkt lesbar im
Klartext irgendwo auf der Festplatte herum.

[...]
> Ich sehe immer noch nicht, wie man Meltdown und Spectre für
> Massenangriffe sinnvoll nutzen kann.


Um Passwörter auszuspähen, mit denen man sich Zugang zu allen möglichen
Diensten verschaffen kann.
Ulrich Maier (14.01.2018, 17:53)
Am 14.01.2018 um 15:34 schrieb Arno Welzel:

[...]

>> Ich sehe immer noch nicht, wie man Meltdown und Spectre für
>> Massenangriffe sinnvoll nutzen kann.

> Um Passwörter auszuspähen, mit denen man sich Zugang zu allen möglichen
> Diensten verschaffen kann.


OK, Danke!

Es bleibt zwar immer noch ein harter Job, das umzusetzen - aber alles,
was möglich ist, wird irgend wann einmal realisiert...

Ulrich
Chr. Maercker (15.01.2018, 09:12)
Holger Marzen wrote:
> Der Kernel kann den Code bei jedem Booten in die CPU einspielen. Die
> Änderung ist flüchtig, d.h. muss bei jedem Booten erfolgen.


Wo wird der Code in der CPU eingelagert und mit welchem Befehl erfolgt
das Schreiben?

Ähnliche Themen