[🛈Start+]   [🥋Trad. Taekwon-Do+]   [🧮Mathematik]   [📙Forschung & Lehre+] [🐧GNU/Linux+]
[🔑Impressum+]   [🛀Autogenes Training+]   [💡Physik]   [⚙️Technik+]   [💾Progs: C+++]
Sprache:  [GB-NA-Flagge]  [🔭Astronomie] [📜LATEX]   [🕹️Spiele+]

JMB-LogoJMB-AvatarBlue Ribbon Icon (Freie Rede)

Sicherheitsprobleme

Probleme mit der Sicherheit von IT-Systemen

[🐧GNU/Linux]   [📀Installation: G/L]   [📂Konfigs: G/L]   [🖬Ältere G/L-e]   [⚠️Sicherheitsprobleme]

Inhaltsverzeichnis zu JMB's Seite zur IT-Sicherheit

Link zur 🐧Bedeutung von GNU/Linux.
[Grafik mit TuX und GNU als Maskottchen von GNU/Linux]

Allgemeines 

Der Inhalt dieser Seite erwuchs aus immer nötigeren Ergänzungen zur 🐧GNU/Linux-Seite.
Angesichts einer immer unsichereren IT-Industrie und einem unangepasst-lockeren Verhalten der Bevölkerung mit IT und fehlgeleiteten Politikern, muss dieses Thema auch gezwungener Maßen mehr Raum bekommen.
Bevor im Nachfolgenden auf die größten Probleme der IT-Branche eingegangen wird, sollen nun erst einmal allgemeine Dinge angesprochen werden.
Nachdem bewiesen wurde, dass man keinen Beweis für ein fehlerhaftes Programm erbringen kann, muss man mit [Wikipedia-de-Icon]Fehlern (sogenannten Bugs) leben – insbesondere mit der ständigen Jagd danach und entsprechend stetem Updaten der benutzten Systeme. Kleine Änderungen an der Hardware können weitreichende Folgen haben. Hierzu tragen insbesondere Race Conditions bei, die je nach Ablauf und Bedingungen unterschiedlich schnell bearbeitet werden und dadurch unterschiedliche Ergebnisse hervorbringen können.

Zur Kennzeichnung allgemeine Sicherheitslücken und Schwachstellen werden seit 1999 sogenannte [Wikipedia-de-Icon]CVE‑Nummern verwendet (Common Vulnerabilities and Exposures). Bei diesem Industriestandard handelt es sich um eine einheitliche Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen, die anfänglich aus Jahreszahl und einer vierstelligen Nummer bestanden, seit Anfang 2014 sind beliebig viele Stellen dafür erlaubt. Aber auch bzgl. CVEs sind Verbesserungen nötig, wie von Heise‑Security am 28.08.2018 berichtet.
Eine Suche bzgl. CVE-Nummern ist im Internet jederzeit möglich.

Alle Schüler sollten im üblichen Mediensicherheitstraining lernen, dass jeder Computer mit Internetverbindung missbraucht werden kann. Kameras können ohne Kenntnis der Anwender (sogenannte User) eingeschaltet, Löschungen können vorgenommen und beliebige Daten können auf Privatrechnern oder Servern abgelegt werden. Rechte können beliebig verändert werden – und das gilt nicht nur für den eigenen PC bzw. das eigene Smartphone/Tablet, sondern in besonderem Maße für die Cloud-Dienste. Facebook, Twitter, Google, Yahoo, Amazon und viele weitere bekannte Unternehmen stehen mit Daten, die Begehrlichkeit wecken, im Fadenkreuz von Crackern (IT‑Spezialisten mit bösen Absichten, auch Black Hats genannt – im Gegensatz zu Hackern [die auf den Tasten hacken], die ihr Können zumeist zum Wohle anderer und nicht zu deren Schaden einsetzen). Alle großen Unternehmen waren in unterschiedlichem Umfang von Datendiebstahl oder Datenveränderung betroffen. Niemand kann das Eindringen verhindern, nur wie beim Haus-Einbruch deutlich erschweren. Zuletzt wurden zwei Facebook‑Hacks bekannt, von denen Heise‑Online am 29.09.2018 und danach am 12.10.2018 berichtete, bei denen Millionen Nutzer betroffen waren, sogar Mark Zuckerberg persönlich.  🤫   😏 
Neben solchen kriminellen Angriffen gibt es auch Unfälle, bei denen User oder Administratoren falsche Berechtigungen setzen oder Software‑Fehler solche Auswirkungen haben und so öffentlich wird was privat bleiben sollte.
Hardwarefehler sind nur durch geänderte Hardware wirklich zu beseitigen, BIOS-/Firmware-Updates und Betriebssystem-Patche können keine vollständige Lösung bieten, auch wenn viele dies suggerieren wollen. An zweiter Stelle der Bedeutung ist der Kernel des Betriebssystems – hier hätte es im vorigen Jahrtausend noch Diskussionen gegeben, heute wird man auf Linux oder auf Speziallösungen zumeist im Unix-Bereich setzen. An dritter Stelle neben den jeweils verwendeten Bibliotheken folgen dann die Applikationen – insbesondere die mit direktem Kontakt nach außen, wie Web-Server oder Web-Browser (FF|Google Chrome) / Mailclients (Thunderbird): z.B. die Liste der in Firefox / Thunderbird im jeweiligen Release behobenen Fehler.
Smartphones haben bislang keine brauchbare Sicherheit (immer noch mangelhafte Abschattung von Apps, die ohne wirkliche Kontrolle aus dubiosen Quellen heruntergeladen werden, auch wenn verantwortliche Firmen gerne einen anderen Eindruck beim Kunden erzeugen wollen), über Internetgeräte wie Leuchtmittel, Kühlschränke etc. (IoT: Internet of things, eindeutig indentifizierbare Kleingeräte, die meist viel zu leicht ferngesteuert werden können und mehr Gefahr als Nutzen bieten) sollte man den Mantel des Schweigens decken.
Empfehlenswert ist heute sicherheitstechnisch nur eine 🐧GNU/Linux‑Distribution, die man regelmäßig updated (1× am Tag genügt). Schon Ende der 90‑er Jahre konnte eine Linux‑Workstation ein Jahr ohne Reboot unter Last fehlerfrei arbeiten (Standard-PC, voll einsetzbares Betriebssystem, nicht z.B. nur Datenbank-Server). Mir ist keine Windows-Lösung bekannt, die dies könnte – nicht einmal ansatzweise; da muss man noch nicht einmal von Viren sprechen, die es unter Linux nicht gibt (solange man deren Ausführung nicht mit Wine erzwingt ;). macOS und Windows bieten sehr schwachen Schutz, was bei Sicherheitsevents immer wieder deutlich demonstriert wird (vgl. auch ⚠️Fußnote).

Überdies gibt es kein digitales Original, auch wenn die IT‑Branche meist in keiner guten Absicht genau dies suggerieren möchte. Alle digitalen Daten werden vielfach kopiert, aus dem Internet oder einem Datenträger gelesen, über schnelle Zwischenspeicher (Cashes; zumeist mehrfache – ggf. in Abstufungen) dann in den Hauptspeicher kopiert, um dann auf einen Bildschirm, auf den Drucker, ins Internet oder einen Datenträger übertragen zu werden. Ein wirklicher Kopierschutz würde dafür sorgen, dass etwas nicht lesbar wäre – somit kompletter Blödsinn. Man sollte das Eigentum anderer achten und somit auch das Copyright, aber vielfach möchten Content-Vertreiber beliebig Geld machen und unerlaubt Daten sammeln, und haben dabei keine Skrupel, neugierige Kinder und deren juristische Vormünder zu kriminalisieren. Die meisten dieser Firmen haben selbst vielfach industriellen Großdiebstahl begangen, was aber nicht einmal geahndet wird. Wenn eine kleine Firma einmal nicht schnell genug pleite geht, einigt man sich gütlich ... ein Angebot, das Jugendlichen nicht gemacht wird. DOS wie auch Windows NT sind prominente Beispiele, aber auch beim Streit um die GUI zwischen Apple und Microsoft wurde zum Schluss festgestellt, dass sich beide unerlaubt bei Xerox Parcs bedient hatten.
Es wäre schön, wenn hier Sachverstand und gesundes Augenmaß über den ständigen Lobbyismus obsiegen könnte und auch die Staaten ihre Pflicht tun und die Privatsphäre anständiger Menschen achten (und damit meine ich nicht die unsinnige 📄DSVGO, die vorrangig anständige Menschen aus dem Web getrieben haben und der kriminellen Abmahnbranche zuspielt). Hier liegt ein sehr langer Weg vor uns, insbesondere in Deutschland, in dem der Datenschutz allenfalls auf dem Papier steht – vom Jugendschutz gar nicht zu sprechen.
Auch diese Bemerkungen gehören zur Sicherheit, damit es nicht plötzlich eine böse Überraschung gibt.

Bemerkung zum Security-GAU der CPUs:  Meltdown & Spectre  [CPU‑Fehler von Intel, AMD, ARM, ...:  CVE‑2017‑5715+‑5753+‑5754]

