Gibt es eine Übersicht, was sich bzgl. Gefahreneindämmung zu Meltdown, L1F1, etc. mit den Kernel-Versionen verbessert hat?

[Andi07]

Hallo zusammen!

Es mag vielleicht ein altes Thema sein.
Seit etlichen Jahren, Jahrzehnt kommt noch nicht ganz hin, gibt keine Bios-Updates zu den Gefahren. Wenigstens gab es über das Betriebssystem Updates des Microcodes.
Das aber nur am Rande.

Wo gibt es online gerne eine Übersicht, was sich zur Gefahreneindämmung bzgl. Meltdown, L1F1, Ausnutzung der Sprungvorhersage, falls jemand SMT/Hyperthreading aktiviert hat und/oder wie die Lücken auch heißen, sich mit den Kernel-Versionen verbessert hat?


Ich bedanke mich herzlich und sage liebe Grüße!

Andi

 

[Iapetos]

Ein kurzes Überfliegen des Wikipedia-Artikels zu Spectre ergab folgendes, interessantes Repo. Vielleicht liefert dir das einen ersten Einstieg, insbesondere die Linksammlung in der Wikipedia.

 

[KnolleJupp]

Seit etlichen Jahren ist ein wenig übertrieben, gefunden hat man diese Lücken erstmals Mitte 2017, also weiß man seit etwa drei Jahren davon.

Das was "wir" laienhaft als Spectre, Meltdown, ZombieLoad usw. kennen, sind in Wahrheit dutzende verschiedene Sicherheitslücken,
die sich zwar ähneln, aber zu verschieden sind, um als ganzes geschlossen zu werden.

Manche dieser Lücken kann man durch ein Microcode-Update beheben (Software), entweder durch ein BIOS-Update oder als Betriebssystem-Treiber.
Manche erfordern sicherlich Änderungen an der Hardware, also am Chipdesign.

Da diese Sicherheitslücken aber ausgerechnet in Bereichen sitzen, die maßgeblich für die Leistungsfähigkeit moderner CPUs verantwortlich sind,
z.B. die generelle Out-of-Order Architektur oder Hyper-Threading/Simultaneous Multithreading,
kann man diese nicht einfach brutal abschalten, dann würde die Leistung des Prozessors zu massiv abfallen.

Man muss also Wege und Kompromisse finden die Lücken zu schließen oder ein Ausnutzen zu erschweren, ohne dabei die Leistung zu stark einbrechen zu lassen.
Eine Intel CPU mit dem aktuellsten Microcode ist schon messbar langsamer als ohne diese Patches.

Bei allem muss man auch bedenken das ein Ausnutzen sehr kompliziert ist und man auch nicht gezielt bestimmte Daten abgreifen kann.
Mindestens muss jemand den abgefangenen Datensalat erstmal zusammenpuzzlen.

Das Problem sitzt auch nicht bei Intel alleine, im Grunde sind alle Hersteller betroffen, auch AMD-, PowerPC-, MIPS-, ARM-, SPARC-CPUs usw. sind betroffen.

Wenn es kein BIOS-Update gibt, z.B. weil der Support für ältere Hardware schon eingestellt ist, kann ein Microcode-Update auch über das Betriebssystem eingespielt werden, bei jedem Rechnerstart.
Dabei ist es ziemlich egal ob das Windows ist oder Linux oder sonst was. Ich denke das alle großen Anbieter inzwischen entsprechendes bereitstellen.

 

[Andi07]

Hallo Ihr Lieben, erst einmal herzlichen Dank!

Lieber lapetos >sudo ./spectre-meltdown-checker.sh< hatte ich schon mal ausgeführt und jetzt noch einmal.
Aber die Angaben insgesamt verwirren mich eher, besonders dann wenn doppelte Verneinungen enthalten sind.