Angesichts des aktuellen Dramas ein paar Infos, gerade, weil in Deutschen Nachrichten zumeist viel Unsinn zu lesen ist und auch in der Tagesschau bzw. bei den Heute-Nachrichten nur peinliches Halbwissen verbreitet wurde. Es gab nur eine Ausnahme, den Artikel von Andreas Stiller (Heise Verlag), den ich daher zum Lesen empfehle: Analyse zur Prozessorlücke:  Meltdown und Spectre sind ein Security-Supergau.
Mindestens seit 2006 (Intel Westmere; es sollen aber quasi alle Intel CPUs betroffen sein, insbesondere alle Core i-Systeme) soll es durch den Versuch der Vorhersage zukünftigen Codes (speculative execution bzw. [Wikipedia-de-Icon]out‑of‑order execution) zur besseren Ausnutzung von Multithreading- und Multicore‑Systemen Probleme mit der Sicherheit geben (Pionier IBM hat mit zSeries auch patchen müssen, so dass dies deutlich länger zurückreicht). Offensichtlich wurde keine gründliche QA (quality assurance; also Qualitätssicherung) betrieben, wenn etwas über 10 Jahre im Verborgenen bleiben kann (dies, das Fehlen von klaren Äußerungen zum zukünftigen Abstellen des Problems und das Runterspielen der jetzigen katastrophalen Situation durch Intel veranlassten den Linux‑Schöpfer und Maintainer des Entwicklungszweigs Linus Torvalds zu sehr deutlichen aber auch mehr als berechtigten kritischen Worten: bislang hat nur ARM bekannt gegeben, zukünftige CPUs wären nicht mehr wie unten beschrieben angreifbar ... nach einer E-Mail von Linus Torvalds vom So., 21.01.2018 machen Intel's Patche sogar den Anschein, als wolle man in zukünftigen CPUs das Problem gar nicht lösen und man aktuell sich eher selbst vor juristischen Schritten bewahren möchte als ihre Kunden vor den extremen Gefahren durch die riesigen Sicherheitslücken zu schützen; die Antwort darauf von David Woodhouse vom 22.01.2018 macht das Bild klarer, die Hauptkritikpunkte bleiben aber bestehen; Intels Aussage, noch in 2018 CPUs mit vollem Hardwareschutz gegen Spectre und Meltdown zu liefern (Heise-Bericht vom 15.03.2018), reicht bei weitem nicht aus (HW-Schadensminderung bzgl. Meltdown {erspart KPTI} und L1TF/Foreshadow brachte als erstes Core i9 9900K – bzgl. Spectre Variante 2 {erspart Retpolines} mit zukünftigem Cascade Lake, vgl. Phoronix-Benchmark-Bericht vom 31.10.2018); zum Aufkündigen der Sicherheitslücken Intel ME & AMD PSP ist mir von den Hardwareherstellern ebenso nichts bekannt; vgl. nächstes Unterkapitel).
Soweit führt Security by Obscurity (also der Versuch, durch Entwicklung und Spezifikationen im Verborgenen Sicherheit zu gewährleisten) – dies nützt nachweislich nur Kriminellen!
Aktuell sind drei Bestandteile bzw. Varianten der Sicherheitslücke bekannt  (8 neue harren ihrer Veröffentlichung; vgl. Spectre‑NG):
1) Bounds Check Bypass(BCB= Spectre V1= GPZ V1)CVE‑2017‑5753,
2) Branch Target Injection(BTI= Spectre V2= GPZ V2)CVE‑2017‑5715,
3) Rogue Data Cache Load  (RDCL= Meltdown= GPZ V3)  CVE‑2017‑5754.
Die dritte (Meltdown) betrifft vorrangig Intel, AMD sei nicht betroffen und lediglich ARM Cortex-A75. In Linux wurde ab 03.01.2017 KPTI mit 4.15‑rc6 eingeführt und in alle LTS‑Kernel als Backport verteilt (4.14.12, 4.9.75, 4.4.110, ab 05. Jan. 2017) – er sollte in nächster Zeit Eingang in die Kernel aller Distributionen finden (zumindest bis zur Deadline der Offenlegung am 09.01.2018). BSDs bereiten sich ebenso vor, auch Windows und macOS werden Patches bringen. Da Google die Sicherheitslücke fand (genauer deren [Wikipedia-de-Icon]Project Zero, daher auch die Abkürzung GPZ) und diese quasi ausschließlich auf Linux setzen und alle Maßnahmen auf ihren Servern durchführten, sollte man unter Linux auch in diesem Fall am sichersten☠  sein. Es gab anfangs auch noch keine Angriffe, die diese Lücken ausnutzten.
Spectre betrifft viel mehr Prozessoren: Intel, AMD (wie z.B. Heise-Online am 12.01.2018 berichtete auch in beiden Varianten betroffen – anfänglich wurde Variante 2 als unkritisch eingeschätzt), ARM, nVidia-GPUs, ... und scheint sowohl von Applikationsseite (FF 57.0.4 wurde in Xubuntu am 05.01. zur Verfügung gestellt und einen Tag zuvor gab es ein Google Chrome-Update; daneben gibt es Compiler-Patches wie die für GCC 7.2 und 8 oder LLVM 5.0.2 und 6.0: 7.3 mit Spectre Patches wurde am 25.01.2018 veröffentlicht – aber Vorsicht: wie am 28.06.2018 von Heise‑Security berichtet wäre allenfalls Firefox aktuell sicher, Chrome, Edge und Safari seien selbst mit den Spectre V1-Patches nicht vollständig sicher) als auch im Kernel der Betriebssysteme verhindert zu werden.
Bei Variante 1 kommen Kernel-Patches ins Spiel (Phoronix 20.01.2018), die voraussichtlich erst mit Beginn des Mainline-Kernels 4.16 Einzug halten – Microcode-Updates von den Hardware-Herstellern (aktuell gibt es z.B. bei Intel unerwartete Reboots [Heise-Online, 18.01.2018] etc., so dass viele noch nicht ausgeliefert werden können) wird in Bezug auf beide Varianten verwiesen, die z.B. von Ubuntu automatisch eingespielt werden – wenn verfügbar.
Der Kernel-Teil, der sich auf Variante 2 bezieht und den Google als Retpoline (return&trampoline) vorstellte, fehlte dem Mainline‑Kernel erst noch ... [die Schwierigkeit lag darin, dass man dies nicht öffentlich bekannt machen wollte, da Meltdown-Vermeidung mit KTPI/KASLR mögliche andere Gründe hatte, aber sobald spekulative Ausführung erwähnt würde, wäre die tatsächliche Schwachstelle sofort allen klar gewesen] ... das Patchset v5 wurde am 06.01.2018 an die Linux Kernel Mailing List (LKML) geschickt und der unanfechtbare Teil wurde Bestandteil von 4.15-rc8 (d.h. Skylake und neuere Intel-CPUs benötigen wegen return buffer underflow weitere Patche: den RETPOLINE_UNDERFLOW-Modus, um vollständig gegen Spectre Variante 2 zu schützen) und sind als Backports in Linux 4.9.77 und 4.14.14 enthalten (vgl. englische Information von Red Hat zu Performance‑Einbußen). Eine Zusammenstellung aller Features von Linux 4.15 (17.01.2018, Thorsten Leemhuis, Heise-Online) geht detailliert auf die aktuellen Bugfixes im Mainline-Kernel ein, die somit auch älteren Kerneln offiziell als Backports zur Verfügung gestellt werden können.
Wenn dies notwendig wäre, würden ggf. auch in solchen Fällen, dass Patche noch nicht im Hauptzweig Aufnahme finden konnten, Distributions-Kernel eine Zwischenlösung bringen, bis man den besten Code gefunden hat. Diese Mutmaßung wurde auch in einem Blog von Greg Kroah-Hartman am 06. Jan. 2018 bestätigt. Offenbar gibt es mehrere konkurrierende Patche, während der oben genannte eine sehr hohe Qualität besitzt. Bzgl. Meltdown wurden ARM64-Patches anfänglich nicht im Hauptzweig aufgenommen, waren aber in den entsprechenden Android Common Trees enthalten und sind seit 10.02.2018 in Linux 4.16 für Meltdown und Spectre zu finden. Jenseits von x86 und ARM gibt es ebenso Probleme, deren Lösung aber wohl noch länger braucht und ggf. eher in den Enterprise-Kerneln getestet werden (so sind nach einem Bericht auf Heise-Online vom 11.01.2018 auch Prozessoren von IBM POWER [Power7+, 8, 9; hier gab es mit Linux 4.15 Patche gegen Meltdown und in 4.16 werden PowerPC Memory Protection Keys seit 22.01.2018 (ähnlich MPK für Intel) unterstützt (vgl. Phoronix-Artikel, 22.01.2018)] {zSeries Infos sind nicht öffentlich sondern nur für Kunden – am 11.02.2018 wurden entsprechende Patche gegen Spectre für Linux 4.16 und GCC 8 eingebaut [basierend auf Expoline, da es auf zSeries die return instruction nicht gibt sondern execute]}, Fujitsu SPARC-M19 und -M12 sowie ARMv8 durch Spectre betroffen und werden Updates erhalten müssen [In-Order-ARM-Kerne wie Cortex-A7 und Cortex-A53 sind von Meltdown und Spectre nicht betroffen]; zudem werden seit 21.02.2018 erste Patches für LLVM ab MIPS R2 ISA [P5600 und P6600] eingebaut, um durch hazard barrier instructions [kein Retpoline] Spectre Variante 2 zu verhindern [vgl. Phoronix-Artikel, 21.02.2018]). Anders als im Blog vorausgesagt gab es bislang noch kein Kernel-Update unter Xubuntu 17.04 (da es bis zum 12.01. keines gab, will man wohl nicht mehr patchen; man hat das EoL wohl offenbar effektiv vorgeschoben, da man bei einer solch schweren Lücke unverzüglich hätte reagieren müssen: Linux 4.10.0-42 #46-Ubuntu SMP Mon Dec 4 14:38:01 UTC 2017), das bis 13.01.2018 Support hätte genießen sollen ... still waiting ... holding the line ...^C – zumal 17.10 wegen des Laptop-Firmware-Problems zur Zeit nicht mit den ISOs installiert werden soll ... hier ist diese Woche (für 11.01.) ein neues Image angekündigt, das aber entgegen jeder Logik die Sicherheits-Patche nicht aufweisen wird, die zumindest ab 09.01. ein Online-Update bringen sollte – es genießt schließlich bis 19.07.2018 Support [14.04 LTS und 16.04 LTS bekamen wie verabredet das Udate, z.B. Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018]. ;) Und am Mo., 22. Jan. 2018, ist ein neuer Ubuntu-Kernel/Firmware für alle Derivate der drei aktuell supporteten Releases 14.04 LTS [Trusty mit Linux 3.13.0-?], 17.10 [Artful mit Linux 4.13.0-?] und 16.04 LTS [Xenial mit Linux 4.4.0-?] geplant, die nun Indirect Branch Predictor Barrier [IBPB] und Indirect Branch Restricted Speculation [IBRS] einführen werden (hierbei wurde Single Thread Indirect Branch Predictors [STIBP] nicht erwähnt), um Specte in Variante 2 zu begegnen (den Stand der Diskussion um Linus Torvalds hat Heise-Online am 23.01.2018 zusammengestellt) – sie untersuchen auch Retpoline, aber wegen der dafür benötigten Compiler-Patche gehen sie trotz höherer Performance-Einbußen erst einmal diesen Weg (wie durch Phoronix am 18. Jan. 2018 berichtet – dennoch gibt es bis 29.01. kein Kernelupdate, wohl aber mehrere Firmware-Updates). Wobei Linux hier ebenefalls eher besser dran ist – in Windows musste man laut Heise-Online vom 29.01. mit Update KB4078130 sogar den Schutz gegen Spectre V2 deaktivieren.
<Ich bin mittlerweile fest auf Xubuntu 18.04 LTS und empfehle dies auch anderen; ich hoffe, dass Ubuntu/Canonical sich auch nach 18.04 LTS Mühe gibt und generell die QA durchführt und Sicherheitsupdates macht (inkl. Kompilieren aller Komponenten mit Compilern, die bzgl. Spectre gepatcht sind), so dass bald alle Anwender eine stabile, sichere und nicht zu verstaubte Plattform bekommen. Was bei 17.04 und 17.10 gemacht wurde ist wohl eher als Bug-Party (siehe meine jüngsten Erfahrungen) zu bezeichnen, bei der jeder einen weiteren Bug beisteuern kann. Oder hat man dort die QA-Spezialisten der Hardware-Branche angeheuert?>
Somit wird auch im angegebenen Blog betont, dass alle gehalten sind, ihre Systeme sicher zu halten, laufend Updates einzuspielen und auch ein Backup ist bei dieser Sachlage keine schlechte Idee (siehe den humorvollen englischsprachigen Beitrag des Linux‑Experten Allan Cox). Wobei es neben den beschriebenen laufend noch anders gerichtete Fixes gibt, so dass der Rat des ständigen Updates immer zu beherzigen ist.
Und wie Kunden von den Hardwareherstellern im Regen stehen gelassen wurden und werden, hat ein Heise-Online-Artikel vom 12.01.2018 treffend umrissen.
Und was dort noch fehlt: Wie können die Hersteller es wagen, neue Produkte vorzustellen, ohne direkt auf die Lücken Meltdown/Spectre/ME & PSP einzugehen, so wie es jetzt gerade geschieht?
Aber dem letzten Satz kann ich nur beipflichten: gerade in Deutschland gibt es keinen Verbraucherschutz – nicht einmal für Jugendliche. Dies stört hier keinen, wie auch nicht den bevorzugten Umgang mit der Automobilbranche oder der Telekommunikationsbranche durch unsere Politiker. Die Zeche zahlen die kleinen Kunden, die Verursacher bekommen Zusatzzahlungen wegen der hervorragend geleisteten Arbeit. Kontrolle, Überwachung, Regulierung, Konsequenz, Recht?
Wer weitreichendere Informationen sucht, sei auf die Quellsammlung von Linux Weekly News (04.01.2018) oder die nach Herstellern gegliederten Stellungnahmen-Sammlung des Heise-Verlages (08.01.2018) und entsprechende zukünftige seriöse Beiträge verwiesen. Wesentliches werde ich natürlich auch hier ergänzen.
[Wikipedia-de-Icon][Meltdown-Logo] Ebenso von Interesse ist die offizielle Homepage von Meltdown & Spectre. [Spectre-Logo][Wikipedia-de-Icon]

Für Personen, die es genauer wissen wollen und sich von der englischen Sprache nicht abschrecken lassen, sei der FOSDEM-Keynote-Vortrag im webm-Format bzw. die zugehörigen Folien als PDF von John Masters von Red Hat empfohlen.

☠)  Wie richtig die Betonung der deutlich höheren Sicherheit von Linux auch in diesem speziellen Fall war, konnte ich als ich das schrieb nicht ahnen – und wird aktuell als Total Meltdown (Bericht von Heise vom 28.03.2018) bezeichnet, bei dem ein Patch von Windows 7 die Sicherheitsproblematik noch wesentlich verschlimmert hat. Allen Unkenrufen zum Trotz, dass in den Mainline-Kernel von Linux oder die BSDs Patches nicht sofort Eingang fanden: es macht keinen Sinn, schlechten Code einzubauen, nur um werbewirksam das Beheben von Sicherheitslücken (für den Namen Moonshot sollte man sich schämen bzw. seine Selbstironie überdenken) zu proklamieren, die entweder nicht sinnvoll gefixt wurden oder noch größere Sicherheitslücken aufgerissen haben, ist schlicht peinlich. Weder Windows (ab NT ein System, das Digital entwickelte und als zu schlecht einstufte, um als VMS-Nachfolger zu dienen) noch macOS (ein Microkernel, der ein ganzes BSD als Service bekam, so dass die Microkernel-Vorteile, die sowieso nur auf dem Papier bestehen, direkt ausgehebelt wurden) hatten jemals einen guten Ruf was Stabilität oder Sicherheit angeht – und werden diesen auch nicht bekommen.
Secutity by Obscurity, d.h. Sicherheit durch Verschleierung und proprietären Code, hat noch nie funktioniert. Fehler passieren überall, aber erst wenn alle hinsehen können besteht die Möglichkeit, Fehler zu minimieren.

AMD Flaws:  Ryzenfall, Masterkey, Chimera, Fallout  [CVE‑2018‑8930 bis ‑8936]

Am 13.03.2018 berichtete Phoronix über gemeldete Sicherheitslücken von AMD in PSP und Chipsatz von Ryzen & Epyc, die wegen der reservierten Domain für die zugehörige Website AMD Flaws genannt werden. Von AMD wurden diese bestätigt (Heise-Bericht vom 21.03.2018), allerdings ist nach dem, was bisher bekannt ist, kein großes Risiko verbunden. Bei root-Rechten, die angeblich nötig sind, sollte es aber keine Schranken geben, so dass dann auch keine Sicherheitslücke relevant ist. Aber da es ggf. auch andere Möglichkeiten geben kann, ist ein Beheben dieser Sicherheitslücken in jedem Fall zu begrüßen:

AMD Flaws
1. Mangelhaftes HW-validiertes Booten MASTERKEY-1 / -2 / -3  CVE‑2018‑8930,
2. Unuzureichende PSP-Zugriffskontrolle RYZENFALL-1 CVE‑2018‑8931,
3. Unuzureichende PSP-Zugriffskontrolle RYZENFALL-2 / -3 / -4 CVE‑2018‑8932,
4. Unuzureichende Zugriffskontrolle bzgl. geschütztem Speicher  FALLOUT-1 / -2 / -3 CVE‑2018‑8933,
5. FW-Backdoor des Promontory-Chipsatzes CHIMERA-FW CVE‑2018‑8934,
6. ASIC-Backdoor des Promontory-Chipsatzes CHIMERA-HW CVE‑2018‑8935,
7. PSP-Rechteausweitung CVE‑2018‑8936.

Das Vorgehen der Sicherheitsfirma nach der Berichterstattung empfinde ich dubios und nicht koscher: kein vernünftiger Vorlauf, brandmarkende Bezeichnungen und alles nur ausnutzbar mit root-Rechten ... das ist Kindergarten.
Dagegen sind Spectre & Meltdown und auch generell Intel CSME / AMD PSP Atombomben, die im ersten Fall Jahrzehnte unentdeckt (trotz warnender Fachartikel) schlummern konnten und im anderen Fall völlig undokumentiert Nutzern und Eigentümern der Hardware auf unseriöse Art und Weise untergeschoben wurden – mit weitergehenden Rechten ausgestattet als root-Rechten.

Spectre Next Generation:  Spectre‑NG  [CVE‑201?‑???? bis ‑????]

Am 03.05.2018 berichtete Heise-online über 8 neue Spectre-Sicherheitslücken, an denen Intel nun arbeite und man ansonsten nichts weitergeben wollte (auch noch keine der acht CVE‑Nr., die man nachreichen wolle). Auch eine viertel Stunde später gab es einen weiteren Artikel (inklusive einer englischen Fassung), der genau so wenig Infos enthielt. Jede Sicherheitslücke muss offenbar separat mit Patches geschlossen werden und bekommt wohl auch einen eigenen Namen. Prinzipiell ähnlich zu den oben unter Spectre-Meltdown beschriebenen drei Varianten (GPZ V1-3), allerdings soll eine der neuen 8 recht leicht und relevant ausnutzbar sein.
Um den 11.07.2018 herum wurden zwei neue Lücken ähnlich Spectre V1 bekannt (siehe z.B. den Bericht über $100000 Preisgeld auf SecurityAffairs): als Bounds Check Bypass Store (=V1.1) und Read-only Protection Bypass (=V1.2) bezeichnet (Intel & AMD sind betroffen, ggf. auch ARM).
Am 24.07.2018 berichtete Heise‑Security von zwei weiteren neuen Sicherheitslücken, die beide den RSB (Return Stack Buffer; somit quasi Spectre umgekehrt) ausnutzen. Da bislang NG4-8 von Intel noch immer unter Verschluss gehalten werden, ist nun das Chaos vorprogrammiert. Die beiden neuen sind ret2spec oder Spectre V5 entdeckt durch das CISPA der Uni Saarland (wohl noch ohne CVE, dafür mit PoC über Firefox 59), bestätigt durch Intel, AMD und ARM, sowie SpectreRSB durch UCR-Forscher (hier kann ggf. sogar Speicher von CPUs ausgelesen werden, die in anderen VMs laufen – ein neuer Spectre V2-ähnlicher Angriff, der SGX aushebelt; zum Schutz wird der schon länger existierende RSP Refilling‑Patch für Linux empfohlen und wie am 26.07.2018 von Phoronix berichtet gibt es einen ersten Patch von SuSE gegen Userspace-Userspace-Attacken).
Am 27.07.2018 berichtete Heise‑Security von NetSpectre, einer neuen Abwandlung von Spectre V1, bei dem RAM über ein langsames Netzwerk (geringe Rate von 15-60 Bits pro Stunde) ausgelesen wird.
Am 05.12.2018 berichtete Heise‑Security von SplitSpectre, einer neuen Abwandlung von Spectre V1, die sich über JavaScript im Browser des angegriffenen Systems ausnutzen lässt, wenn verwundbarer Code (sogenannte Exploitation Gadgets) im Zielsystem existiert.
Am 14.08.2018 berichtete Heise‑Security (und Aktualisierung am 28.08.2018) vom 5. Teil der Spectre‑NG-Lücke: Foreshadow (Intel-Bezeichnung: L1TF = L1 Terminal Fault), der aber aus drei Teilen besteht (aufgeteilt nach dem Angriffsziel: SGX [CVE‑2018‑3615], OS Kernel / SMM [CVE‑2018‑3620] oder VM [CVE‑2018‑3646]; beim ersten Fall spricht man von Foreshadow, bei den beiden anderen von Foreshadow‑NG; alle drei gehören zu Spectre‑NG). In allen drei Fällen ist OoOE das Problem: transiente Out‑of‑Order-Ausführung kann zum Zugriff auf SGX‑Schlüssel bzw. zum Auslesen von RAM des SMM führen. Wahrscheinlich muss die Malware auf demselben CPU‑Kern laufen wie die VM bzw. die SGX‑Enklave – dann wären Systeme sicher, die ganze physikalische Kerne zuordnen (dies erklärt ggf. das Ausschalten von Hyper-Threading durch die OpenBSD-Entwickler). Bei Linux hat die Lösung keine 24 Stunden gebraucht (wie Heise‑Security am 15.08.2018 berichtete): Das bald anstehende Linux 4.19 enthät den Fix, direkt darauf kamen die Mainline-Kernel 4.18.1, 4.17.15, 4.14.63, 4.9.120 und 4.4.148 heraus, die diesen Patch als Backport besitzen – ebenso reagieren Distributionen wie Ubuntu, so Kernel 4.15.0‑32‑generic für 18.04.1 LTS. Betreiber von VMs müssen zusätzlich HyperThreading deaktivieren – was bis zu 50% Performance-Verlust nach sich zieht. Eine Rettung der Performance auf sicherheitskritischen Systemen könnten Kernel‑Maßnahmen wie Core‑Scheduling sein, die aber erst in 2020 oder gar noch später greifen werden, aber bereits diskutiert werden (vgl. Heise‑Artikel vom 11.09.2019).
Ebenso von Interesse ist die offizielle Homepage von Foreshadow. [Foreshadow-Logo]
Am 22.05.2018 kamen nun die ersten Details von Intel [vgl. untere Tabelle, 4)+5), d.h. Spectre V3a+V4; siehe auch US-Cert Alert: TA18-141A vom 21.05.2018)] mit Ergänzungen durch Red Hat, wie von Phoronix sogleich berichtet, ebenso ein deutscher Bericht von Heise sowie ein Update zu Spectre-NG mit Info-Link-Sammlung; ebenso wurde dann am 13.06.2018 die dritte Sicherheitslücke: Lazy FP State Save/Restore [vgl. untere Tabelle, 6)] zu Spectre-NG von Intel veröffentlicht [Intel SA‑00145], wie ebenso von Heise‑Security sowie von Phoronix berichtet; bis Foreshadow ist alles im Heise‑Security‑Bericht vom 14.08.2018 zusammengestellt:

Spectre & Meltdown Classic
1) Bounds Check Bypass(BCB+NetSpectre+SplitSpectre= Spectre V1= GPZ V1)CVE‑2017‑5753,
1a) Bounds Check Bypass Store(BCBS= Spectre V1.1= Spectre‑NG 1)CVE‑2018‑3693,
1b) Read-only Protection Bypass(???= Spectre V1.2= ???)CVE‑20??‑????,
1+) SWAPGS (Spectre V1-Varianten)(???= Spectre V1+= ???)CVE-2019-1125,
2) Branch Target Injection(BTI= Spectre V2= GPZ V2)CVE‑2017‑5715,
3) Rogue Data Cache Load  (RDCL= Meltdown= GPZ V3)  CVE‑2017‑5754,
Spectre-NG
4) Rogue System Register Read  (RSRE= Spectre V3a= Spectre‑NG 2)CVE‑2018‑3640,
5) Speculative Store Bypass  (SSB= Spectre V4= Spectre‑NG 3)  CVE‑2018‑3639,
6) Floating Point Lazy State Save/Restore  (???= Spectre V??= Spectre‑NG 4)  CVE‑2018‑3665,
7a) Foreshadow = L1 Terminal Fault - SGX   (L1TF-SGX= Spectre V?? = Spectre‑NG 5a)   CVE‑2018‑3615,
7b) Foreshadow‑NG = L1 Terminal Fault - OS-Kernel, SMM   (L1TF-OS= Spectre V?? = Spectre‑NG 5b)   CVE‑2018‑3620,
7c) Foreshadow‑NG = L1 Terminal Fault - Virtual Machines   (L1TF-VM= Spectre V?? = Spectre‑NG 5c)   CVE‑2018‑3646,
?2+x) ... ⚠️ Fortsetzung  ⚠️ ...     (Spectre‑NG 6 und 7 sowie ???)CVE‑20??‑????,
Spectre-NG+ (mit RSB)
8) ret2spec  (???= Spectre V5= Spectre-NG+)  CVE‑20??‑????,
9) SpectreRSB  (???= Spectre V???= Spectre-NG+)  CVE‑20??‑????,
Spectre-NG++ (diverse)
10) BranchScope  (???= ??????= Spectre-NG++)  CVE‑2018‑9056,
11) SGXPectre  (???= ??????= Spectre-NG++)  CVE‑20??‑????,
12) SGXSpectre  (???= ??????= Spectre-NG++)  CVE‑20??‑????,
ZombieLoad (aka Microarchitectural Data Sampling [MDS]; diverse)
13) Microarchitectural Store Buffer Data Sampling  (MSBDS= ??????= ZombieLoad)  CVE‑2018‑12126,
14) Microarchitectural Fill Buffer Data Sampling  (MFBDS+YAM= ??????= ZombieLoad)  CVE‑2018‑12130,
15) Microarchitectural Load Port Data Sampling  (MLPDS= ??????= ZombieLoad)  CVE‑2018‑12127,
16) Microarchitectural Data Sampling Uncacheable Memory  (MDSUM= ??????= ZombieLoad)  CVE‑2019‑11091,
17) MDS: Rogue In-Flight Data Load  (RIDL= ??????= ZombieLoad)  CVE‑????‑?????,
18) MDS: Fallout  (???= ??????= ZombieLoad)  CVE‑????‑?????,
19) TSX Asynchronous Abort  (TAA= ??????= ZombieLoad v2)  CVE‑2019‑11135,
20) L1D Eviction Sampling  (L1DES= ??????= CacheOut/RIDL)  CVE‑2020‑0549,
21) Vector Register Sampling  (VRS= ??????= RIDL‑Variante)  CVE‑2020‑0548,
22) Load Value Injection  (LVI= ??????= Spectre/Meltdown Mix)  CVE‑2020‑0551,
∞) ... ⚠️ Fortsetzung folgt ⚠️ ...     (... stay tuned ...)CVE‑20??‑????.