Da ich der englischen Sprache nicht mächtig bin und weil es hier kürzer ist, das Ergebnis im Gockel-Übersetzer übersetzt.
Ergebnis sudo ./spectre-meltdown-checker.sh (Einen direkten Link, den ich grundsätzlich lieber verwende, nimmt leider die halbe Seite ein. Vom Ergebnis selbst ganz zu schweigen.

Das Ergebnis war für den Übersetzer zu lang, daher noch die Ergänzung:

Rest-Ergebnis von sudo ./spectre-meltdown-checker.sh


Nur ein paar Beispiele:

* CPU zeigt ausdrücklich an, dass Meltdown / L1TF (RDCL_NO) nicht anfällig ist: NO

Die umständliche Anzeige bedeutet also sie ist anfällig?

* CPU-Schwachstelle für spekulative Ausführungsangriffsvarianten
* Anfällig für CVE-2017-5753 (Spectre Variant 1, Bounds Check Bypass): JA

Das betrifft wohl SMT/Hyperthreading, oder? Und ist, falls das zutrifft, bzgl. der CPU eine grundsätzliche Aussage?
Denn Hyperthreading ist gar nicht aktiviert.

Das oben im Ergebnis-Link angezeigte Ergebnis ist also eher eine grundsätzliche Aussage über die CPU, maximal noch in Verbindung mit dem Microcode?

...
Manche dieser Lücken kann man durch ein Microcode-Update beheben (Software), entweder durch ein BIOS-Update oder als Betriebssystem-Treiber.
...

Lieber KnolleJupp, auch Dir meinen persönlichen Dank!
Ich suche ja eine Übersicht bzgl. Gegenmaßnahmen, die in den Kerneln schon vollzogen wurden und aktuell auch noch ggf. enthalten sind.
Meinst Du mit Betriebssystem-Treiber den Kernel?

Der hoffentlich aktuelle Microcode wird über das Betriebssystem geladen.
Ist bzgl. der CPU-Hardware hier ein aktueller Microcode die aktuell bestmögliche Maßnahme gegen diese zig Lücken?

Aber gerne noch einmal die Übersichts-Frage der Kernel-Gegenmaßnahmen.
Was macht der Kernel ggf. gegen diese Lücken?


Ich danke Euch herzlich!

Gruß Andi

 

[KnolleJupp]

Meinst Du mit Betriebssystem-Treiber den Kernel?

Nein.

Ein Microcode-Update bedeutet das die in der CPU enthaltene Software aktualisiert wird.
Eine CPU besteht nicht nur aus Hardware, sondern enthält auch Software, quasi die "Firmware".

In der CPU ist ein Befehlssatz (Microcode) unveränderlich einprogrammiert.
Es gibt aber seit dem Intel Pentium Pro (von 1995) einen zusätzlichen Flash-Speicher in den CPUs, in den ein aktuellerer Befehlssatz geladen werden kann, der den fest eingespeicherten dann vollständig ersetzt.

Ein aktuellerer Befehlssatz kann also während der Initialisierung der CPU in selbige geladen werden.
Er ersetzt temporär (solange der Rechner eingeschaltet ist) und flüchtig (die CPU "vergisst" das Update nach jedem Ausschalten) den ursprünglich bei der Fertigung einprogrammierten.

Nun kann man dieses Microcode-Update auf zwei verschiedene Arten einspielen. Entweder liegt es im BIOS vor und wird bei der Initialisierung des Rechners in die CPU geladen
oder es liegt im Betriebssystem (als eine Art "CPU-Treiber") vor und muss dann aber sehr früh im Boot-Prozess eingespielt werden.

Mit dem eigentlichen Betriebssystem hat das nichts zu tun.

Eine Liste mit Patches kenne ich nicht. Das heißt natürlich nicht das es keine gibt.
Erschwerend kommt hinzu das durch den Patch einer Lücke auch das Ausnutzen einer anderen Lücke zumindest erschwert werden könnte.

Da die meisten dieser Lücken lediglich Seitenkanalattacken zulassen, sind sie allgemein recht umständlich und nicht unmittelbar zielführend.
Natürlich kann man mit geeignetem Code z.B. die Sprungvorhersage so beeinflussen das sie z.B. einen bestimmten Speicherbereich liest,
aber welche Daten am Ende tatsächlich abgegriffen werden, ist mehr Glückspiel als zielgenau.

Ist bzgl. der CPU-Hardware hier ein aktueller Microcode die aktuell bestmögliche Maßnahme gegen diese zig Lücken?

Ein aktueller Microcode, der bestimmte Patches enthält, ist nur eine Möglichkeit.
Auf Seiten des Betriebssystems, also des Kernels wenn du so willst, gibt es auch Möglichkeiten. Google z.B. mal nach "Retpoline" (gegen Spectre V2).

Allen diesen Software-Patches ist aber gemeinsam das man die Sicherheitslücken damit nicht vollständig schließen kann.
Dazu wäre eine Änderung/Anpassung der Hardware nötig. Denn dort sitzt ja letztlich das Problem.

Wenn du Einschlafprobleme hast, hier eine Liste mit bestätigten Sicherheitslücken:
https://cve.mitre.org/data/downloads/allitems.txt (Achtung, sehr groß, über 140.000 Einträge!)

 

[Ratz_Fatz]

Mit "lscpu" kann man mittlerweile auch sehen, welche Lücken bestehen und wie sie vom Kernel behoben wurden bzw. umgangen werden.

Es kann aber auch beim beheben der Lücken zu Fehler kommen(Kernel-Entwickler patzen bei einfachem Spectre-Fix).

Im Moment gibt es eine weitere Lücke bei Intel und AMD CPUs, die sich BlindSide nennt. Von dieser Lücke habe ich bei heise und andere deutsche Medien noch nichts gelesen.
Die Lücke soll mit bestehenden Spectre-Schutzmaßnahmen funktionieren.

Links dazu sind nur auf Englisch:
New BlindSide attack uses speculative execution to bypass ASLR
BlindSide: Intel/AMD Speculation Bugs Under Microscope Again
Security Researchers Detail New "BlindSide" Speculative Execution Attack

https://www.vusec.net/projects/blindside/

 

[Andi07]

Hallo KnolleJupp, Hallo Ratz_Fatz, Hallo zusammen, vielen vielen Dank!

Knolle, Einschlafprobleme habe ich deshalb nicht.
Trotzdem bin ich aber daran interessiert, wenigstens ob und wie erschweren Microcode, Kernel etc. diese Attacken?

Ein wenig anders sieht es dann vielleicht bei LVI aus. Denn die CPU muss b.a.w. erst einmal bleiben.
Was man bzgl. der Passwörter vielleicht machen kann, z.B. hier bei der Anmeldung den Haken bei "angemeldet bleiben" herauszunehmen.
Und zuvor jedes einzelne Zeichen von Hand einzugeben.

LVI - Hijacking Transient Execution with Load Value Injection

LVI is a new class of transient-execution attacks exploiting microarchitectural flaws in modern processors to inject attacker data into a victim program and steal sensitive data and keys from Intel SGX, a secure vault in Intel processors for your personal data.

LVI turns previous data extraction attacks around, like Meltdown, Foreshadow, ZombieLoad, RIDL and Fallout, and defeats all existing mitigations. Instead of directly leaking data from the victim to the attacker, we proceed in the opposite direction: we smuggle — "inject" — the attacker's data through hidden processor buffers into a victim program and hijack transient execution to acquire sensitive information, such as the victim’s fingerprints or passwords.

Crucially, LVI is much harder to mitigate than previous attacks, as it can affect virtually any access to memory. Unlike all previous Meltdown-type attacks, LVI cannot be transparently mitigated in existing processors and necessitates expensive software patches, which may slow down Intel SGX enclave computations 2 up to 19 times.

Bzw.:

LVI - Hijacking Transient Execution mit Lastwertinjektion

LVI ist eine neue Klasse von Transient-Execution-Angriffen, bei denen mikroarchitektonische Fehler in modernen Prozessorenausgenutzt werden, um Angreiferdaten in ein Opferprogramm einzufügen und vertrauliche Daten und Schlüssel von Intel SGX zu stehlen , einem sicheren Tresor in Intel-Prozessoren für Ihre persönlichen Daten.

LVI dreht frühere Datenextraktionsangriffe wie Meltdown , Foreshadow , ZombieLoad , RIDL und Fallout um und besiegt alle vorhandenen Schadensbegrenzungen. Anstatt Daten direkt vom Opfer an den Angreifer weiterzuleiten, gehen wir in die entgegengesetzte Richtung: Wir schmuggeln die Daten des Angreifers durch versteckte Prozessorpuffer in ein Opferprogramm und entführen die vorübergehende Ausführung, um vertrauliche Informationen wie die des Opfers zu erhalten Fingerabdrücke oder Passwörter.

Entscheidend ist, dass LVI viel schwerer zu mildern ist als frühere Angriffe, da es praktisch jeden Zugriff auf den Speicher beeinträchtigen kann. Im Gegensatz zu allen früheren Meltdown-Angriffen kann LVI in vorhandenen Prozessoren nicht transparent gemindert werden und erfordert teure Software-Patches , die die Intel SGX-Enklavenberechnungen 2 bis zu 19-mal verlangsamen können.

Aber wie könnte denn überhaupt ein Angriff über diese Lücken in der Praxis erfolgen?
Muss da z.B. erst mal dubiose Software installiert werden?
Dieses Zeug muss vermutlich ja erst einmal auf den Rechner kommen.

Anders sähe es dann aus, wenn Angriffe möglicherweise einfach über Javascript eines Browsers erfolgen. Sofern das aktiviert ist.

Aber keine Sorge, ich schlafe trotzdem oder das Thema regt mich nicht auf.
Aber an Sicherheit bin ich nichts desto trotz interessiert.

Danke!!!

Gruß Andi

 

[KnolleJupp]

Die meisten dieser Sicherheitslücken funktionieren so das ein Prozess A plötzlich auf Bereiche des Arbeitsspeichers zugreifen kann, die zu einem Prozess B oder C gehören.
Die Patches sorgen z.B. dazu das zusätzliche Überprüfungen der Berechtigungen durchgeführt werden. Das kostet dann aber Leistung, da dadurch zusätzliche Bearbeitungsschritte notwendig werden.

Sectre und Meltdown nutzen - grob gesprochen - das Out-of-Order Funktionsprinzip aus (spekulative Sprungvorhersage),
die unter bestimmten Voraussetzungen Bereiche des Arbeitsspeichers einliest, in vorauseilendem Gehorsam, weil sie der Meinung ist das ein Prozess bestimmte Daten demnächst brauchen könnte,
der Prozess, für den das gemacht wird, aber gar keine Berechtigung hat auf diese Speicherbereiche zuzugreifen, weil diese einem anderen Prozess zugeordnet sind.
Selbst wenn diese vorgehaltenen Daten dann wieder verworfen werden, weil der Prozess diese Daten nicht brauchen kann, kann man im Anschluss Rückschlüsse ziehen auf den Inhalt.

 

[el osito]

Eine kleine Übersicht bzgl. Spectre (1/2) und Meltdown bieten u.a. folgende Distros:

• Ubuntu Wiki
• Debian Wiki

 

[Andi07]

Hallo KnolleJupp, Hallo el osito und Hallo zusammen!

KnolleJupp, vielen für detailierteren Einblick!
Dann lag meine Annahme, dass die Sprungvorhersage etwas mit SMT/Hyperthreading zu tun hat, auf einem falschen Feld.
Und hat mit den Daten im Arbeitsspeicher zu tun. Vielen Dank!

Auch wenn dies nichts mit SMT/Hyperthreading zu tun hat, bleibt dies weiterhin bei mir deaktiviert.
Auch wenn ich diesbzgl. und der anderen Sicherheitsprobleme in den problematischen CPU's hier einige Male gelesen habe, dass das Ausnutzen dieser Lücken im privaten Bereich keine Rolle spielen sollen.
Verhältnismäßig ist das wohl richtig, aber nur verhältnismäßig. Das heißt aber für mich nicht, dass ich unbedingt gewissermaßen mit dem Feuer spielen muss oder leichtfertig sein muss.

Bzgl. der Berechtigungszuordnungen kommt mir irgendwie dunkel der Gedanke, da mal etwas in einem Kernel-Changelog an Sicherheitsanpassungen oder Änderungen gelesen zu haben.
Das geistert aber gerade sehr vage in meinem Kopf herum, bzw. sehr unkonkret.

el osito, vielen vielen Dank für die Übersichten/Links!

Vermutlich ist es leider ein kleines Problem, dass diese Seiten von 2018 sind.
Klein nur deshalb, weil diesbzgl. Sicherheits-Updates mindestens weiterhin vorhanden sind.


Herzliches Dankeschön!

Gruß Andi

 

[lokon]

Vermutlich ist es leider ein kleines Problem, dass diese Seiten von 2018 sind.

ubuntu-wiki: zuletzt geändert am 2019-10-15
debian-wiki: zuletzt geändert 2019-07-20

• Änderungen im Kernel-Log sind öffentlich und durchsuchbar.
• Es gibt durchsuchbare CVE Datenbanken mit öffentlichen Details wenn der Fehler behoben wurde / Nummer vergeben wurde ("responsible Disclosure") - zB auch nur für Intel (nicht nur CPUs), mit Filter/Suchfunktionen
• zB auch https://www.linuxkernelcves.com/ , deren github

Vielleicht findest du in einer Suchmaschine für wissenschaftliche Publikationen einen guten Übersichtsartikel. Oder auf einer (Linux?) Konferenz einen Vortrag über die Lücken. Spectre und ähnliche Sicherheitsprobleme sind Gegenstand der Forschung.
zB scholar.google.com , sciencedirect , springerlink und (Meta)-Suchmaschinen diverser Universitätsbibliotheken für Hochschulschriften u.ä.

Über "Gefahreneindämmung" und "aktuelle Maßnahmen" :

• Angreifermodelle u. -szenarien / Red u. Blue Team sollten beachtet werden
• Seitenkanalangriffe sind nicht "neu" (1943)
• Isolierte Systeme / Kontrollierter Code oder unwichtige Daten brauchen vielleicht keine Mitigation, FIPS Zertifizierung, "military grade security" usw.

Deshalb sind im Kernel die Maßnahmen abschaltbar und andere Mitigationen auch sinnvoll : zB kein fremder Code

im privaten Bereich keine Rolle spielen sollen

Über die Praxistauglichkeit von Spectre u. a. ist auch deren Verfügbarkeit zu berücksichtigen.
"Proof of Concept" ist etwas anderes als ein funktionierender Exploit für eine "Skript-Kiddie" Software.
Keine Ahnung wie der Stand da ist in "einschlägigen Hackerforen" - für das Testen von neuen Kernelversionen gegen alte Bugs braucht es auch "Hackersoftware" bzw. eine Testliste wenn geprüft werden soll ob die CVE-Mitigationen noch korrekt funktionieren.
siehe Kritik am "Hackerparagraph" , (alter) Anhaltspunkt der Praktikabilität von Spectre hier

Die meisten Rechner bieten genügend größere Angriffspunkte für lokales oder entferntes Hacken: Hardwaremodifikation oder Browser-Sicherheitslücken.

 

[Ratz_Fatz]

Auf eine Fernwartungsfunktion in der CPU würde ich auf dem Desktop verzichten(Intel AMT / AMD DMTF DASH). Sonst alles abschalten, was man nicht benötigt, Router aktuell halten und auch hier Dinge deaktivieren die man nicht benötigt z.B. UPnP, SSH, Telnet, RDP verbieten.

Javscript im Browser deaktivieren.

Mit neueren Kernel kannst du auch den Kernel-Lockdown Modus mit confidentiality oder integrity verwenden. Einfach mal danach suchen, was das ist.

cat /sys/kernel/security/lockdown
nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="security_lockdown_lsm_early lockdown=confidentiality"
update-grub

Bei den Asmedia(CTS-Labs) Lücken mit Keylogger und möglicher Backdoor-Funktion fand ich spannend zu sehen, was so alles möglich ist und auf welcher Ebene(Link). Ich möchte keine Diskussion lostreten, warum die Lücken veröffentlicht wurden.

Während es Behauptungen gab, dass die Mängel der Marktmanipulierung dienten,[11][12], wurde ihre Gültigkeit von einem technischen Standpunkt von unabhängigen Sicherheitsexperten bestätigt, die die Offenlegungen überprüften.[13] Quelle

Wie sieht es denn mit Lücken aus, die zwar Adminrechte benötigen, aber dann damit ggf. in den Ring -2 kommen(Eskalation von SMM-Zugriffsprivilegien(Link))? Adminrechte unter Windows bekommt man als Programm doch relativ leicht, nur damit in den Ring -2 zukommen ist doch eigentlich sehr schlecht.

Auch noch interessant: Rowhammer

 

[Andi07]

Hallo lokon, Hallo Ratz_Fatz und Hallo zusammen!

Herzlichen Dank Euch beiden, das sind tolle Anregungen. Super!
Da habe ich im Laufe der Zeit erst einmal zu tun!


Liebe Grüße
Andi