Zu Spectre V4 wurden noch am selben Tag der Veröffentlichung erste Patches zur SSB-Verhinderung im aktuellen Entwicklerzweig von Linux eingebaut, deren Backporting auf die noch unterstützten stabilen Kernelversionen nun vorbereitet werden und noch am 22.05. mit 4.9.102, 4.14.43 und 4.16.11 zur Verfügung gestellt wurden (wie von Phoronix berichtet; unter Ubuntu 18.04 LTS entsprechend 4.15.0-22, 16.04 LTS: 4.4.0-127{+4.13.0-43}, 14.04 LTS{+12.04 ESM}: 3.13.0-149). AMD scheint von Spectre V4 nicht betroffen zu sein, Intel-Microcode steht noch immer aus, für ARM und IBM Power sind Patches vorhanden, aber noch nicht in Mainline eingegangen. Natürlich wieder mit Performance-Einbußen und ebenso sind wieder Microcode-Updates der CPU‑Hersteller gefragt ... bis die CPU‑Hersteller diesem ganzen Cirkus endlich ein Ende machen und das Problem ausmerzen ... Aber die nächsten 2-5 Jahre ist wohl für die Popcorn‑Begleitung gesorgt.
Spectre V5NG 3 scheint nur Intel Core-Mikroarchitektur ab Nehalem beim Kontextwechsel zu betreffen, bei dem Daten anderer Prozesse in den FPU-Registern (d.h. der Fließkomma-Einheit bzw. SSE/AVX) zurück bleiben, und soll bei Linux ab 4.9 wie auch bei Windows und Windows Server bereits gefixt sein – ebenso haben z.B. OpenBSD und DragonFly-BSD mit Patches hierzu begonnen und mit DragonFlyBSD 5.2.2 behoben (vgl. Phoronix-Bericht am 18. Juni 2018): Verwendung von Eager FP state restore durch System‑SW (vgl. Red Hat‑Bericht).
Wie von Heise‑Security am 14.06.2018 berichtet, hat Intel offenbar die Veröffentlichung des Bugs verschleppt und wichtige Betriebssysteme wie OpenBSD (das besonders in Security‑Kreisen einen sehr guten Ruf genießt) erst gar nicht informiert, so dass deren Hauptentwickler Theo de Raadt bei einer Konferenz dieses Vorgehen offen kritisierte und sich Intel zu einer vorgezogenen Veröffentlichung veranlasst sah. Manchmal kann jemanden mit Security‑Hintergrund schon beschleichen, dass offenbar trotz solch gravierender HW‑Fehler, mit denen man eigentlich gar keine Prozessoren neu verkaufen dürfte (zumindest nicht, wenn nicht klar ist, dass nach spätestens zwei Jahren ein kostenloses Update gegen eine in Hinsicht der bekannten und ähnlicher Fehler fehlerlose CPU erfolgt), niemand an einer vernünftig schnellen Behebung interessiert ist. Diese SW‑Patches sind schlechte Flicken – und selbst diese brauchen unverhältnismäßig viel Zeit, was alle Nutzer von Computern und insbesondere Cloud‑Diensten gefährdet. Auf diese Weise kann man nur seinen Ruf auf Dauer auf's Spiel setzen. Es wird Zeit, hier die richtige Flagge zu zeigen und Marketing und Nebelkerzen einmal zurückzustellen.
Die Bezeichnung Kein Loch, sondern Schweizer Käse wird bei Intel noch sehr lange Programm sein, zumal die größte Sicherheitslücke, Intel ME (bzw. neuerdings CSME: Converged Security and Management Engine) mit ungepatchtem Minix, nicht einmal am Rande erwähnt wird. Der Kurs von Intel erinnert an die [Wikipedia-de-Icon]Jungfernfahrt der Titanic, wie auch die späteren beiden Berichte zum aktuellen Verhalten einer der größten und reichsten IT‑Firmen zeigen (vgl. untere Infos zur Intel‑Attacke auf Reverse‑Engineering und zu Intels Dokumentation, die Missverständnisse auslöste; wie man Sprache doch gebrauchen und missbrauchen kann ...; ach wie gut, dass heute kaum noch jemand technisch Ahnung besitzt).
Am 14.11.2018 berichtete Heise‑Security von 7 neuen Sicherheitslücken (2×Meltdown: Meltdown‑PK [Protection Key Bypass] bei Intel ab Skylake {mit MPX und Memory Protection Keys}, Meltdown‑BR [Bounds Check Bypass: bound range exceeded exception (#BR)] bei Intel und AMD; 5×Spectre: Spectre‑PHT [Pattern History Table; wie Spectre V1 und V2], Spectre‑BTB [Branch Target Buffer, wie Spectre V2], Spectre‑STL [Store-to-Load Forwarding, wie Spectre V4], Spectre‑RSB [Return Stack Buffer]), die von den bekannten abgeleitet werden. Intel behauptete in einer Stellungnahme, dass die bereits verfügbaren Schutzmaßnahmen auch gegen die neuen Angriffstypen helfen. Dies ist nach dem Bericht der Wissenschaftler (arXiv:1811.05441) aber nicht richtig, zumal diese die bekannten Schutzmaßnahmen überprüften.
Am 14. Mai 2019 platzte eine weitere Bombe für Intel‑Nutzer: ZombieLoad [ZombieLoad-Logo] oder Microarchitectural Data Sampling (MDS; Intel-Bezeichnung), ein neuer Seitenkanalangriff aus mindestens vier Varianten, der die Abschottung der Speicherbereiche gleichzeitig laufender Prozesse überwindet; Vorbedingung ist, dass sowohl Schadcode als auch Angriffsziel auf demselben Prozessorkern laufen – vor allem bei aktivem Hyper-Threading klappt ZombieLoad eindrucksvoll (vgl. Bericht von Heise-Online, 14.05.2019; ebenso bei Phoronix, einer schönen visuellen Darstellung von [YouTube-Icon] Red Hat und von Linux Weekly News). Zudem wurden frisch zwei neue Meldungen zu Lücken in diesem Zusammenhang veröffentlicht:
Yet Another Meltdown (YAM von Bitdefender), eine MFBDS‑Variante, sowie
die neuen MDS-in-flight-Varianten RIDL und Fallout:
RIDL (Rogue In‑Flight Data Load) stiehlt Daten auf derselben Maschine – und bricht alle Grenzen, d.h. wirkt über Betriebssystem- oder VM‑Grenzen wie SGX‑Enklaven hinaus.
Fallout bricht den Schutzmechanismus KASLR und sorgt für ein Leck sensitiver Hauptspeicherdaten des Betriebssystem-Kernels – dabei sind ironischer Weise die neuen Coffee Lake Refresh i9 CPUs auf Grund der Gegenmaßnahmen bzgl. voriger Lücken anfälliger gegen Fallout.
Für Linux wurden Fixes bereits eine Stunde nach Veröffentlichung (Disclosure) des Problems durch Intel veröffentlicht: 5.1.2, 5.0.16, 4.19.43, 4.14.119 und 4.9.176 (vgl. Kernel Documentation (Zweiter Link) bzw.  Berichterstattung durch Heise-Online und LWN) und ebenfalls bei den BSDs (wie von Phoronix). Vorsicht ist geboten, da diese Patches bislang komplett hinter verschlossenen Türen entwickelt werden mussten, so dass Nachbessurungen mehr als wahrscheinlich sind.
Wie üblich muss auch hier Hyperthreading ausgeschaltet sein und Firmware geupdated werden, um wirklichen Schutz zu gewährleisten ...
Anders als sonst sollen aber die allerneuesten Intel CPUs geschützt sein (zumindest bis Gegenteiliges bekannt wird – und so scheint es nach der oben ergänzten Fallout-Beschreibung auch zu sein  😬  – neben SW-Flicken kommen nun HW-Lümpchen anstatt eines sinnvollen und langsam mal nötigen CPU-Redesigns: HT weg, Spekulationenen über zukünftigen Code {branch prediction} nur in Sicherheit-garantierendem Umfang – ggf. sogar ebenfalls raus, und dafür sauberes effizientes Design; diese erschreckend-unsicheren Abkürzungen  😱  wurden nur von Intel, nicht von AMD oder ARM beschritten – dies macht den langsam extrem deutlichen Unterschied in angreifbarer Oberfläche {attack surface aus}) – AMD soll von MDS nicht betroffen sein, was bei vielen dieser Lücken so gemeldet wurde und sich bislang auch als richtig erwies.
Die Leistungseinbußen durch MDS-Schutz sollen beträchtlich sein ... (siehe erste Benchmarks von Phoronix, 16.05.2019, sowie die erweiterten, 18.05.2019, wobei in beiden Artikeln noch Hyper Threading eingeschaltet ist, was ja nicht möglich ist, wenn man wirklichen Schutz vor MDS haben möchte).
Am 06. Aug. 2019 wurde die SWAPGS Vulnerability (CVE-2019-1125, vgl. 2. Heise-Artikel, 07.08.2019) als neue Variante von Spectre V1 veröffentlicht (vom performance deterioration departement der Linux-Maintainer Grand Schemozzle (LWN-Artikel, 08.08.2019) genannt, da es GS-basierten Datenzugriff betrifft – siehe Red Hat Information und Ubuntu Information; die Lücke wurde ohne Aufhebens durch Microsoft für Windows 10 am 09.07.2019 behoben ... soviel zur Informationspolitik von Intel und Microsoft – die auch zum 1. Heise-Artikel führte), die alle Betriebssysteme alledings nur Intel CPUs mindestens seit Ivybride bis zu deren jüngsten Produkten betrifft und von Bitdefender entdeckt wurde. Auf Linux kosten die Sicherheitspatche ein weiteres Prozent (vgl. Phoronix, 07.08.2019). Und last but not least: hier ist die eigene Seite der SWAPGS-Sicherheitslücke.
Am 12./13.11.2019 wurde eine neue Lavine der Hardware‑Fehler von Intel losgetreten (vgl. Berichte von Heise oder von Linux Weekly News): Mit iGPU Leak (CVE‑2019‑14615) ist erneut eine ausnutzbare Sicherheitslücke in Intels Chipsatzgrafik für Gen 7 bis Gen 9 bekannt geworden (vgl. Phoronix), die durch Mitigation im Linux Kernel am 15.01.2020 auffiel.

Am 28.01.2020 kam nun wieder eine erneute Enthüllung (vgl. Heise-Online, 28.01.2020, sowie Phoronix; siehe auch die obige unendliche Liste) – wieder sind Intel‑CPUs betroffen und wieder wird es zur Behebung der Lücken Performanceeinbußen geben – und wieder einmal liegt es an unvollständigen Sicherheitsvorkehrungen, was bei der aktuellen Flickschusterei ja keinen mehr wundern sollte:
CacheOut/RIDL bzw. L1DES (L1D Eviction Sampling; CVE‑2020‑0549) umgehen bisherige Sicherheits‑Updates für Intel‑Prozessoren.
Zudem gibt es eine neue RIDL‑Variante, VRS (Vector Register Sampling, CVE‑2020‑0548), die statt auf den L1D‑Cache auf die Vektor‑Register abzielt.

Am 10.03.2020 kam nun wieder eine erneute Enthüllung (vgl. Heise‑Online und Phoronix; siehe auch die obige unendliche Liste): Load Value Injection oder kurz LVI (CVE‑2020‑0551 und das Intel Advisory). Auch bei dieser Schwachstelle, die das Intel SGX betrifft, greifen alle vorigen Bemühungen bzgl. Meltdown, Foreshadow, Zombieload, RIDL oder Fallout ins Leere, wobei LVI Spectre‑artige raffinierte Codeschnipsel mit Meltdown‑artigen illegalen Datenflüssen kombiniert.

Um diese Schwachstellen, LVI und Seitenkanal‑Attacken, in den Griff zu bekommen, hat Google einen Patch: SESES Speculative Execution Pass zur Verfügung gestellt (vgl. Phoronix, 21.03.2020 sowie die Aufnahme in LLVM am 11.05.2020), der bei Intel‑CPUs über 90% der Leistung verbrennt, also weniger als 10% der Leistung übrig lässt – dies zeigt das wirkliche Ausmaß der Intel‑Lücken, das man auf Haswell schon weitestgehend erleben durfte.

Am 11.05.2020 kam nun wieder eine erneute Enthüllung (vgl. Heise‑Online und Phoronix): Thunderspy‑Attacke, die bei direktem HW‑Zugriff auf Notebooks durch eine Thunderbolt‑Schwachstelle in unter 5 min den kompletten Zugang ermöglicht. Dies ist eine Erweiterung der bekannten Thunderbolt‑Schwachstelle Thunderclap (vgl. Heise‑Online, 27.02.2019).
Auch hier sieht man wieder, wie Attacken proliferieren, wenn man das wirkliche Problem nicht entfernt. Zudem wird in USB 4.0 Thunderbolt‑Technik stecken ...
Im Moment sollte Intel wirklich bedacht sein, die immense Problemlawine in den Griff zu bekommen – Mitigations genügen nicht.

Es ist und bleibt eben so, dass Software keine Hardwarefehler  beheben kann (auch wenn ich dies von Anfang an betonte, Google sprach nun deutlich davon, dass die Mitigation die Angriffsfläche in jedem Fall vergrößert und somit selbst ein Problem ist: Project Zero, 12.02.2020). Man legt lediglich einen Teppich über ein Loch, das immer noch da ist. Was nötig ist sind komplett neue CPU‑Designs, die nicht mehr den einfachen Weg sondern den richtigen gehen (hierzu bedarf es aber einiger neuer Cache-Strategieen – die heutige spekulativen Zweige, bei denen aller Mist im Speicher ungeschützt liegen bleibt, darf es nicht mehr geben; Monate nach meinem Kommentar gab es einen Bericht auf Heise-Online: Wie sich Spectre und Meltdown auf künftige CPU-Designs auswirken vom 21.08.2018; ich teile nicht alles, aber man sollte die HW kennen und nutzen, wenn man programmiert [C, C++ und Assembler; Java war und ist ein Irrweg – insbesondere, wenn man 💾Programmierern Basistechniken vermitteln möchte] und vor allem [Wikipedia-de-Icon]FOSH muss eine gewichtige Rolle spielen, wenn man solche Probleme wirklich hinter sich lassen möchte – was ebenfalls erzwingt, dass Spionageprozessoren wie Intel ME/CSME und AMD PSP beseitigt werden, was beim Artikel lediglich bis zum Hinweis auf RISC V gedieh und damit eindeutig viel zu kurz gesprungen ist).
Dieser Weg erfordert neben Free Software  auch Free Hardware , mit kompletter Dokumentation und vollkommen ohne Blobs, ohne Branding, das wie beim Android‑Wahnsinn zu ungepatchten Handies führt, obwohl die Patche prinzipiell verfügbar sind. Das selbe Problem taucht auch bei Spectre-(NG) / Meltdown auf, da jeder Motherboard-Hersteller sein eigenes Süppchen kocht und so die meisten Intel-Systeme der letzten fünf Jahre nicht einmal die notdürftigen vorhandenen Patches bekommen haben (dieses generelle Chaos umreißt auch der Heise-Kommentar vom 04.05.2018 an einem konkreten Beispiel).
Zudem hat Windows 10 mit dem April 2018 Update (d.h. Version 1803; vgl. Heise-Bericht vom 01.05.2018) nun möglicherweise wirklichen Meltdown-Schutz geliefert (in Version 1709 klaffe ein gewaltiges Loch, wie im oben zitierten Kommentar nachzulesen ist), dafür wurde aber gleich das Spectre‑V2-Microcode‑Update rausgeworfen (und man benötigt neue Grafiktreiber und adaptierte Software wie z.B. einen neuen Firefox). Dazu kann man kaum mehr etwas sagen ... außer "setzen 6" oder "in die Ecke und schämen" wie vor 100 Jahren, dies wäre hier mehr als angemessen, und auch die Qualität ist eher die vom Mittelalter als von der Neuzeit.
Diese Problematiken werden sich nun mit Spectre‑NG noch deutlich verschärfen, zumal offiziell immer noch kein Einlenken erfolgt. Nicht nur, dass immer noch keine klaren Aussagen zu CPUs ohne diese Probleme gemacht werden – und ohne Intel ME – auch die Veröffentlichung und erst recht das Software-Flickwerk wird wohl noch sehr lange auf sich warten lassen (vgl. Intel verschiebt die ersten Patches – koordinierte Veröffentlichung aufgeschoben, HeiseSecurity-Bericht vom 07.05.2018). Aber vielleicht kommt es dann zumindest nicht zu weiteren peinlichen Vorfällen wie zuvor.
August 2018 ist ein weiterer Monat voller neuer Problem-Meldungen (vgl. Foreshadow), die wieder neue Patches und Microcodes nach sich ziehen werden. Linux ist wohl klar im Bereich Sicherheit sehr weit vorn, aber auch dies kostet, wie Kernelbranch-Maintainer Thomas Gleixner angesichts des Merge-Window (2-wöchige Phase des Sammelns aller Codebeiträge mit positivem Review zum -rc1, was dann in ca. 7 Wochen als neuer Kernel – hier 4.19.0 – veröffentlicht wird) sagte (vgl. Bericht von Phoronix):
Die Speck-Brigade liefert trauriger Weise noch ein weiteres großes Patchset, das die von uns sorgsam aufgebaute und erhaltene Leistung zerstört.
[Anmerkung: Speck ist hier ein Slang-Ausdruck für Spectre, hat also nichts mit dem kontrovers-diskutierten Kompressions-Algorithmus der NSA zu tun.]
Wie bei der Sicherheit dürfte es aktuell kein Allround-Betriebssystem geben, dass sich ernsthaft mit Linux im Bereich Performance (Durchsatz, [Wikipedia-de-Icon]Latenz) messen könnte, dennoch sind die Einbußen (nach Phoronix bzgl. L1TF-Patchen einige Prozent für Standard-Sicherheit, aber bei vollem Schutz für VMs über 50%; ähnlich der 2. Phoronix-Artikel vom 30.08.2018: 7-16% für Standard-Sicherheit bei Intel, wobei AMD deutlich besser wegkommt) deutlich spürbarer als die Zunahme der CPU-Geschwindigkeit seit 2011! Es fehlen neue CPU-Designs ...

Spoiler  (Intel-Problem)

Dies macht auch eine neue Sicherheitslücke deutlich, die wie häufiger vorrangig Intel betrifft, umfassender ausgenutzt werden kann als Spectre und offenbar noch schwieriger zu schließen ist: Spoiler  (vgl. Heise-Online vom 05.03.2019, TheRegister 05.03.2019, Phoronix 05.03.2019). Wie bei Spectre nutzt man den Vorsuch der spekulativen Vorausberechnung aus, um an eigentlich zu schützende Daten zu kommen, allerdings werden bei Spoiler lediglich Verwaltungsdaten des Speichers geliefert. Anstatt sich dem Problem wirklich zu stellen sind nun wieder einmal Software-Änderungen von Intel favorisiert, die wieder Leistung kosten (bislang liegt der Verlust bei gut 30% für Intel-CPUs der Core-Generation, wenn man nicht volles Risiko fahren will; vgl. z.B. Phoronix vom 03.03.2019: The Current Spectre / Meltdown Mitigation Overhead Benchmarks On Linux 5.0, bzw. Phoronix vom 11.03.2019: Spectre/Meltdown Performance Impact Across Eight Linux Distributions) – sowie DRAM-Module mit Härtung gegen Rowhammer-artige Angriffe. Es bleibt zu hoffen, dass Intel bereits an CPUs arbeitet, die die jetzige Form der Branch Prediction nicht mehr verwenden sondern sinnvollere Möglichkeiten nutzen, die nicht in Katastrophen enden müssen, vor denen Forscher schon um die Jahrtausendwende gewarnt hatten. Aktuell hat damit AMD einen gewaltigen Vorsprung bei allen, denen Sicherheit wichtig ist (wem nun einfällt: Unter Blinden ist der Einäugige König, der hat die aktuelle CPU-Situation gut verstanden).
Das Hauptproblem bleibt:   Software – egal ob OS oder Programme wie auch Software in der Hardware, sogenannte Firmware, Microcode oder BIOS genannt, können genau so wenig die Probleme beheben wie man mit einem Schuss auf den Mond gelangen (dafür ist Raketentechnik nötig), ein [Wikipedia-de-Icon]Perpetuum mobile konstruieren kann oder die [Wikipedia-de-Icon]Quadratur des Kreises zustande bekommt. Versuche dieser Art sind einfach peinlich und haben starke Ähnlichkeit mit der [Wikipedia-de-Icon]Diesel‑Affäre, durch die bereits Hunderttausende sterben mussten und man ebenso laufend die Softwarelüge gerade von prominenten deutschen Politikern zitiert, obwohl auch hier eine Lösung nur in Hardware (quasi einem ganzen Chemielabor) möglich ist. Aber die Abgasaffäre geht nur in eine neue Runde – drei Jahre nach offiziellem Bekanntwerden betrügen Autohersteller wohl noch immer, wie z.B. Heise-Auto am 11.06.2018 berichtete, und laut ersten Gerüchten seien Diesel mit der [Wikipedia-de-Icon]kommenden Abgasnorm Euro 6d-TEMP sogar noch giftiger als bislang – kein Wunder, dass in Japan der Diesel von Toyota, Subaru und Nissan abgekündigt wurde. Aber Lügen sind heute populär, da die [Wikipedia-de-Icon]Lobbys stark sind (wie könnte sonst der US-Kongress so etwas absurdes wie eine Copyright-Verlängerung auf bis zu 144 Jahre erwägen, wie von Heise am 19.05.2018 berichtet?) und die Medien beherrschen. Aber bei solchen Dingen muss die Wahrheit früher oder später siegen.

Tod von Simultaneous Multi- / Hyper-Threading (SMT/HT)

Es gibt zumindest drei Sicherheitsschwachstellen, die heute das Abschalten von SMT/HT (d.h. die Nutzung logischer Prozessoren) zumindest auf Intel-CPUs erzwingt. Bereits die erste, TLBleed, hat auf BSD zum Abschalten von HT auf Intel CPUs geführt und sollte zumindest bei Cloud-Servern auch abgeschaltet sein. Mit der neueren zweiten Schwachstelle, Foreshadow, ist nun klar, dass die Nutzung von SMT ein nicht zu unterschätzendes Sicherheitsrisiko darstellt. Die neueste dritte Sicherheitslücke, ZombieLoad [🧟] (Original‑Website) kann ebenfalls mit SMT/HT nicht wirkungsvoll geschlossen werden.
Angsichts neuer CPUs im Multi-Core-Design (d.h. Nutzung physischer Prozessoreinheiten) sollte SMT ohnehin als Auslaufmodell betrachtet werden können (solange effektive Kernel‑Maßnahmen wie Core‑Scheduling auf sich warten lassen; vgl. Heise‑Artikel vom 11.09.2019).

Translation Lookaside Buffer (TLB) Bleed

TLBleed ist eine Sicherheitslücke, die Intels Hyper-Threading in Verbindung mit dem Translation Lookaside Buffer (TLB) ausnutzt, um geschützte Informationen per Seitenkanal abzuschöpfen (siehe Bericht von Heise‑Security vom 25.06.2018; der nächsten Sicherheitslücke PortSmash also nicht unähnlich). Anfang August auf der Blackhat USA 2018 vorgestellt gelingt das Ausnutzen der Lücke auf Intel-Prozessoren verschiedener Generationen in mehr als 99 Prozent der Fälle – dennoch wiegelte Intel ab, da man durch Verwendung von Intels eigenen kryptografischen Primitives TLBleed vermeiden könne – und den niederländischen Forschern für ihre Entdeckung nichts bezahlt wurde und es gab keine CVE-Nummer. Zumindest letzteres sollte man schon als skandalös bezeichnen dürfen. Es ist fraglich, ob Cloud-Server Intels Empfehlungen umsetzen, so dass Intels HT eher abgeschaltet werden sollte, wie es auch [Wikipedia-de-Icon]auf OpenBSD sinnvoller Weise getan wurde.

PortSmash:   neue CPU-Seitenkanal Sicherheitslücke  [CVE-2018-5407]

PortSmash [CVE-2018-5407] ist laut Bericht von Phoronix vom 02. Nov. 2018 (vgl. auch Bericht von oss-security vom selben Tag; bzw. der Heise‑Secutity‑Bericht zwei Tage später) eine neue Sicherheitslücke, die von universitären Forschern entdeckt wurde und zu einem Datenleck der beim SMT gemeinsam genutzten Ausführungs-Einheit führt. Für Intels Hyper Threading existiert bereits ein Konzeptbeweis; somit sollte SMT/HT auf sicherheitskritischen Systemen nicht mehr verwendet werden. IBM POWER und AMD CPUs könnten ggf. ebenso betroffen sein, wohingegen diese von der vorigen Sicherheitslücke TLBleed nicht betroffen sind.
[Da diese Sicherheitslücke nichts mit spekulativer Ausführung zu tun hat, gibt es keinen Zusammenhang mit Spectre & Meltdown!]

Bemerkung zu Spionage-Coprozessoren:  Intel ME & AMD PSP

Eines soll hier auch noch erwähnt werden: Spionage-Coprozessoren.
Es gibt bei Intel (ME: Management Engine; [Wikipedia-de-Icon]Infos auf Englisch) und bei AMD (PSP: Platform Security Processor) selbstständig agierende Spionage‑Chips (die einzig passende und in Free & Open Source Kreisen häufig verwendete Bezeichnung, so z.B. Besides starting buggy spyware, what function does early boot firmware serve? {also ... fehlerhafte/verwanzte Spionage-Software ...} im englischen Blog-Artikel von Alison Chaiken mit Titel Analyzing the Linux boot process), die priorisierten Zugang auf alle PC/Server-Komponenten ermöglichen, was die CPU und damit das Hauptbetriebssystem, das der Benutzer bzw. der Administrator sieht, nicht einmal mitbekommt. Es gibt auch hierzu eine ausnutzbare Sicherheitslücke in ME – und natürlich auch in PSP (letztere nach Berichten vom 05.01.2018)! Auch hier sollten Intel und HW-Hersteller Firmware nachliefern, die gerade für die Privat-Systeme zumeist noch ausstehen und ein Ausnutzen bereits für beide Hersteller bekannt ist. Dieser Unsinn darf in künftigen CPUs nicht mehr enthalten sein, sie haben keine sinnvolle Funktion und sind auf Gund Ihrer hohen Priorität das interessanteste Angriffsziel fü Kriminelle ([Wikipedia-de-Icon]Black Hats bzw. Cracker). AMD hat eine Option des Ausschaltens zu Verfügung gestellt, bei Intel scheint dies deutlich komplizierter.
Da Intel ME wie AMD PSP Scheunentorgroße Sicherheitslücken reißen, sind die wirklichen Probleme noch lange nicht aufgedeckt. Somit ist es auch kaum möglich, die bekannte CVEs zu listen. Intel ME hat z.B.: CVE‑2017‑5689 (Bericht vom 22.11.2017); CVE‑2017‑5705, CVE‑2017‑5706 und CVE‑2017‑5707 (Bericht vom 23.11.2017); CVE‑2017‑5705, CVE‑2017‑5708, CVE‑2017‑5711 und CVE‑2017‑5712 (Bericht vom 21.11.2017 mit& späterem Update); ... – bei AMD PSP z.B.: CVE‑2018‑???? (nicht zugeordnete PSP-Lücke vom Januar 2018); CVE‑2018‑8932 (AMD Ryzen and Ryzen Pro processor chips have insufficient access control for the Secure Processor: RYZENFALL-2, RYZENFALL-3, und RYZENFALL-4), CVE‑2018‑8936 (AMD EPYC Server, Ryzen, Ryzen Pro und Ryzen Mobile Prozessor-Chips erlauben PSP Privileg-Ausweitung) [vgl. AMD Flaws]; ... .
Am 20.07.2018 berichtete Heise‑Security von drei neuen Sicherheitslücken der Intel ME (betroffen Intel Active Management Technology: Versionen 3.x bis 11.x): CVE‑2018‑3628 (Verarbeiten von HTTP‑Anfragen), CVE‑2018‑3629 (Denial‑of‑Service‑Attacke aus dem gleichen Netz), sowie CVE‑2018‑3632 (weniger brisanter Speicherfehler).
Auch diese haarsträubende Realisierung dieser Management-/Sicherheits-Prozessoren wurde von Google aufgeklärt, sehr ausführlich analysiert und auf deren Systemen durch Abschalten und weitestgehendes Ersetzen der Firmware inkl. eines Mini-Linux zum Booten ersetzt. Dies können selbst die meisten Computerfirmen nicht nachmachen – geschweige denn Privatpersonen. Freie (UEFI-)BIOS-Alternativen wie Coreboot werden bewusst verhindert, wie von der Free Software Foundation (FSF) immer wieder analysiert und beklagt.
Dass man solchen Betrug (selbst Google mit seinen Server-Farmen wurde offenbar überrascht – und ein ungepatchtes Minix jahrelang als [Wikipedia-de-Icon]Ring 0 laufen zu lassen – das nenne ich vorsätzliche Schädigung; bislang wurde diesen Vorwürfen nicht widersprochen, ich habe mich davon nicht überzeugt und nehme gerne anderslautende Fakten auf) vornehmen kann – nicht nur ungestraft, sondern ggf. von undemokratischen Regierungen befohlen, ist unglaublich. Google ersetzte die Firmware zum Großteil mit Linux – und diese Speziallösung wird hoffentlich bald bei Servern wie Workstation (d.h. PCs) allen zur Verfügung stehen, was die Ankündigung des Projekts LinuxBoot (von der Linux Foundation am 25.01.2018 [LinuxBoots Vorläufer war NERF]) hoffen lässt. Dies wurde bereits ausführlich im Artikel des renomierten Online-Magazins Linux Weekly News: Replacing x86 firmware with Linux and Go vom 20.11.2017 beschrieben und erneut im Artikel LinuxBoot: Linux as firmware vom 07.03.2018 aufgegriffen (inkl. Erläuterung des Boot-Vorgangs).
Aber der kleine Sonnenstrahl, der durch die schwarzen Wolken hindurchstach, ist auch schon wieder abgeschottet:   Offenbar wurde nun eine neue Runde eingeläutet – anstatt selbst den Code offen zu legen und dafür zu sorgen, dass ihre eigenen Kunden sicher mit Intel‑HW arbeiten können, sorgt Intel (unabhängig davon, ob after receiving a courtesy request from Intel's Director of Software Infrastructure  oder Intel politely asked Purism to remove this document which Intel believes may conflict with a licensing term eher den Tatsachen entspricht, hust) für die Rücknahme von Informationen zu Reverse-Engeneering-Erfolgen bei Intels Firmware Support Package durch Purism (wie von Phoronix am 11.05.2018 berichtet). Es gleicht wie oben bereits dargestellt wirklich dem Diesel-Skandal wie ein faules Ei dem anderen ... Ein Kommentar des obigen Berichts meint: ein weiterer Grund, AMD-Hardware zu kaufen. Sie bedrohen keine Freiwilligen, die sich für ein offenes Ökosystem des Wettbewerbs einsetzen. Nicht, dass AMD eine saubere Weste hätte – aber dieses Vorgehen ist zumindest aktuell nicht mit AMD in Verbindung zu bringen. Was soll man da noch ergänzen?
Vielleicht, dass Intels ehemals umworbenes Sicherheitsfeature MPX (Memory Protection Extensions) wohl aus GCC 9 entfernt werden wird (vgl. Bericht auf Phoronix vom 27. April 2018), weil der Code nicht mehr vernünftig supported wird, obwohl Intel-Entwickler von Zeit-zu-Zeit Patche beigesteuert haben, und der Code generell so schlecht ist (klare Untertreibung: im aktuellen Kernel funktionslos [broken]), dass ebenso ein Rauswurf aus dem Linux-Kernel erwogen wird (siehe Phoronix-Bericht vom 28. April 2018). Beides ist mittlerweile vollzogen. Wer will da noch zweifeln, dass die Presseverlautbarungen, Intel nähme Security sehr ernst (Zitat als Stellungnahme zu Spectre-NG: Protecting our customers' data and ensuring the security of our products are critical priorities for us, vgl. Heise-Bericht), wirklich von Herzen kommen?
Und da ich zuvor schon bemängelte, dass Intel nicht selbst Ihre Probleme löst, sondern wie bei Spectre & Meltdown lieber andere den Karren aus dem Dreck ziehen lässt, haben ein paar unbedeutende Betriebssysteme (wie – hust – Linux, Windows, macOS und FreeBSD) offenbar eine Intel-Dokumentation einer CPU-Funktion missverstanden (so die Deutung des Heise-Berichts vom 11.05.2018), so dass nun fast alle Betriebssysteme anfällig für Manipulationen des Kernel-Speichers waren – Updates wurden bereits verteilt (CVE‑2018‑8897: POP SS / MOV SS Vulnerability; vgl. Liste betroffener Systeme). Vielleicht will Intel nVidia ganz anders Konkurrenz machen, als es die meisten zunächst verstanden haben ;)
Bzgl. der Hardwarehersteller sieht Sicherheit komplett anders aus als was dort geboten wurde – und eine Privatsphäre sollte zur Not auch mit Zivilcourage gegen zu nachgiebige Hardwarehersteller oder unsinnige Regierungsbestrebungen erkämpft werden (in Deutschland heißt das Stichwort: Bundestrojaner [auch hier behält man sich vor, Sicherheitsprobleme nicht zu melden], in den USA: NSA).
Eine Demokratie erkennt man an guter Pressedarstellung der Fakten, Gewaltenteilung, freien Wahlen (ohne jegliche Beeinflussung vom Wahlgang bis zum Ergebnis) und dem überall geltenden Grundsatz: in dubio pro reo (im Zweifel für den Angeklagten). Es gibt noch viele weitere Kriterien, aber die Verletzung eines dieser Dinge sorgt für ein komplettes Aushebeln eines demokratisch angelegten Systems. Aktuell ist fraglich, ob man noch irgendwo auf der Welt angesichts der extrem einflussreichen global agierenden Unternehmen von einer Demokratie sprechen kann.
Es ist bedauerlich, dass gerade in Deutschland – trotz historisch klar erkannter Probleme durch den Staat – man immer noch keinerlei Linie der moralischen Grenzen zu ziehen in der Lage ist. Zu einer Zeit, in der nicht nur die CIA damit prahlt, auf jeden Rechner im Internet jede Datei ablegen zu können und alle Spuren perfekt zu verwischen, sondern mittlerweile jeder mit IT-Erfahrung in jeden beliebigen Computer einbrechen kann (warum ist auf dieser Seite deutlich dokumentiert – natürlich ohne Anleitung oder Beispielcode) muss ausgerechnet der Vorstoss kommen, verbrecherische Software, unser aller Staatstrojaner (eine reine Spähsoftware) durch Einbruch in Wohnungen von Verdächtigen aufzuspielen. Und die Kriminiellen, die dies wollen und sogar fordern, sind keine anderen als die Länder-Justizminister – da wurde wahrlich der Bock zum Gärtner gemacht. Es ist wirklich weit mit den sogenannten Demokratien gekommen, wenn dies als ernster Vorstoß von Staatsorganen gemacht werden kann und man dies dann allenfalls in Computer-Zeitschriften bzw. deren Online-Version lesen kann (siehe Bericht von Heise, 08.06.2018). Die einzigen, die sich langsam unter diesen Bedingungen wohl fühlen, sind die Verbrecher – die wissen, wie man sich schützt – haben Anwälte auf Ihrer Seite und genügend Geld durch ihr kriminelles Wirken, um politisch Einfluss zu nehmen (durch Parteispenden, Aufsichtsratsposten, sonstige kleinen Geschenke zur Teambildung) – was mittlerweile ja vollkommen normal ist und nicht mehr als Bestechung gewertet werden darf.
Es wird Zeit, dass man Menschenrechte klar formuliert und in einer Verfassung Schutz gewährt, die auch nicht für eine Stunde durch kriminelle oder zumindest handwerklich schlechte Gesetze außer Kraft gesetzt werden können. Der Bürger darf nicht entmündigt werden und Datenschutz muss endlich dem Bürger dienen, nicht einer skrupellosen Abmahn-Industrie. Der Einzelne müsste die [Wikipedia-de-Icon]Datenkraken verklagen können, dass es diesen riesigen Unternehmen wirklich weh tut. Stattdessen habe anständige Menschen und Vereine in Deutschland zu Recht Angst, eine Website zu betreiben (durch die unsinnig gestaltete DSGVO: einen Vorgeschmack zeigte Heise Security am 25.05.2018). Nicht nur aber auch dadurch, dass erst nach den ersten Urteilen klar wird, was ein Gesetz in Deutschland eigentlich bedeutet. Kein Jurist würde Gesetzestexte lesen – sondern die Kommentare dazu, die die einschlägigen Urteile berücksichtigen. Diese Form des Rechts geht an Bürgern komplett vorbei und ist das Gegenteil von Transparenz – es bedeutet für den Bürger ohne Rechtsbeistand oder Jura-Studium schlicht Willkür. Man kann sich für unser Land nur noch schämen, egal, wohin man auch schaut.
Zur Zeit ist an autonomes Fahren, ferngesteuerte problematische Systeme (Energieversorger etc.) oder unkontrollierte Robotereinsätze nicht zu denken – wer so etwas auch nur duldet ist selbst kriminell, und niemand kann sagen, er hätte von der Problematik nichts gewusst.
Eine Übernahme von essentieller Infrastruktur durch terroristische Gruppierungen wird durch die Fülle an Sicherheitslücken immer wahrscheinlicher und wird sogar von öffentlichen Sendern immer mal wieder dargestellt, wenn auch peinlich verzerrt (da technisch unqualifiziert dargeboten – es ist schwer zu glauben, dass dies nicht bewusst erfolgt).
Und die Regierungen der meisten Staaten unterstützen die Schwächung der Sicherheit und erhöhen die Terrorgefahr auf diese Weise erheblich, obwohl sie viele Aktionen dieser Art vorgeblich nur machen, um den Terrorismus zu bekämpfen. Die Geheimdienste sind die wahren Terrorzentralen, nicht wie von diesen immer wieder beschuldigt die größeren IT-Unternehmen.
Man sollte nicht vergessen, dass Osama bin Laden und seine Leute von US-Geheimdiensten ausgebildet wurden, wie vielfach ohne Widerspruch berichtet wurde. Ohne Geheimdienste gäbe es ggf. noch Terror, aber die Gefährdung wäre deutlich geringer. Und den heutigen Terrorismus hätte es ohne Geheimdienste nie gegeben.
Man sollte dem maßlosen Treiben der Geheimdienste, nicht nur aber insbesondere auch der Sammelwut der NSA Einhalt gebieten (auch in Europa entwickeln wir einen Hang zum Überwachungsstaat, wie ein Kommentar von Heise-Online vom 10.03.2019 nochmals untermauert; selbst die wichtige Funktion der Whistleblower oder der Mut zur Zivilcourage, ohne den keine Demokratie auskommt, wird immer weiter kriminalisiert). Von den IT-Firmen wird immer wieder auf die NSA verwiesen, wenn Schwierigkeiten auftauchen. Gerade für diese Spionage-Prozessoren ist dieser Zusammenhang bedeutsam. Dass diese der Überwachung der Systeme durch die Eigner-Firmen diene ist Unsinn – hierzu gab es schon immer Lösungen, die wohl dokumentiert und auch in den Updateplänen der IT-Unternehmen enthalten waren. Und das Ganze unter Trusted ... Environment oder ähnlichen Begriffen laufen zu lassen ist reiner [Wikipedia-de-Icon]Zynismus, es macht selbst für DRM (korrekt digital restrictions management, da der Benutzer bei digitalen Medien beschränkt werden soll – ähnlich einer Kindersicherung) in dieser Form keinen Sinn. So gibt es immer wieder Diskussionen, ob Intel ME und AMD PSP von der NSA oder anderen Geheimdiensten/Regierungskreisen angeordnet wurden, so dass diese Gefahr gar nicht entfernt werden darf, was aber dringend nötig wäre.
Diese stellen auf Dauer eine deutlich höhere Bedrohung dar als obige Probleme um Spectre/Meltdown, zumal der Eigentümer keinen Einfluss hat und nachweislich keine vernünftige Update-Strategie dieses höchstpriorisierten Systems im System Anwendung fand. Dieser Skandal hat eine viel größere Bedeutung und macht alle Computernutzer, egal ob Firmen oder Privatpersonen, auf Dauer angreifbar. So mutet es ausgesprochen lächerlich an, wenn offiziell bekanntgegeben wird, Die NSA wusste nicht von der Schwachstelle, hat sie nicht ausgenutzt und freilich würde die US‑Regierung nie ein großes Unternehmen wie Intel einem Risiko aussetzen, um eine Angriffsfläche offenzuhalten.
Das ist entweder Realsatire, oder es wäre eine ganz neue Richtung, denn dies kam als Strategie zuvor vielfach vor. So ging die EFF offiziell gegen die NSA wegen des [Wikipedia-de-Icon]Heartbleed-Bugs vor [siehe unten; eine viele Jahre alte Sicherheitslücke, die auf vielen Servern immer noch offen ist, trotz schnell verfügbarer Fixes].
Daher wäre es eher naheliegend, dass die NSA durch ME/PSP gar keine weiteren Zugriffsmöglichkeiten im x86-Umfeld mehr braucht, zumal Zugriffe auf ME/PSP komplett unbeobachtet vonstatten gehen und allenfalls im Netz-Traffic mit extrem viel Mühe auszumachen wären. Die beschriebenen Sicherheitslücken Meltdown/Spectre wären deutlich nachvollziehbarer und auch sofort Computern zuzuordnen.
Man sollte sich vor Augen halten: Server und Desktops sind das Sicherste, das die IT zu bieten hat; IoT (Internet der Dinge: Lampen, Heizung, Jalosien etc., aber auch Multimedia-Systeme in Autos etc.) und Smartphones, Tablets und Laptops sind noch viel unsicherer, wenn man überhaupt noch von Sicherheit sprechen kann.
Beide Aspekte einer unsicheren Computerlandschaft: Schlampigkeit / Hast und Wunsch nach allumfassendem Zugriff sollten nachhaltig bekämpft werden.
Es wird höchste Zeit!

SegmentSmack:  Fehler im Linux Netzwerk Bereich  [CVE‑2018‑5390]

Der Fehler, der seit Linux 4.9 existiert, kann über remote denial of service attack ausgenutzt werden und ist bei Bekanntgabe am 07. Aug. 2018 (siehe Heise‑Security vom 07.08.2018 bzw. Phoronix-Artikel auf Englisch) bereits seit 2 Wochen im Mainline-Kernel gefixt. Somit ist z.B. Ubuntu 18.04 LTS ab Kernel 4.15.0‑30.32 vom 03. Aug. 2018 gefixt. Details über die Schwachstelle sind im Red Hat security advisory zu finden.

Holey Beep:  System Piep  [CVE‑2018‑0492]

Auch wenn es hier einiges über Sicherheit zu lernen gibt, so ist die Bedeutung doch recht begrenzt ...
Der Name Holey Beep kommt von der als Satire zu verstehenden Website (von den Machern der Dirty Cow-Website unten), wobei ein seriöser Hintergrund im LWN-Artikel What the beep? (vom 11.04.2018) zu finden ist.

Dirty Cow:  Copy‑on‑Write-Linux‑Problem  [CVE‑2016‑5195]

Dieser Fehler ist ernster als der zuvor erwähnte Holey Beep, wurde wie von LWN berichtet (am 20.10.2016) mit den Linux-Kernel-Versionen 4.8.3, 4.7.9, und 4.4.26 behoben.
Wie zuvor gibt es auch hierzu eine humorige Website (von den Machern der zuvor erwähnten Holey Beep-Website).

Shellshock:  Bash-Sicherheitslücke  [CVE‑2014‑6271]

Eine leicht ausnutzbare Sicherheitslücke in der Standard-Shell der Linux‑Distributionen: BASH, sorgte am 24. Sep. 2014 für Aufsehen unter dem einprägsamen Namen Shell-Shock (Heise-Bericht vom 24.09.2014; vgl. [Wikipedia-de-Icon]Shell-Shock Information von Wikipedia bzw. deren [Wikipedia-de-Icon]Seite zur BASH).
Betroffen waren die Bash-Versionen zwischen 1.03 und 4.3. [Shellshock-Logo]

Heartbleed:  OpenSSL-Sicherheitslücke  [CVE‑2014‑0160]

Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL war der Titel des Heise-Berichts vom 08.04.2014 für diese Sicherheitslücke, die mit OpenSSL 1.0.1 am 14. März 2012 eingeführt und mit OpenSSL 1.0.1g am 07. April 2014 behoben wurde (vgl. [Wikipedia-de-Icon]Heartbleed Information auf Wikipedia bzw. deren [Wikipedia-de-Icon]Open-SSL Versionshistorie).
Eine Sicherheitslücke, die etwas auf sich hält, hat eine eigene Website. [Heartbleed-Logo]

FDIV-Bug im Intel-Pentium

Zu einer Zeit, zu der CPU-HW-Fehler kein Thema waren, machte Intel bereits von sich Reden durch einen Bug im Pentium 60 und 90, der vom inzwischen verstorbenen Mathematikprofessor Dr. Thomas Nicely von der Uni Lynchburg am 30.10.1994 zum wiederholten Mal (Intel wusste seit mindestens Juni bescheid; daher beim 2. Mal inkl. Autoren und Journalisten) gemeldet wurde: der FDIV‑Bug (vom fehlerhaften x86‑Gleitkomma-Assembler‑Befehl: Floating Point Divides; vor dem 486‑er wurden immer mathematische Co‑Prozessoren benötigt).
Auch damals wollte Intel nicht angemessen reagieren. Nachdem aber jeder die Fehler in beliebigen Standardprogrammen finden konnte, wurden die CPUs ersetzt. Davon kann man heute nur träumen, da extremste Fehler über Jahre in der Produktion verbleiben – und zu Höchstpreisen verkauft werden [ 🤮 ].
Der Pentium-Bug wurde sehr gut von Andreas Stiller (Heise‑Online, 30.10.2014) zum 20. Bug-Geburtstag zusammengefasst.
[Persönliche Anekdote: Ich habe vor diesem Fehler mit Einführung der PC/Linux Workstations mit noch 32 Bit auf diesen wie auf den etablierten Digital Alpha Workstations mit 64 Bit wissenschaftliche Programme aus denselben Quelltexten ablaufen lassen und die Ergebnisse beider Plattformen verglichen – und beide lieferten identische Ergebnisse. Kollegen haben mich angesprochen, warum ich mir diese Arbeit machte – als dann der Pentium-Bug auftrat, waren die Kollegen erstaunt, dass dies wirklich sinnvoll war.
Noch geschockter bin ich vom Lehramt, bei dem an Gymnasien mittlerweile von Beweis per Taschenrechner gesprochen wird ...]
[YouTube-Icon]Konsuminfarkt, Systemfehler, (16.07.2013, Musik zum Film, vgl. [YouTube-Icon]Trailer & Filmclips)   [[YouTube-Icon]Wenn Inge tanzt, Systemfehler, Offizielles Video, 17.05.2013]
Link zum 🐧persönlichen Hintergrund.
Bei Fragen / Problemen mit dieser Seite bzw. meiner Webpräsenz kontaktieren Sie mich bitte:
      E-Mail:  📧jmb@jmb-edu.de
© 1995-2024 JMB           Bitte beachten Sie hierzu auch mein 📄Impressum.                   W3C: Valid HTML 4.01 Transitional
[Zurück zur 🏁Startseite]
Erste Fassung:29. März 2018
Letzte Änderung: 01. Januar 2024