W.S. schrieb:> Es ist lediglich eine Einfallstür für Leute, die ein ERHEBLICHES> Spitzbuben-Potential besitzen.
Kann es sein dass du das aktuelle Risiko-Potential etwas zu gering
einschätzt?
Offensichtlich können die Lücken sogar mit JS genützt werden; und viel
schlimmer: Virtualisierung ist anfällig (und das in Zeiten von Azure und
AWS/EC2 und wie sie alle heissen). Heisst für mich: ich miete einen
Mini-Server für lau, und in Kürze hab ich Host und alle VMs
übernommen...
Unterhalte dich mal mit einem Security-Experten deines Vertrauens... mir
macht das Angst
W.S. schrieb:> Wer von euch Programmierern kennt sich denn z.B. in den Details> internationalen Seerechts aus?
Wahrscheinlich keiner. Allerdings wird auch keiner auf die Idee kommen,
eigenhändig ein Schiff über internationale Schifffahrtsstraßen zu
steuern.
> oder in den Details von Geologie und Bergbau oder den Details, die ein> Zahnarzt wissen muß? He?
Gleiches Thema: Da ich diese Details nicht kenne, werde ich eben einfach
keine Zähne aufbohren und füllen. Aber ausgerechnet bei sowas komplexem
wie einem Computer wird erwartet, dass er für jeden auch ohne
Vorkenntnisse so leicht zu bedienen ist wie ein Toaster.
Selbstverständlich soll man dabei aber trotzdem alles damit machen
können, und sicher soll es auch noch sein.
Rolf M. schrieb:> Allerdings wird auch keiner auf die Idee kommen, eigenhändig ein Schiff> über internationale Schifffahrtsstraßen zu steuern.
Hab' ich schon gemacht. ;-) Allerdings war ein Kapitän dabei, der die
Verantwortung trug und die nötigen Rechtskenntnisse hatte … Hat Spaß
gemacht, bspw. durch die Brücke über den Großen Belt zu fahren.
Gut, aber das nur, weil du es erwähntest. :)
Anders als W.S. sehe ich schon den Bug. Habe schon zu viele Huftiere
sich vor der Apotheke übergeben sehen, als dass man davor die Augen
verschließen sollte. Ganz plötzlich wissen die Spitzbuben dann halt
doch, wie man in kürzester Zeit eben tatsächlich interessante Nadeln
in diesem 8 GiB großen Heuhaufen finden kann … konnte doch keiner
ahnen, dass die wirklich so spitz(buben)findig sein würden, oder?
F. F. schrieb:> Ich habe das nur im Radio gehört und das sagten sie, dass Intel schon> neue Prozessoren hätte, die diese Sichereitslücke nicht hätten. Deshalb> schrieb ich das überhaupt.
Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Alles ich derzeit von Intel zu lesen finde, läuft auf die PTI Patches
raus.
Michael R. schrieb:> AWS/EC2 und wie sie alle heissen). Heisst für mich: ich miete einen> Mini-Server für lau, und in Kürze hab ich Host und alle VMs> übernommen...
Die sind die erste Adresse für solche Spielchen und wissen das auch.
Deshalb tut sich da ja auch was.
A. K. schrieb:> Ich gehe daher davon aus, dass zukünftige Prozessoren sich nicht sehr> von den aktuellen unterscheiden werden. Aber Mechanismen enthalten> werden, die den Performance-Einbruch der Adressraumtrennung abmildern> oder eliminieren.
PS: Zumindest dürfte das Meltdown und dessen Abwehr entschärfen.
Bei Spectre bleibt es spannend.
Da scheint wohl doch was per Microcode zu gehen, zumindestens fuer
"Variant 2: branch target injection (CVE-2017-5715)"
Red Hat Security Advisory 2018-0013-01
https://packetstormsecurity.com/files/145650
1
Red Hat Security Advisory 2018-0013-01
2
3
The microcode_ctl packages provide microcode updates for Intel and AMD
4
processors.
5
Security Fix: An industry-wide issue was found in the way many modern
6
microprocessor designs have implemented speculative execution of
7
instructions. There are three primary variants of the issue which differ in
8
the way the speculative execution can be exploited. Variant CVE-2017-5715
9
triggers the speculative execution by utilizing branch target injection.
10
11
It relies on the presence of a precisely-defined instruction sequence in
12
the privileged code as well as the fact that memory accesses may cause
13
allocation into the microprocessor's data cache even for speculatively
14
executed instructions that never actually commit. As a result, an
15
unprivileged attacker could use this flaw to cross the syscall and
16
guest/host boundaries and read privileged memory by conducting targeted
A. K. schrieb:>> Virtualisierung ist anfällig> Aus dieser Ecke fand bisher allenfalls heisse Luft. Hast du mehr dazu?https://googleprojectzero.blogspot.co.at/2018/01/reading-privileged-memory-with-side.html
Ich lese das so:
Bounds Check bypass (Spectre) - works cross VM
Branch Target Injection (Spectre) - works cross VM
Rogue Data Cache Load (Meltdown) - does not work cross VM
Ich hab aber grad eine andere Idee: Beide Attacken nutzen als
side-channel ja das Timing (einmal cache hit/cache miss, einmal
branch/call predictor), und das jeweils mit dem guten alten TSC... macht
man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte
vielleicht per Microcode implementiert werden?
Hans schrieb:> Wenn überhaupt müsste man Microcode Updates für die CPUs fordern falls> möglich.
Formal betrachtet und aus Sicht der Anwälte "ja", denn dann spielt das
BS keinerlei Rolex weil der Patch dann auf den Betriebssystemen laufen
muß die der Prozessor unterstützt.
73
Toxic schrieb:> Meine Dell-Lappies sind nicht betroffen - woher die Info? Nun zumindest> nicht von heise.de sondern von Intel und einer von Dell gefuehrten> Auflistung.
wo bitte? hab auch Dell...
Kaj G. schrieb:> Da scheint wohl doch was per Microcode zu gehen, zumindestens fuer> "Variant 2: branch target injection (CVE-2017-5715)"
Ich frage mich allerdings, ob damit zwar die jetzige Version von Spectre
ausgehebelt wird, aber bald die nächste Methode ansteht, das
grundlegende Problem auszunutzen.
Michael R. schrieb:> macht> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte> vielleicht per Microcode implementiert werden?
Vorstellbar. Nebenwirkungen allerdings nicht ausgeschlossen. Nur
adressiert auch das nur die verwendete Methode, das Problem auszunutzen,
nicht aber das Problem.
F. F. schrieb:> A. K. schrieb:>> Denn "kauft sofort einen neuen Prozessor,>> aber keinesfalls von uns" bringts irgendwie nicht, oder? ;-)>> Ich habe das nur im Radio gehört und das sagten sie, dass Intel schon> neue Prozessoren hätte, die diese Sichereitslücke nicht hätten. Deshalb> schrieb ich das überhaupt.
Da drängen sich Parallelen zum Dieselskandal auf. Einen Hardwarefix gibt
es nicht, nur Softwareupdates. Zur endgültigen Lösung des Problems muß
eine neue CPU her. Vielleicht zahlt Intel bald eine Abwrackprämie in
Form von Rabatten auf neue Prozessoren und kurbelt damit den Verkauf an.
Microsoft reibt sich auch schon die Hände, weil die neuen CPUs nur noch
unter W10 laufen. Wie immer zahlen die Endkunden die Zeche. Ist der Ruf
erst ruiniert, verdient es sich ganz ungeniert...
Michael R. schrieb:> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte> vielleicht per Microcode implementiert werden?
Wobei die Technik der Virtualisierung, die von VMware genutzt wurde, als
x86 eigentlich noch nicht virtualisierbar war, auch in der Lage sein
könnte, solche Verhaltensänderungen der ISA zu implementieren.
A. K. schrieb:> Michael R. schrieb:>> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte>> vielleicht per Microcode implementiert werden?>> Wobei die Technik der Virtualisierung, die von VMware genutzt wurde, als> x86 eigentlich noch nicht virtualisierbar war, auch in der Lage sein> könnte, solche Verhaltensänderungen der ISA zu implementieren.
Hängt vermutlich davon ab, ob sich RDTSCx trappen lässt... so wie damals
beim FDIV
Icke ®. schrieb:> Ist der Ruf erst ruiniert, verdient es sich ganz ungeniert...
Oder das triggert eine längerfristige Veränderung in der IT, in der
manche Platzhirsche am Ende dastehen wie Heizer in der E-Lok. Nämlich
dann, wenn sich aufgrund von über die Jahre wiederkehrenden Attacken auf
das Grundprinzip hochkomplexer spekulativer Prozessoren die bisherige
Nutzungsweise von IT-Geräten wesentlich verändert.
Michael R. schrieb:> Hängt vermutlich davon ab, ob sich RDTSCx trappen lässt...
Soweit ich mich erinnere scannt oder emuliert die besagte alte
Virtualisierungstechnik die Befehle, bevor sie das erste Mal per
Hardware ausgeführt werden, um jene rauszufischen und zu ersetzen, die
einer Virtualisierung im Weg standen. PUSHF war wohl so ein Kandidat.
Als VMware anfing war x86 in sich nicht vollständig virtualisierbar. Für
das Statusregister gab es im VM86 Mode für DOS ein virtuelles
Interrupt-Flag, nativ aber nicht. Ohne schmutzige Tricks ging das also
überhaupt nicht.
A. K. schrieb:> Michael R. schrieb:>> macht>> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte>> vielleicht per Microcode implementiert werden?>> Vorstellbar. Nebenwirkungen allerdings nicht ausgeschlossen. Nur> adressiert auch das nur die verwendete Methode, das Problem auszunutzen,> nicht aber das Problem.
Hmmm... das kann man so oder so sehen. Auf die schnelle fällt mir jetzt
außer Timing kein "aus der Ferne nutzbares" sideband ein. Und wenn man
das sideband zumacht, wären auch zukünftige andere Attacken zumindest
erschwert.
A. K. schrieb:> Oder das triggert eine längerfristige Veränderung in der IT, in der> manche Platzhirsche am Ende dastehen wie Heizer in der E-Lok. Nämlich> dann, wenn sich aufgrund von über die Jahre wiederkehrenden Attacken auf> das Grundprinzip hochkomplexer spekulativer Prozessoren die bisherige> Nutzungsweise von IT-Geräten wesentlich verändert.
Ich glaube nicht an den Weihnachtsmann. Um noch eine Parallele zur
Automobilindustrie zu ziehen, hat sich das Nutzungsverhalten dort
geändert, weil die Karren aufgrund immer komplexerer Technik
störanfälliger werden und die Betriebskosten drastisch nach oben gehen,
weil Wartung und Reparaturen teilweise nur noch von Vertragswerkstätten
zu Apothekenpreisen ausgeführt werden können? Nein, die Leute kaufen
noch dickere Boliden mit noch mehr Schnickschnack zu noch höheren
Preisen.
Der gemeine IT-User hat doch kaum ein Wahl, das Nutzungsverhalten wird
von den Monopolisten diktiert. Siehe die Absprachen zwischen
CPU-Herstellern und MS bezüglich Betriebssystemunterstützung. Der
Vernetzung kann sich auch keiner mehr entziehen, die wird ihm teilweise
per Order Mufti aufgezwungen (z.B. elektronische Abgabe von Steuer- und
SV-Meldungen) oder ist aus wirtschaftlichen Gründen unvermeidbar, um
konkurrenzfähig zu bleiben. Privatusern ist es mittlerweile sowieso
scheißegal, was mit ihren Daten passiert. Die sind genauso gierig nach
hippem Schnickschnack und geben freiwillig Unsummen dafür aus.
Das Nutzungsverhalten wird sich erst ändern, wenn du eines Tages ohne
totale Vernetzung nicht mal mehr ein Brötchen kaufen kannst und dann der
große Crash kommt...
Icke ®. schrieb:> Ich glaube nicht an den Weihnachtsmann.
Ich hab ihn gesehen, ebenso Intel und Microsoft. Die sahen vor einigen
Jahren durch Mobilgeräte wie Tablets breits ihre Felle davonschwimmen
und reagierten. Kam dann doch nicht so wie befürchtet, aber...
Jungs macht euch locker. Alles was passiert ist lässt sich schnell in
wenigen Sätzen zusammenfassen:
Die Speicherbereiche bei Systemen mit INTEL-Architektur wurden endlich
liberalisiert! Vorbei ist es mit dem bisherigen Speicher-Nationalismus,
dieser auf strickte Grenzen setzenden altbackenen Abschottung. Man
erhofft sich mit dieser Öffnung die Umsatzzahlen kräftig anzukurbeln.
Von der Liberalisierung sollen vor allem das Kern-Geschäft mit neuen,
dann noch besseren, sichereren INTEL-Prozessoren profitieren. Die
Analysten warten bereits auf die neuen Produkte.
Ihr IT-Berater des Vertrauens erwartet Sie als Kunden noch heute in
Ihrem nächst gelegenen Medwida-Markt (alternativ bei Sutarn).
Jau! Die Deregulierung rollte nach 30 Jahren endlich auch den PC-Markt
auf. Speicherverwaltung und Sicherheit? Sozialistischer Humbug! Die
Umsätze steigen und steigen, die Blasen werden grösser und grösser.
Icke ®. schrieb:> Siehe die Absprachen zwischen> CPU-Herstellern und MS bezüglich Betriebssystemunterstützung
Hä? Wieso braucht es da Absprachen? Wenn Microsoft will das nur noch
Windows 10 auf neuen Kisten läuft, dann programmieren die entsprechend.
Sven D. schrieb:> Hä? Wieso braucht es da Absprachen?
Als AMD die 64-Bit x86 ISA definierte, signalisierte Microsoft an Intel,
dass sie bitteschön auf den Zug aufspringen mögen, statt selber etwas in
dieser Richtung zu definieren. Sonst seien sie bei 64 Bit x86 draussen.
A. K. schrieb:> Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Mein Gott, wie borniert du doch bist.
Die berichteten da, dass die Sicherheitslücke nur mit neuen Prozessoren
zu beseitigen sei, Intel aber schon Prozessoren habe, die diese
Sicherheitslücke nicht hat.
F. F. schrieb:> Mein Gott, wie borniert du doch bist.
Danke für die Blumen. Aber ich bin über die Jahre mit dem "Stille Post"
Spiel der Medien einigermassen vertraut geworden. Daher ist nicht ganz
unwichtig, woher eine Information stammt und wieviele andere Leute
zwischen der letzten sachkundigen Quelle und der Präsentation sitzen.
Soll heissen: Ich versuche, nicht unbesehen alles wörtlich zu glauben,
was ich irgendwo höre oder lese. Sondern ziehe es ab und zu vor,
gegenzuchecken. Aber ich weiss, dass ich damit in der Minderheit bin.
Es ist schon klar, wenn man etwas genauer wissen will, dass es dann
nicht reicht Radio zu hören.
Aber für die Annahme, dass Intel den Markt ankurbeln will, weil gerade
die höherwertigen Prozessoren (z.b. i 7) nicht die erhofften
Verkaufszahlen brachten.
Ich weiß von dir, dass du auch nicht mehr so ganz jung bist und die
Anfänge noch kennst. Intel hat über Jahre Zuwachsraten im zweistelligem
Prozent Bereich gehabt.
Wo sie aktuell liegen weiß ich nicht. Vor einigen Jahren hatten sie
immer noch 13%, was so nicht schlecht für andere Firmen wäre, aber nur
zwei Jahre vorher hatten sie 25,...% gehabt.
Und heute?
Wo fängt ein Büro Computer an (der so für die meisten Heimanwender
völlig reicht), ist es nicht um die 300 €?
Dabei ist dann schon satt Software.
Aber die meisten kaufen nicht mal mehr diese, weil ihnen ihr Tablet und
Mobiltelefon reicht.
F. F. schrieb:> Mein Gott, wie borniert du doch bist.
Ähem, Foldi, das hat sich A.K. bestimmt nicht verdient. Er gehört
zu denen, die hier allemal am ausgewogensten daherkommen.
F. F. schrieb:> Aber für die Annahme, dass Intel den Markt ankurbeln will, weil gerade> die höherwertigen Prozessoren (z.b. i 7) nicht die erhofften> Verkaufszahlen brachten.
Ich bräuchte eine einigermassen glaubhafte Quelle für
> dass Intel schon neue Prozessoren hätte, die diese Sichereitslücke> nicht hätten."
Ich hatte daraufhin gesucht, und nichts in dieser Richtung gefunden.
Lediglich etwas Info, die man in dieser Richtung missverstehen kann. Die
sich aber tatsächlich auf OS-Patches bezieht und evtl. auch
Microcode-Patches.
Bis dahin ist das für mich Spekulation. Hier im Thread wurde auch schon
spekuliert, dass es nur so qualmt, ohne dabei mehr Grundlage zu haben
als ein Bauchgefühl und allgemeine politische und wirtschaftliche
Ansichten.
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Laut orf.at haben die zusammengearbeitet.
http://orf.at/stories/2421147/2421148/
A. K. schrieb:> Soll heissen: Ich versuche, nicht unbesehen alles wörtlich zu glauben,> was ich irgendwo höre oder lese. Sondern ziehe es ab und zu vor,> gegenzuchecken. Aber ich weiss, dass ich damit in der Minderheit bin.
Apropos glauben, ich kann auch gar nicht glauben was MS mir da gerade
alles frisch als Update getarnt 1) reingespült hat auf meinem Rechner:
Hier der Inhalt fürs liebe Excel
http://download.microsoft.com/download/4/6/E/46EE95B4-7B13-4157-BAD1-854D4FA4855A/4056894.csv
1)
2018-01 – Monatliches Sicherheitsqualitätsrollup für Windows 7 für
x64-basierte Systeme (KB4056894)
Installationsdatum: 05.01.2018 09:36
Installationsstatus: Erfolgreich
Updatetyp: Wichtig
In einem Microsoft-Softwareprodukt wurde ein Sicherheitsproblem
festgestellt, das Auswirkungen auf Ihr System haben könnte. Durch die
Installation dieses Updates von Microsoft können Sie zum Schutz Ihres
Systems beitragen. Eine vollständige Liste der Problembehebungen in
diesem Update finden Sie in dem entsprechenden Microsoft Knowledge
Base-Artikel. Nach der Installation dieses Updates müssen Sie das System
gegebenenfalls neu starten.
Weitere Informationen:
http://support.microsoft.com/help/4056894
Hilfe und Support:
http://support.microsoft.com/help/4056894
W.S. schrieb:> Wer von euch Programmierern kennt sich> denn z.B. in den Details internationalen Seerechts aus?
Frag mal was Konkretes, mit etwas Glück kann ich's dir beantworten,wenn
es nicht zu vertrackt ist.
Aber die Frage ist gut gewählt, wie beim internationalen Seerecht ist es
schwierig Greift die Hoheitlich Gesetzgebung nur bei Wirken der
Beteiligten vom Hoheitsgebiet aus. Alles weiter ist Vertragsrecht.
Allerdings gibt es die Seefahrt betreffend Schon lange internationale
Abkommen. Das internationale Recht das Internet betreffend steckt
dagegen in den Kinderschuhen. muss aber kommen.
Wie im Seerecht mauern die Staaten allerdings wenn die Eigenen
Souveränität z.B. der Marine betroffen ist. Im Internet nehmen die
Geheimdienste diese Position ein.
Namaste
A. K. schrieb:> Aber ich bin über die Jahre mit dem "Stille Post"> Spiel der Medien einigermassen vertraut geworden.
Doktorarbeiten: teilweise falsch abgeschriebene Bedeutung von
Theoriebegriffen, -> leicht falsche Hauptannahmen -> die ganze Arbeit
für die Tonne - wie auch die anschließenden Veröffentlichungen.
"Schuld" z.T. maßlose Übertreibung mit Fachbegriffen oder anderen
abstrakten Wörterwelten.
Medien: die wiederholen seit etwa 20 Jahren penetrant 3 - 5
Kampfbegriffe, nach politischem Gusto, das ist nicht stille Post, das
ist Gehirnwäsche.
Stille Post wäre ein gutes Beispiel für einen "lebendigen" Vorgang.
(Medienimitation für einen Bot wäre im Moment viel einfacher, als stille
Post Imitation).
Mampf F. schrieb:> Mal eine dumme Frage ... Wenn unter Linux der gesamte> Physikalische> Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch> überhaupt?
Er verhindert das dieser im Betriebsystem offene Sidechanal mit
legitimierter Software für Illegitime Zugriffe benutzt werden kann.
Er verhindert nicht, das Schadsoftware welche der User dummerweise
installiert und mit passender Prio ausstattet (wissend oder nicht) die
bekannten Lücken auch zukünftig nutzt.
was Apple jüngst zum Anlass nimmt wieder einmal darauf hinzuweisen SW
nur via Appstore zu beziehen.
Namaste
Jörg W. schrieb:> Ganz plötzlich wissen die Spitzbuben dann halt> doch, wie man in kürzester Zeit eben tatsächlich interessante Nadeln> in diesem 8 GiB großen Heuhaufen finden kann
OK. Sämtliche Spitzbuben dieser Welt hätten das bereits vor etwa 10
Jahren wissen und ausnützen können. Nehmen wir also mal an, daß
tatsächlich alle Spitzbuben, denen dies wichtig und machbar war/ist,
selbiges bereits seit langem praktiziert haben.
Was ich sehe, ist ein sehr unguter Zug dieser Zeit, der darin besteht,
alles und jedes nur noch im und mit Netzwerk und Internet tun zu wollen.
Guck in die Läden, guck auf's Publikum in U-Bahn und Bus, was die
machen. Das Nutzungsverhalten ist massiv vom stationären PC zu
Smartphones und Tablets übergegangen und ein jeder, der mit sowas
herumfuchtelt, ist eben eine Zielscheibe für obige Spitzbuben. Es ist
nicht das Stück Hardware, sondern die allzeitige Verbindung in den
elektronischen Urwald.
Das sind - mal ganz kurz gefaßt - eben UNSICHERE STRUKTUREN.
Mir hatte es schon vor langen Jahren nicht geschmeckt, daß sowohl Apple
als auch Google aus der Ferne auf Millionen von Mobiltelefonen Dateien
gelöscht hatten.
Entsinnst du dich daran?
Das waren die Vorboten, die zumindest mir klar gemacht hatten, daß man
auf allen Systemen, die an fernzugänglichen Netzwerken hängen, auf gar
keinen Fall wirklich sensible Daten halten darf.
Wer es dennoch tut, steht eben mit beiden Beinen auf unsicheren
Strukturen und braucht sich nicht zu wundern, wenn er ne Zielscheibe für
Spitzbuben abgibt.
Dabei wäre es ja einfach, dem zu begegnen: Zwei PC's, einer mit all dem,
was einem wirklich wichtig ist, der andere für's Herumdaddeln im
Internet. Also Trennung der Sphären auf die brachiale Art. Das hilft
zumindest jedem Privaten.
Die Probleme bei den Rechenzentren in den Netzwerken und allgemein im
Internet sind was anderes. Aber für sowas sollten eigentlich keine
PC-Komponenten, sondern Mainframes benutzt werden, die für
sicherheitsrelevante Arbeiten geeignet sind. OK, die kosten dann auch
was.
Aber keiner hat in den letzten Jahre von Sicherheitsbedenken wirklich
etwas hören oder sehen wollen. Auch hier in diesem Forum nicht (* s.u.).
Ich kann das verstehen, die Leute fassen eben diese Vernetztheit als
einen Zugewinn an Lebensqualität auf. Vielleicht ist es das ja auch -
aber eben wie ein siamesischer Zwilling mit einem "Zugewinn" an
Unsicherheit verbunden.
Es geht in die falsche Richtung:
- möglichst alles drahtlos,
- Daten in der Cloud,
- IOT,
- zwangsweise elektronische Übermittlung von sensiblen Daten an die
Obrigkeit,
- Software, die sich nur dann benutzen lassen will, wenn sie ins
Internet kommt,
- Verwendung von PC-Komponenten und PC-Software für Zeugs, wo das
eigentlich nicht hingehört - von der AKW-Steuerung über Bankautomaten
bis zur Fahrtenplanung bei Bahn und Bus.
Ich sehe das so, daß sich wohl gar nichts in die richtige Richtung
ändern wird, weil alle Leute jedem Hype begeistert nachrennen. Die Leute
werden es wohl nie begreifen, daß man sich im elektronischen Wald eben
nicht mit einem Paßwort oder ner Girlande wo "Firewall" draufsteht gegen
die elektronischen Wölfe schützen kann.
W.S.
(*) Ich kann mich entsinnen, daß auf meine Bedenken bezüglich
sicherheitskritischer Strukturen damals von "Spezialisten" geantwortet
wurde, daß men eben bessere Virenscanner benötigte...
W.S. schrieb:>> Die Probleme bei den Rechenzentren in den Netzwerken und allgemein im> Internet sind was anderes. Aber für sowas sollten eigentlich keine> PC-Komponenten, sondern Mainframes benutzt werden, die für> sicherheitsrelevante Arbeiten geeignet sind. OK, die kosten dann auch> was.
Und sind vor allem nicht weniger betroffen, denn deren Performance wäre
unterirdisch, würden sie nicht heute genau so gebaut sein wie die bösen
PC CPUs. Und ja, ich habe schon Assembler-Code auf Mainframes
geschrieben. Und zwar zu Zeiten, als der noch nicht spekulativ
ausgeführt worden ist.
Winfried J. schrieb:> Mampf F. schrieb:>> Mal eine dumme Frage ... Wenn unter Linux der gesamte>> Physikalische>> Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch>> überhaupt?>> Er verhindert das dieser im Betriebsystem offene Sidechanal mit> legitimierter Software für Illegitime Zugriffe benutzt werden kann.>> Er verhindert nicht, das Schadsoftware welche der User dummerweise> installiert und mit passender Prio ausstattet (wissend oder nicht) die> bekannten Lücken auch zukünftig nutzt.
Das versteh ich nicht ...
Ich hab gelesen, dass man mit Meltdown auf jede Zelle des physischen
Speichers zugreifen kann und dagegen gibt es imho dann keinen Schutz.
Man findet den Kernel evtl nur nicht so leicht.
Egal ob es jetzt legitimierte Software ist, die böses macht oder
Schadsoftware (imho eh das gleiche).
Mampf F. schrieb:> Ich hab gelesen, dass man mit Meltdown auf jede Zelle des physischen> Speichers zugreifen kann
Von der Art des Bugs her kann Meltdown eigentlich nur den gesamten
virtuellen Speicher des aktuellen Prozess-Adressraums lesen, Userspace
und Kernelspace. Egal ob er offiziell zugreifen darf oder nicht. Sollte
allerdings der physikalische Speicher vollständig in den virtuellen
Kernelspace gemappt sein, dann geht das natürlich.
> und dagegen gibt es imho dann keinen Schutz.
Die PTI (Page Table Isolation) Patches der Betriebssysteme sorgen dafür,
dass der Kernelspace im Userkontext eines Prozesses nicht mehr Teil des
Prozess-Adressraums ist. Dann kommt Meltdown nicht mehr an den
Kernelspace ran, somit auch nicht an den darin gemappten physikalischen
Speicher.
Ich konnte lesen, dass bei diesem Problem Virenscanner und Firwall
schräge Aktivitäten bezüglich dieser "Lücke"bemerken würden. Wo sind
denn eigentlich die von der "Snakeoil Fraktion" zu diesem Thema? Im
übrige denke ich wird zur Zeit dieses Thema zu heiß gegessen. Die
wirklich bösen Buben denke ich waren bis dto. ahnungslos. Klein Erna und
groß Hugo werden auch in Zukunft ruhig schlafen können. Intel hat
mittlerweile eine Liste betroffener CPU´s veröffentlicht. Von AMD hat
man noch nichts vernommen.
Kaj G. schrieb:> Ich musste schon sehr lachen :D
Der Vergleich hinkt. Im Sinn von Meltdown schickt dich das Navi (branch
predictor) in die Bar. Aber nachdem du merkst, dass das nicht der Weg
nach Hause ist, kommst du wieder raus. Nur kannst du dich an nichts mehr
erinnern. Was drin passierte lässt sich jedoch aus dem Seiteneffekt
rekonstruieren, dass dein Cash leer ist (du aber voll).
A. K. schrieb:> Der Vergleich hinkt. Im Sinn von Meltdown schickt dich das Navi (branch> predictor) in die Bar. Aber nachdem du merkst, dass das nicht der Weg> nach Hause ist, kommst du wieder raus. Nur kannst du dich an nichts mehr> erinnern. Was drin passierte lässt sich jedoch aus dem Seiteneffekt> rekonstruieren, dass dein Cash leer ist (du aber voll).
Das Navi schickt Dich selbstsicher in die Bar. Dort gibst Du Dein Geld
aus und trinkst. Dann erst bemerkt das Navi, daß es Dich dort nicht
hätte hinschicken dürfen. Es versucht jetzt schnell noch alles zu
vertuschen, besticht den Kellner daß er das Geld wieder rausrückt, etc.
- aber letztlich erkennt man doch noch an der Fahne wo Du warst.
Gerd E. schrieb:> Dann erst bemerkt das Navi, daß es Dich dort nicht> hätte hinschicken dürfen.
Nope. Diese Sorte Navis merkt das nicht. Das merkt man erst selber. Ein
branch predictor korrigiert sich nicht selbst, sondern wird von der
execution unit korrigiert.
Auch kriegst du den Inhalt vom Cash (Cache) nicht wieder. Das ist es ja
gerade, anhand dessen Meltdown merkt, was drinnen passiert ist.
Winfried J. schrieb:> Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert> ist?
Ich hoffe dies beruhigt dich: ;-)
Rob Joyce, White House cybersecurity coordinator, said, “NSA did not
know about the flaw, has not exploited it and certainly the U.S.
government would never put a major company like Intel in a position of
risk like this to try to hold open a vulnerability.”
A. K. schrieb:> Ich hoffe dies beruhigt dich: ;-)>> Rob Joyce, White House cybersecurity coordinator, said, “NSA did not> know about the flaw, has not exploited it and certainly the U.S.> government would never put a major company like Intel in a position of> risk like this to try to hold open a vulnerability.”
Da haben wir ja noch mal Glück gehabt ;-)
A. K. schrieb:> Ich hoffe dies beruhigt dich: ;-)
Ja genau, weil der Dienstgeber dem von Ihm Beauftragten Dienst ein
Alibi ausstellt.
Bitte! Nur wegen so einer Erklärung ist doch nicht die Begehrlichkeit
ausgeräumt oder gar ein solcher Dienst rein gewaschen. Also jetzt
erstaunst du mich doch etwas. Soll ich dir mein Ironieschild leihen?
Ein Dementi im falschen Augenblick und ohne Not verkündet, damit kenne
wir Ossis uns aus, da klingelt es Alarm und die Erdschlussklappe fällt
aus dem Klappenschrank.
Namaste
Winfried J. schrieb:> Bitte! Nur wegen so einer Erklärung ist doch nicht die Begehrlichkeit> ausgeräumt oder gar ein solcher Dienst rein gewaschen. Also jetzt> erstaunst du mich doch etwas. Soll ich dir mein Ironieschild leihen?
Könnte es sein, dass du deinen Detektor grad schon verliehen hast. ;-)
Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch
für fragwürdig.
Fakt ist, es ist ein Stück Hardware, welche man nicht eben ändern kann.
Eine Softwarelücke ist schnell gepatcht bzw. verschwunden und
hinterlässt dabei kaum Spuren. Die werden solch ein Risiko sicher nicht
eingehen. Von daher glaube ich Ausnahmsweise auch, was die NSA sagt :)
Trotzdem kann man sich nicht sicher sein. Vielleicht hat Intel auch eine
entsprechend große Hand aufgehalten, für den Fall des Falles. Wer weiß.
Aber Spekulationen haben noch nie viel gebracht...
Billiger Kommentator schrieb:> Aber Spekulationen haben noch nie viel gebracht...
rofl
Hier dein Ironischild bitte sorgfältig benutzen.
Erklär das mal den Jungs an de Börse.
Namaste
Winfried J. schrieb:> der liegt grad unter der Glaskugel und sucht nach der witzigen Stelle in> deinem Post. ;)
Die Kugel ist sicherlich schon länger in deinem Besitz und daher
befangen, das wird dann nichts. Ironie wird nicht immer als witzig
empfunden. Besonders nicht von jenen, die man damit auf den Arm nimmt.
;-)
Billiger Kommentator schrieb:> Aber Spekulationen haben noch nie viel gebracht...
Besonders schlecht ist, wenn spekulative Codeausführung für Angriffe
ausgenutzt werden kann.
Bei der ganzen Aufregung wird leider oft vergessen, dass sich die
Prozessoren durchaus spezifikationskonform verhalten, d.h. das
Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie
man es "gemäß Lehrbuch" erwarten würde. Es geht hierbei nicht um eine
fehlerhafte Implementierung, die ursprünglich vielleicht einen IP-Block
betraf und anhand derer man dessen Weitergabe hätte verfolgen können.
Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze
Zeit offen! Daher wird man auch Intel usw. auch nicht juristisch ans
Bein pinkeln können. Die Art und Weise, wie die Prozessoren aufgebaut
sind, entsprach eben bis vor ein paar Monaten dem aktuellen Stand der
Technik. Neuerdings aber eben nicht mehr.
Billiger Kommentator schrieb:> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch> für fragwürdig.
Dann ist dir was entgangen. Die sammeln Daten von jedem,
Bewegungsprofile werden erstellt und sogar ein Zusammenhang hergestellt.
Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder
ob sie da ist, wo sie angibt zu sein, dann frag die NSA. Hast du die
riesigen Serverfarmen nicht gesehen. Riesige Gebäude.
Andreas S. schrieb:> Bei der ganzen Aufregung wird leider oft vergessen, dass sich die> Prozessoren durchaus spezifikationskonform verhalten, d.h. das> Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie> man es "gemäß Lehrbuch" erwarten würde.
Wobei ich zwischen Meltdown und Spectre etwas unterscheiden würde.
Bei Meltdown kann man drüber streiten, ob ein spekulativ ausgeführter
Load im unzulässigen Fall wirklich die realen Daten liefern sollte. Das
muss nicht sein, wie man an AMD sieht. Auch wenn nicht nur Intel
betroffen ist, sondern auch diverse ARMs, sehe ich das schon als Bug.
Bei Spectre hingegen liegt es voll im Prinzip der Arbeitsweise. Weshalb
auch wirklich jeder betroffen ist, es nur vielleicht bei manchen
schwieriger auszunutzen ist.
> Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze> Zeit offen!
Wobei noch die eine oder andere Stinkbombe platzen könnte. Denn
ausnutzbare side channels sind schon länger bekannt. Dass es möglich
sein kann, Crytoverfahren über ähnliche side channels abzugreifen ist
schon seit Jahren bekannt und davon hatte ich auch schon mal gehört. Bei
Fefe sammeln sich grad ein paar Links über frühe Erkenntnisse darüber:
https://twitter.com/TheSimha/status/949361495468642304https://twitter.com/cperciva/status/949216126331887616
F. F. schrieb:> Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder> ob sie da ist, wo sie angibt zu sein, dann frag die NSA.
Da würde ich eher Google fragen, die haben Handy standort Daten (für
W-Lan ortungs verbesserung), Mails vom Gmail Account, Browser history,
eventuell noch einige Fotos und andere Daten über Google Drive & co
(z.B. deine What's App Nachrichten vom online Backup), etc. Ziemlich
lückenlose geschichte.
A. K. schrieb:> Stinkbombe platzen könnte
fehlplatzierter Konjunktiv
ersetzte durch FuturII
-platzen könnte +geplatzt sein wird
Von der zukünftigen Vollendung kann bereits sicher ausgegangen werden.
Namaste
Andreas S. schrieb:> Bei der ganzen Aufregung wird leider oft vergessen, dass sich die> Prozessoren durchaus spezifikationskonform verhalten, d.h. das> Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie> man es "gemäß Lehrbuch" erwarten würde. Es geht hierbei nicht um eine> fehlerhafte Implementierung, die ursprünglich vielleicht einen IP-Block> betraf und anhand derer man dessen Weitergabe hätte verfolgen können.>> Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze> Zeit offen! Daher wird man auch Intel usw. auch nicht juristisch ans> Bein pinkeln können. Die Art und Weise, wie die Prozessoren aufgebaut> sind, entsprach eben bis vor ein paar Monaten dem aktuellen Stand der> Technik. Neuerdings aber eben nicht mehr.
Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die
Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,
wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms
verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben
manchmal darauf verzichten.
Carl D. schrieb:> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben> manchmal darauf verzichten.
Das gehört zum Thema "Abwehr bestimmter Angriffe". Genau darüber sichert
man sich nun in Browsern gegen Spectre per Javascript ab, über das
Sessions sich gegenseitig belauschen können. Das wäre auch ein Thema für
Microcode-Updates, also RDTSC ausreichend zu jittern.
Nur: Es ändert nichts am Prinzip. Das Grundproblem von Spectre, dass
sich Prozesse gegenseitig beeinflussen, bleibt. Man braucht nur einen
neuen Weg, das auszunutzen.
F. F. schrieb:> Billiger Kommentator schrieb:>> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch>> für fragwürdig.>> Dann ist dir was entgangen. Die sammeln Daten von jedem,> Bewegungsprofile werden erstellt und sogar ein Zusammenhang hergestellt.> Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder> ob sie da ist, wo sie angibt zu sein, dann frag die NSA. Hast du die> riesigen Serverfarmen nicht gesehen. Riesige Gebäude.
Naja, hier wird von Seiten der USA auch bewusst versucht einen Mythos
aufrechtzuerhalten, nämlich den der (angeblichen) permanenten
Totalüberwachung und damit Allwissenheit über so ziemlich jeden von uns,
insbesondere der eigenen Bürger. Das mag vereinzelt schon mal so sein,
aber wenn das immer so wäre, wäre es auch ein leichtes gewesen
beispielsweise das FBI vorbeizuschicken, als der Trump Clan sich mit
einer russischen Anwältin traf, zum "Informationsaustausch" (man könnte
es auch Spionage nennen) über einen bzw. eine mögliche nächste
US-Präsidentin (lies Äußerungen von Steve Bannon dazu). Das hätte einen
Skandal gegeben und womöglich die paar Prozent abgehalten ihn (Trump) zu
wählen, die ihn knapp ins Amt beförderten.
Jetzt wird natürlich wieder ein Schlaumeier daherkommen und sagen, klar
hat die NSA das alles gewusst und aufgezeichnet sowieso, nur halt aus
bestimmten Gründen nicht verwertet. Nur sind wir dann wieder bei den
beliebten Verschwörungstheorien, die immer dann sich Raum verschaffen,
wenn es gilt: "Nix genaues weiß man nicht".
Bedenke, je mehr Informationen gesammelt werden, desto schwieriger wird
es daraus noch das Wissenswerte zu filtrieren. Kennt jeder von seiner
eigenen Festplatte. Je mehr Info, desto gröber muss das Suchraster sein,
um in angemessener Zeit noch das zu finden, was man sucht und im Fall
der NSA ist es mit der Suche allein auch nicht getan. Irgendjemand muss
das Gefundene dann auch noch bewerten und selbst beim Einsatz von KI
wird man nicht um eine individuelle und damit zeit- und
personalaufwändige Einschätzung dieser Daten herumkommen.
Hierzulande braucht es mehr als zwei Dutzend Spezialisten um auch nur
EINEN mutmaßlichen Gefährder (Islamisten) rund um die Uhr zu überwachen.
Glaubt du diese Arbeit könnte die NSA aus der Ferne mittels ihrer
Computer übernehmen, so dass man sich die Spezialisten hierzulande
einsparen könnte? Ich nicht!
Wüssten sie bei der NSA zu jeder Zeit immer alles, wäre Edward Snowden
wohl die Flucht niemals geglückt.
Alles Humbug schrieb:> klar> hat die NSA das alles gewusst und aufgezeichnet sowieso
Sicher nicht alles, aber schon 'WannaCry' hat ja gezeigt, das die Damen
und Herren der NSA durchaus Sicherheitlücken in populärer Software
verschweigen, wenn es ihnen nützlich erscheint, wobei das 'Security' in
der Bezeichnung ihrer Behörde dann ein wenig nach blankem Hohn klingt.
Eine Attacke mit Spectre oder auch Meltdown hat zudem den Vorteil, das
so gut wie jedes Stückchen Software, das sich das Opfer auf den Rechner
lädt, unauffällig im Hintergrund seine Schnüffelarbeit tut - ideal für
Massenangriffe auf Privatdaten. Und diesmal muss es nicht mal Windows
sein, wie sonst immer. Es reicht ein Intel oder AMD, und damit sinds
auch die Apples und Linuxe.
Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so
ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf
spekulative Ausführung umschwenkten. Das ist aber eine Plattform, bei
der neben Verfügbarkeit bestimmt auch Sicherheit ein wichtiges Thema
ist.
Zwar sind die nicht erste Adresse bei der Ausnutzbarkeit, weil da
seltener Fremdcode ohne weiteres draufhuschen dürfte, als es bei Clouds
oder Clients der Fall ist. Aber dafür sind die Kunden empfindlicher.
Matthias S. schrieb:> Eine Attacke mit Spectre oder auch Meltdown hat zudem den Vorteil, das> so gut wie jedes Stückchen Software, das sich das Opfer auf den Rechner> lädt, unauffällig im Hintergrund seine Schnüffelarbeit tut - ideal für> Massenangriffe auf Privatdaten.
Konzeptfehler auszunutzen hat gegenüber Software-Bugs einen schwer
wiegenden Nachteil: Man sitzt genauso tief in der Tinte wie alle
anderen, ohne etwas dagegen tun zu können. Wenn ich als NSA ein Leak
ausnutzen will, dann achte ich darauf, das ich es bei Bedarf schnell
stopfen kann. Andernfalls kann das auch jeder andere ausnutzen.
Mal auf Handys bezogen: Wetten, dass es in Nordkorea praktisch keine
betroffenen Handys gibt? Aber umgekehrt hat Nordkorea seit Datum
xx.yy.20zz einen auf einem fehlerhaften Konzept beruhenden
Freifahrtschein für Angriffe auf Handys in den USA. Also da würde ich
als NSA nicht gut schlafen.
A. K. schrieb:> Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so> ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf> spekulative Ausführung umschwenkten.
PS: Hätte die NSA das Thema damals auf dem Radar gehabt: Hätten die
nicht ausgerechnet dort diesen Weg verhindern müssen? Das wäre vmtl auch
niemandem aufgefallen, denn ein Beharren auf nichtspekulativer
Ausführung kann man in diesem Sektor auch anders begründen.
A. K. schrieb:> PS: Hätte die NSA das Thema damals auf dem Radar gehabt: Hätten die> nicht ausgerechnet dort diesen Weg verhindern müssen? Das wäre vmtl auch> niemandem aufgefallen, denn ein Beharren auf nichtspekulativer> Ausführung kann man in diesem Sektor auch anders begründen.
Unterstellen wir mal sie hatten es nicht "auf dem Radar". Was sagt uns
das dann über deren Fähigkeiten bei der NSA Sicherheitslücken zu finden,
um Spähsoftware dort einzuschleusen? Oder anders ausgedrückt, hat Google
vielleicht oder sogar anscheinend doch bessere Experten auf diesem
Gebiet als einer der bestausgerüsteten Auslandsgeheimdienste der Welt?
Alles Humbug schrieb:> Oder anders ausgedrückt, hat Google> vielleicht oder sogar anscheinend doch bessere Experten auf diesem> Gebiet als einer der bestausgerüsteten Auslandsgeheimdienste der Welt?
Den attraktiveren Arbeitsplatz bietet sicherlich Google. Besonders für
jene, die man nur unter Einsatz von Gewalt in Organisationen wie die NSA
kriegt.
Mit Geld kannst du Aufwand erschlagen, aber keine Ideen erzwingen. Das
funktioniert öffentlich besser als geheim.
Einer hat in einem Bürokratieapparat eine halbgare Idee. Chef sagt:
vergiss es! Ende der Geschichte. Öffentlich machen ist keine
Alternative. Wer will schon in der Bude neben Snowden wohnen.
Im offenen Markt von Ideen hat einer eine halbgare Idee. Macht ein Paper
draus, aber die passende Konferenz lehnt es ab. Also platziert er es im
Web. Jemand anders irgendwo auf der Welt sieht das vielleicht, greift
sie auf und findet das fehlende Glied, postet selber. Schwupps werden 10
weitere hellhörig und merken was da abgeht.
A. K. schrieb:> Wobei ich zwischen Meltdown und Spectre etwas unterscheiden würde.
Ja, definitiv. Obwohl beide aus taktischen Gründen gleichzeitig
veröffentlicht wurden, handelt es sich schon um unterschiedliche
Angriffe.
> Bei Meltdown kann man drüber streiten, ob ein spekulativ ausgeführter> Load im unzulässigen Fall wirklich die realen Daten liefern sollte.
Nach "altem Stand der Technik"(tm) war dies völlig akzeptabel, solange
sichergestellt wurde, dass diese Daten verworfen werden. Folglich
genügte es, bei der Architektur, dem Entwurf, der Implementierung und
den Tests solcher Prozessoren ausschließlich alle Ausführungspfade zu
analysieren, in denen eine Verwertung der spekulativ berechneten Daten
erfolgt.
> Das muss nicht sein, wie man an AMD sieht. Auch wenn nicht nur Intel> betroffen ist, sondern auch diverse ARMs, sehe ich das schon als Bug.
Ich sehe das ganze etwas formeller, gemäß dem Motto: "Operation
gelungen, Patient tot". Das zeitliche Verhalten der Prozessoren wurde ja
sehr teuer (Entwicklungsaufwand, Chipfläche) erkauft, aber niemand(?)
erkannte, was das alles bedeutete. Vor einigen Jahren befasste ich mich
auch mit möglichen Seitenkanälen durch Caching usw., aber erkannte auch
nicht die nun beschriebenen Angriffsmöglichkeiten.
Auf einer sehr abstrakten Ebene kann man das ganze zwar schon als Bug
bezeichnen, nicht jedoch auf der Implementierungsebene der Prozessoren.
> Bei Spectre hingegen liegt es voll im Prinzip der Arbeitsweise. Weshalb> auch wirklich jeder betroffen ist, es nur vielleicht bei manchen> schwieriger auszunutzen ist.
Ja.
> Wobei noch die eine oder andere Stinkbombe platzen könnte.
Es werden mit Sicherheit auch noch etliche andere
Implementierungsschwächen sehr weit verbreiteter Prozessorfamilien
bekannt werden, aber ob noch weitere derart universelle Schwächen
aufgedeckt werden, wage ich nicht zu beurteilen.
> Denn> ausnutzbare side channels sind schon länger bekannt. Dass es möglich> sein kann, Crytoverfahren über ähnliche side channels abzugreifen ist> schon seit Jahren bekannt und davon hatte ich auch schon mal gehört.
Insbesondere kommt es durchaus auch vor, dass das Stopfen eines
Seitenkanals plötzlich einen neuen überhaupt erst schafft. Es gibt
einige Computer, bei denen man mit großem Aufwand die elektromagnetische
Abstrahlung miniert hat. Allerdings wurde nicht bedacht, dass die vielen
verwendeten Drosseln und Keramikkondensatoren tolle magnetostriktive und
Piezolautsprecher darstellten. Bei früheren Versionen von GPG konnte man
daher die Entschlüsselungsvorgänge akustisch belauschen und mit
statistischen Verfahren sogar große Teile der geheimen Schlüssel
extrahieren.
Carl D. schrieb:> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben> manchmal darauf verzichten.
Das war bei bisherigen Prozessoren eben kein Entwurfsziel, was sich aber
nun ändern wird. Sobald aber irgendein Fachmagazin dann aber
herausfindet, dass der neue Prozessor in irgendeinem synthetischen
Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es
ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder
vergessen.
A. K. schrieb:> Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so> ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf> spekulative Ausführung umschwenkten. Das ist aber eine Plattform, bei> der neben Verfügbarkeit bestimmt auch Sicherheit ein wichtiges Thema> ist.
Ich kann mir sehr gut vorstellen, dass man bei diesen Prozessoren sogar
die spekulative Ausführung deaktivieren kann. Womöglich wurde so etwas
schon implementiert, weil man ahnte, dass es irgendwann Probleme durch
Seitenkanalangriffe geben kann, ohne sie genau benennen zu können.
> Zwar sind die nicht erste Adresse bei der Ausnutzbarkeit, weil da> seltener Fremdcode ohne weiteres draufhuschen dürfte, als es bei Clouds> oder Clients der Fall ist. Aber dafür sind die Kunden empfindlicher.
Bei der Sicherheitsanalyse solcher Systeme geht man davon aus, dass
jeder Benutzer und jedes Programm für Angriffe genutzt wird und damit
versucht, Zugriff auf höher eingestufte Daten zu erhalten. Eines der
hierfür relevanten Stichwörter ist MLS (Multilevel security):
https://en.wikipedia.org/wiki/Multilevel_security
Systeme auf Basis der zSeries werden auch in solchen Umgebungen
eingesetzt, siehe:
ftp://public.dhe.ibm.com/s390/zos/racf/pdf/r04_mls_introduction.pdf
ftp://ftp.software.ibm.com/s390/zos/racf/pdf/r04_mls_update.pdf
Andreas S. schrieb:> Ich kann mir sehr gut vorstellen, dass man bei diesen Prozessoren sogar> die spekulative Ausführung deaktivieren kann.
Dafür reicht meine Phantasie nicht. Man kann sicherlich zig Dinge
abschalten, wie etwa bestimmte Sprungvorhersageverfahren. Aber einen OOO
Prozessor spekulationsfrei zu kriegen? Das bricht seine gesamte
Arbeitsweise.
Technisch mag das zwar möglich sein, wenn man es entsprechend eingeplant
hat. Der Einbruch wäre aber m.E. dramatisch. Auf 3-4 Befehle kommt ein
Sprung und der blockiert alles bis er retired ist. Das endet wesentlich
schlechter als feste Pipelines in einem nichtspekulativen Design.
Jedenfalls wäre IBM dann mächtig im Zugzwang. Mit "kauft einen neuen
teureren Recher, sobald wie einen haben, bis dahin bricht euch eben ab
zu der Laden zusammen" macht man sich keine Freunde. Klar, wer noch
nicht am Limit ist kriegt Prozessoren umsonst/verbilligt freigeschaltet.
Aber wer es schon ist?
Wer beim Bau ernsthaft ist Erwägung zieht, die OOO Arbeitsweise im
produktiven Umfeld abschalten zu müssen, der baut sie nicht erst ein.
Aber ich lasse mich da gerne überraschen. IBM fällt Jahr für Jahr
hauptsächlich damit auf, was sie alles nicht mehr machen. ;-)
Andreas S. schrieb:> Carl D. schrieb:>> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die>> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,>> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms>> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben>> manchmal darauf verzichten.>> Das war bei bisherigen Prozessoren eben kein Entwurfsziel, was sich aber> nun ändern wird. Sobald aber irgendein Fachmagazin dann aber> herausfindet, dass der neue Prozessor in irgendeinem synthetischen> Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es> ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder> vergessen.
Naja, die Performance-Counter abzuschalten sollte kein
Performance-Promille ausmachen. Wie gesagt, schön für den Programmierer,
der sein Programm fein-tunen will, aber für bunte Graphiken mit
Cloud-Performancedaten muß man nicht mit Nanosekunden Auflösung zählen.
Zur z-Serie:
Die hat den großen Vorteil, daß sie tauschbare Prozessorboards hat und
nicht in Millionenstückzahlen in irgendwelchen Notebooks verlötet ist.
Peter D. schrieb:> Also alles nur heiße Luft. Schade um die mit Lesen vergeudete Zeit.
Aus heutiger Sicht wohl schade um die vergeudete Zeit, diesen Beitrag zu
schreiben
> Beim branch target cache konnte es vorkommen, dass bei> erkanntem self modifying code Befehle doppelt ausgeführt wurden.
Wenn es um sowas geht, so einen "Fehler" hatte auch der 486er schon.
Wenn man einen Befehl im Speicher unmittelbar vor dessen Ausführung
modifiziert hat, blieb diese Modifikation wirkungslos, da der Befehl
bereits in den Dekoder geladen war und nicht neu aus dem Speicher geholt
wurde.
Ben B. schrieb:>> Beim branch target cache konnte es vorkommen, dass bei>> erkanntem self modifying code Befehle doppelt ausgeführt wurden.> Wenn es um sowas geht, so einen "Fehler" hatte auch der 486er schon.> Wenn man einen Befehl im Speicher unmittelbar vor dessen Ausführung> modifiziert hat, blieb diese Modifikation wirkungslos, da der Befehl> bereits in den Dekoder geladen war und nicht neu aus dem Speicher geholt> wurde.
Der BTIC war kein Teil eines Prefetchers, sondern ein spezieller I-Cache
für Sprungziele. Griff also dann, wenn man das tut, was man bei self
modifying code nach dem Speichern seit 8086 korrekterweise immer tun
sollte: springen. Denn solch ein Sprung vermeidet die von dir
beschriebenen Schmutzeffekte.
Der Bug führte dazu, dass nicht etwa der falsche Befehl ausgeführt
wurde, oder der alte, sondern 1-2 Befehle zweimal ausgeführt wurden.
Dieser Bug trat auch dann auf, wenn überhaupt kein self modifying code
vorlag. Der BTIC enthielt Befehlscode, musste also Schreiboperationen
scannen. Und dafür hat er nur einen Teil der Adressbits genutzt. Das
führte zu einer vorsätzlich in Kauf genommenen Fehlerkennung, die aber -
weil sehr selten - normalerweise nur die Laufzeit eines Programms
unmerklich beeinflusst hätte.
Der GCC enthält natürlich keinen self modifying code. Auf die Nase flog
er trotzdem. Am GCC lag es nicht, es lag am Prozessor. Das stand auch
schon vorher in den Erratas, allerdings ohne Hinweis auf die
unvollständige Erkennung. Kurz drauf stand auch die u.A. Note drin.
"Re-execution of Instructions Due to Self-Modifying Code
...
then: the long-decoded instruction, or the short-decoded instruction(s),
is executed twice.
Note: A potential self-modifying code condition means that the processor
detects all actual self-modifying code sequences, as well as some
sequences in which the processor "believes" that a self-modifying code
situation is occurring, but in reality is not (referred to as "false"
self-modifying code detection). The false detection occurs because the
processor does not check all 32 address bits when checking for
self-modifying code."
Billiger Kommentator schrieb:> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch> für fragwürdig.
Man erinnere sich an den NSAKey in Windows, der natürlich im Nachhinein
nur zufällig so hieß und rein gar nix mit der NSA zu tun hat… Ehrenwort!
> Fakt ist, es ist ein Stück Hardware, welche man nicht eben ändern kann.
Das ist doch gerade das Schöne aus Sicht von Geheimdiensten. Die Lücke
lässt sich nicht einfach mit einem Patch schließen. Deshalb kann man
Hardware-Verschlüsselung eigentlich auch nicht trauen.
> Eine Softwarelücke ist schnell gepatcht bzw. verschwunden und> hinterlässt dabei kaum Spuren. Die werden solch ein Risiko sicher nicht> eingehen. Von daher glaube ich Ausnahmsweise auch, was die NSA sagt :)
Und warum sollte das ein Vorteil für die NSA sein, wenn es besonders
leicht ist, ihnen ihren Zugang wieder zu schließen?
> Trotzdem kann man sich nicht sicher sein. Vielleicht hat Intel auch eine> entsprechend große Hand aufgehalten, für den Fall des Falles. Wer weiß.> Aber Spekulationen haben noch nie viel gebracht...
Seit Snowden sollte aber klar sein, dass da nicht weniger, sondern eher
deutlich mehr passiert, als man als nicht-Aluhutträger eigentlich
vermuten würde. Deshalb traue ich den USA in der Hinsicht alles zu und
halte jegliche in den USA entwickelte closed-source Computer-Hard- und
Software nicht für zweifelsfrei vertrauenswürdig.
Rolf M. schrieb:> und> halte jegliche in den USA entwickelte closed-source Computer-Hard- und> Software nicht für zweifelsfrei vertrauenswürdig.
Nach meiner bescheidenen Meinung lässt sich das beliebig ausdehnen.
Schon rein wirtschaftliche Interessen berechtigen zu dieser Annahme. Mit
der Auswahl des Produktes fällst du nur die Entscheidung in welcher
Krake Hände du dich begibst, nicht ob.
Herr schütze mich vor meinen Freunden, meiner Feinde will ich gewahr
sein.
Namaste
Das impliziert doch, dass der NSA die Möglichkeit zur Schnüffelei so
viel Wert sei, dass sie bereit sei, auch jedem potentiellen Gegner
freien Einblick in amerikanische Inhalte zu gewähren, ohne irgend etwas
dagegen tun zu können?
Wäre das nicht Hochverrat?
A. K. schrieb:> Das impliziert doch, dass der NSA die Möglichkeit zur Schnüffelei so> viel Wert sei, dass sie bereit sei, auch jedem potentiellen Gegner> freien Einblick in amerikanische Inhalte zu gewähren, ohne irgend etwas> dagegen tun zu können?>> Wäre das nicht Hochverrat?
Nein, die haben doch spezielle Prozessoren in Amerika. Die haben
Prozessoren ohne Sicherheitslücke extra in der Area51 produzieren
lassen, umgelabelt, heimlich ausgetauscht und dann nur in Amerika in den
Verkauf gebracht...
Ironie und Verschwörungstheorie aus
Daher sage ich bei deinem Beitrag nur: DITO!
WENN die Staatsorgane der USA wirklich die gleichen Intel Prozessoren
mit den Sicherheitslücken haben, sollte klar sein, dass die da nicht mit
drin stecken. Haben die andere Prozessoren, dann könnte man durchaus
hellhörig werden.
Billiger Kommentar schrieb:> Die haben Prozessoren ohne Sicherheitslücke extra in der Area51> produzieren lassen
So ist offensichtlich der 8051 entstanden. Und der ist ja tatsächlich
nicht betroffen, obwohl er von Intel ist.
Aber ob er noch den heutigen Ansprüchen genügt?
Ja für so opportunistisch muss man solche Org's halten.
Schon vergessen? Wer mit dem Teufel speist braucht einen langen Löffel.
Die Hybris des absoluten Wissens über die absolute Wahrheit zu
verfügen,und auf der Seite des Guten zu kämpfen und gegen das Böse, ist
essentieller Teil eines solchen Weltbildes. Das ist in allen
Staatsformen gleich weil zu tiefst menschlich. Es erleichtert das eigene
Handel als gerechtfertigt anzusehen auch in fragwürdiger Situation.
Ehrgeiz schützt vor Dummheit nicht.
Beitrag "Re: Schwere Sicherheitslücke in Intelprozessoren?"
Namaste
A. K. schrieb:> Wäre das nicht Hochverrat?
Nach Ockham genügt auch Mangel an Phantasie egal wie ausgeprägt und
bezogen auf welche Abstraktionsstufe.
Namaste
Winfried J. schrieb:> Schon vergessen? Wer mit dem Teufel speist braucht einen langen Löffel.
In der Betriebskantine der NSA muss es lustig aussehen. ;-)
und nun seid ihr doch alle fleissig am verschwörungstheoretisieren
und polemisieren. Genau das, was man mir vorgeworfen hat.
wer also im Glashaus sitzt, sollte aufpassen wohin man die Steine wirft.
Billiger Kommentar schrieb:> Nein, die haben doch spezielle Prozessoren in Amerika. Die haben> Prozessoren ohne Sicherheitslücke extra in der Area51 produzieren> lassen, umgelabelt, heimlich ausgetauscht und dann nur in Amerika in den> Verkauf gebracht...
und du glaubst wirklich der MIK leistet sich nicht teure Entwicklungen
von Costum Prozessoren? Dann sage dir was. Ander OHS in Stralsund war
ich 1985-86 persönlich am Brainstorming für ein während des Abschusses
programmierbaren Mikrocontrollers auf U8810 Basis zur Einstellung der
Zerlegergrenze von Luftabwehrgeschossen befasst.
Wir hatten Kopien von äquivalenten Erfindungen aus dem Bundesdeutschen
Patentamt, geheim gestempelt im Schnitt 2 Jahre alt. Unser Mc sollte im
HFO als Customchip mit OTP und wenigen Registern gefertigt werden. Haken
war das programmieren im stickstoffgekühlten Patronenlager bei 3000
Schuss pro Minute.
Alles war GVS.
Alle Aufzeichnungen waren nur in einer personengebundenen GVS Kladde zu
führen und wurden bei Verlassen des Gebäudes petchiert in der VS-Stelle
gegen Protokoll hinterlegt. Auch meine persönlichen Aufzeichnungen zum
Thema durfte ich nur dort führen und hinterlegen.
Glaub mir Die USA haben noch ganz andere Projekte.
Und wenn du das nicht glaubst beschäftige dich mit dem Kampf der Briten
gegen die Ubotflotte
Stichworte enigma--> the bomb ---> Ellen Turing--->Eniac
die Akten dazu waren bis vor wenigen Jahren Top Secret.
Namaste
Rolf M. schrieb:> Winfried J. schrieb:>> Costum Prozessoren>> Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching> verkleide.>> SCNR
S'il te plait bell.
Namaste
Rolf M. schrieb:> Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching> verkleide.
Manche könnten versucht sein, dich daran zu erinnern,
dass Halloween im Herbst ist.
Aber vielleicht gibts trotzdem ein paar Bonbons.
Andreas S. schrieb:> Sobald aber irgendein Fachmagazin dann aber> herausfindet, dass der neue Prozessor in irgendeinem synthetischen> Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es> ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder> vergessen.
Berechtigt, berechtigt.
Ich warte ja jetzt schon immer dass dieser lahme Idle-process endlich
mal fertig wird ...
/regards
P.S:
Schöner, hochinformativer Fred :)
Baum schrieb:> Raspberry Pi sind nicht betroffen?> Alle modelle?
Alle. V1: ARM11, V2: Cortex A7, V3: Cortex A53. Alle haben eine in-order
Bauweise, arbeiten also nicht spekulativ.
Gut dran sind deshalb auch Freunde von Handys der Billig- und
gemässigten Mittelklasse. Die sind heute praktisch immer mit Cortex A53
bestückt. Also wer Futter braucht, um einen stolzen iPhone-Besitzer zu
ärgern ...
A. K. schrieb:> Gut dran sind deshalb auch Freunde von Handys der Billig- und> gemässigten Mittelklasse. Die sind heute praktisch immer mit Cortex A53> bestückt. Also wer Futter braucht, um einen stolzen iPhone-Besitzer zu> ärgern ...
Kennst du zufällig ein paar modelle?
Ich habe (nach meinem Beitrag... ) selbst mal die glaskugel angeworfen.
Clevere idee einen (ein Zyklus, ein Befehl) prozessor so zu nutzen.
Ich gebe zu, ich hab es erst halbwegs begriffen als ich diesen link
gefunden habe.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
In allen fällen wird die ausgabe der 'pages' verhindert da die operation
so oder so ungültig ist... (?!) Also ich hoffe ich hab es grob
verstanden.
A. K. schrieb:> Ist nicht vollständig, weil einem Qualcomm die Arbeit erschwert.
Ja die Snapdragon sollen auch betroffen sein.
Vielen dank für die Links.
O.T
Mir kam gerade eine saublöde idee.
Aber ich versuch mal mein glück damit. ;)
Baum schrieb:>> Ist nicht vollständig, weil einem Qualcomm die Arbeit erschwert.>> Ja die Snapdragon sollen auch betroffen sein.
Qualcomm nennt alles Snapdragon, egal was drinsteckt. Das können auch
A53er sein, oder leicht veränderte Varianten davon. Bei den 8xx darf man
davon ausgehen, betroffen zu sein, während man bei den 4xx auf der
sicheren Seite sein sollte.
A. K. schrieb:> Baum schrieb:>> Kennst du zufällig ein paar modelle?>> Handys ab 2017 mit A53 drin:> https://www.heise.de/preisvergleich/?cat=umtsover&xf=3229_2017~5827_Cortex-A53>> Davon alle abziehen, die verschiedene Cores enthalten, z.B. 4xA53 und> 4xMongoose wie das S8. Diese anderen Cores sind dann dann spekulativ,> und nur bei ausreichend Last aktiv.
Oder alle mit https://en.wikipedia.org/wiki/MediaTek#Octa-_and_deca-core
außer Helio X. Nur sollte dazugesagt werden das wohl die meisten der
Handys mit so einem SoC nicht von LineageOS unterstützt werden (es gibt
aber einige auf Lineage-basierte Custom-ROMs). Zur Patchversorgung bei
Android: Kein Kommentar, da braucht's weder Meltdown noch Spectre
Arc N. schrieb:> . Zur Patchversorgung bei Android: Kein Kommentar, da braucht's weder> Meltdown noch SpectreSeuftz ... und noch schlimmer ist es wenn die leute tausende von
spielen installieren die zugriff auf alles haben was die kiste hergibt.
A. K. schrieb:> Qualcomm nennt alles Snapdragon, egal was drinsteckt. Das können auch> A53er sein, oder leicht veränderte Varianten davon. Bei den 8xx darf man> davon ausgehen, betroffen zu sein, während man bei den 4xx auf der> sicheren Seite sein sollte.
Ich muss mal schauen was on meinem J5 (Samsung) steckt... ich ahne aber
nichts gutes....
Baum schrieb:> Ich muss mal schauen was on meinem J5 (Samsung) steckt... ich ahne aber> nichts gutes....
Bei der J5-Serie? 2015/16/17 soweit ich sehe alles nur A53. Mehr hätte
mich in dieser Klasse auch gewundert.
Winfried J. schrieb:> Mal sehen was passiert.
Nix. A7 ist sauber. Also was das Thema angeht. Löcher hat das Handy
garantiert trotzdem, aber nicht diese.
A. K. schrieb:>>>> Bei der J5-Serie? 2015/16/17 soweit ich sehe alles nur A53. Mehr hätte> mich in dieser Klasse auch gewundert.
Stimmt. Naja für 200€ ... immerhin ist mein Telefon scheinbar nicht
betroffen.
Ja von 2017. :)
Tjaja die Sicherheitslücken. Da oute ich mich mal als "Schuster mit den
schlechtesten Schuhen" und teile mit das auf meinen Rechnern weder
updates noch Virenscanner aktiv sind.
Lediglich ein NAS internes hidden backup läuft da mit.
Bisher alles super. Das sagt nix aus, weiß ich selber.
Aber hier mal ein Beitrag abseits des hirnverblödenden Medienrummels:
...
Seite 11: "On such systems, an attacker can use Meltdown to dump the
entire physical memory, simply by reading from virtual addresses
starting at 0xffff 8800 0000 0000."
Alle existierenden PoCs, sowie meine Tests und auch Google kommen
allerdings zu einem anderen Ergebnis:
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.htmlhttp://blog.fefe.de/?ts=a4ad9f54
Achso, vielleicht trenne ich mal wieder internes Netz und Internet über
einen Rechner ohne Freigaben mit dem ich per mstsc im internet surfe.
Scheint mir sicher genug.
Jörg W. schrieb:> F. F. schrieb:>> Mein Gott, wie borniert du doch bist.>> Ähem, Foldi, das hat sich A.K. bestimmt nicht verdient. Er gehört> zu denen, die hier allemal am ausgewogensten daherkommen.
Nein, im weiteren Verlauf hat er das näher geschildert und deswegen,
mein lieber A.K., nehme ich das "borniert" auch gerne wieder zurück.
Ich hatte ganz vergessen, dass man hier immer sehr genau sein muss und
Mutmaßungen in einem Fachforum nicht unbedingt angebracht sind.
Danke Jörg, für den Hinweis!
Kaj G. schrieb:> Intel-Sicherheitslücke> Wichtiges Update könnte Millionen Computer extrem
Ob ein simples MS/Intel-Update überhaupt WIRKSAM genug ist, wenn das
Übel schon über das BIOS eingeschleppt werden könnte?
oszi40 schrieb:> Ob ein simples MS/Intel-Update überhaupt WIRKSAM genug ist, wenn das> Übel schon über das BIOS eingeschleppt werden könnte?
Meinst du mit "BIOS" Intels ME? Das sind zwei sehr verschiedene
Angriffs-Szenarien.
In ME kommst du über das lokale Netz rein. Sitzt zwischen den Angreifer
und dem Zielsystem eine entsprechend arbeitende Firewall, dann geht
nichts. Das ME Loch kann man stopfen, wenn der Hersteller des
Rechners/Mainboards das bietet.
Meltdown/Spectre setzt voraus, dass auf dem betreffenden Rechner
Schadcode läuft, der diese Lücken ausnutzt. Egal ob der selbst
installiert wurde, über Browser (JS) reinkam oder über Buffer Overflow.
Du kannst natürlich auch resignieren und von nun an konsequent darauf
verzichten, irgendwelche Löcher auch nur versuchen zu stopfen. Weils ja
doch immer wieder neue gibt. Das erspart dir manche Arbeit.
A. K. schrieb:> Meltdown/Spectre setzt voraus, dass auf dem betreffenden Rechner> Schadcode läuft, der diese Lücken ausnutzt. Egal ob der selbst> installiert wurde, über Browser (JS) reinkam oder über Buffer Overflow.
Achtung! Auf dem (virtualisierten) Rechner selbst muss nicht zwingend
der Schadcode laufen, es reicht wenn der auf einer anderen (virtuellen)
Maschine am selben Host läuft! Das ist ein kleiner, aber extrem
signifikanter Unterschied! (Gilt offensichtlich aber nur für Spectre)
Michael R. schrieb:> Achtung! Auf dem (virtualisierten) Rechner selbst muss nicht zwingend> der Schadcode laufen, es reicht wenn der auf einer anderen (virtuellen)> Maschine am selben Host läuft!
Wobei die Ausnutzung von Spectre über VM-Grenzen hinaus ein ziemlich
krasses Szenario ist. Aber ja, das ist richtig. Weshalb auch die
Virtualisierungsumgebung nicht verschont bleibt. Für die Spectre
Mitigations kamen gestern von VMware Patches raus, um die entsprechenden
Patches von Intel und Microsoft wirksam werden zu lassen.
> (Gilt offensichtlich aber nur für Spectre)
Für Meltdown reicht es aus, das Gastbetriebssystem mit KPTI zu fahren.
Ab VMware Gast-Hardware 11 und mindestens Westmere Prozessor gibts dann
auch PCID (process-context identifiers), d.h. die Performance-Einbusse
ist geringer.
A. K. schrieb:> Für die Spectre> Mitigations kamen gestern von VMware Patches raus, um die entsprechenden> Patches von Intel und Microsoft wirksam werden zu lassen.
Wobei:
> VMware vSphere 5.5: apply patch ESXi550-201709101-SG (this patch has> remediation against CVE-2017-5715 but not against CVE-2017-5753)
CVE-2017-5753 ist "Bounds-Check Bypass"
CVE-2017-5715 ist "Branch Target Injection"
A. K. schrieb:> Meinst du mit "BIOS" Intels ME? Das sind zwei sehr verschiedene> Angriffs-Szenarien.
Meine ich nicht. Wenn ich mal von der einfachen Annahme ausgehe, daß im
fest eingebrannten BIOS auf den Board schon spekulative CPU-Befehle
ausgeführt werden könnten, dann ist schon dort ein Loch im Zaun, was
eigentlich nur durch dem Mainboardhersteller gefixt werden könnte (da
ein Betriebssystem erst später läuft).
oszi40 schrieb:> Meine ich nicht. Wenn ich mal von der einfachen Annahme ausgehe, daß im> fest eingebrannten BIOS auf den Board schon spekulative CPU-Befehle> ausgeführt werden könnten, dann ist schon dort ein Loch im Zaun,
Nein. Die Prozessoren rechnen im Sinn der x86 Instruction Set
Architecture mit und ohne spekulativer OOO-Architektur exakt richtig.
Die Szenarien dieses Threads sind auf das BIOS nicht anwendbar.
Die Aufgabe des Bios im PC kann höchstens darin bestehen, aktuelle
Microcodeupdates in die CPU zu laden. Dazu muss man mal schauen, ob sich
bei den BIOS Updates für den eigenen Rechner was tut.
Matthias S. schrieb:> Die Aufgabe des Bios im PC kann höchstens darin bestehen, aktuelle> Microcodeupdates in die CPU zu laden. Dazu muss man mal schauen, ob sich> bei den BIOS Updates für den eigenen Rechner was tut.
Wobei mindestens Linux in der Lage ist, CPU-Microcode beim Start auch
selbst zu aktualisieren. Inwieweit das hier genutzt werden kann bleibt
abzuwarten.
die ganze Geschichte könnte eine schöne Neuaufbereitung der damaligen
Lisp-Maschinen sein
http://www.cse.unsw.edu.au/~chak/papers/PLKC08.html bzw.
http://www.cse.unsw.edu.au/~chak/papers/fsttcs2008.pdfhttps://de.wikipedia.org/wiki/Lisp-Maschine
"könnte" weil der ghc ja hauptsächlich mit C Grundlage daherkommt, der
gelinkte Artikel sich nicht wirklich mit Strategien rund um - und mit
Interlocks auf Hardwareebene beschäftigt, und der ghc selbst zumindest
zuletzt recht häufig abstruse fehlerhafte Ausgaben (Windows)
produzierte.
Als Programmierer kann man notfalls immer noch an einer der wenigen
Faustregeln halten, die da empfiehlt: nicht soviel bzw. ganz oft/viel
springen.
Da auch Artikel im Spiegel und in der NYT auftauchen fühlt man sich an
typische Agenda 10 Projekte mit Bürgermeisterfotos und Zeitungsartikeln
erinnert, die zwar nett in der Überschrift und schön nachzulesen sind,
aber schnell vergessen werden und die Projekte verstauben oder
verfallen.
(u.a. auch weil POC sch.. ist und (Dos-) .com Dateien angeblich nur 64k
groß sein dürfen (war wohl der RealMode für viele schon zu hoch?)).
Wie darf man sich die so schnellen Patches auf Softwareebene vorstellen,
wo doch das Hauptproblem recht tief in Hardware (+ Paralleltheorie usw.)
(ver-)steckt?
A. K. schrieb:> Wobei mindestens Linux in der Lage ist, CPU-Microcode beim Start auch> selbst zu aktualisieren. Inwieweit das hier genutzt werden kann bleibt> abzuwarten.
Einige Distributionen haben jetzt schon Kernel-Patches und installieren
auch gleich Microcode-Updates :)
Mampf F. schrieb:> und installieren> auch gleich Microcode-Updates :)
Den link auf die aktuellen Microcodes für Intel hatte ich oben ja mal
gepostet. Der kleine Server hier mit jessie und Atom 220 hat sie
jedenfalls erstmal geschluckt. Bei jessie selber hatte sich gestern auch
was getan.
Matthias S. schrieb:> Der kleine Server hier mit jessie und Atom 220 hat sie> jedenfalls erstmal geschluckt.
Einen Atom 220 gibts bei Intel m.W. nicht. Und ein Atom 230 braucht
keinen Fix, weil von den Problemen nicht betroffen. Alle Atoms vor dem
Silvermont Core arbeiten nicht-spekulativ.
A. K. schrieb:> Einen Atom 220 gibts bei Intel m.W. nicht.
Das Dings hier heisst wohl Celeron 220. Ich wollte da auch keinen Fix
reinpatchen, sondern den normalerweise brachliegenden Mechanismus für
Microcode ausprobieren. Das scheint zu klappen, aber man sollte es z.B.
in rc.local zünden.
A. K. schrieb:> F. F. schrieb:>> Ich habe das nur im Radio gehört und das sagten sie, dass Intel schon>> neue Prozessoren hätte, die diese Sichereitslücke nicht hätten. Deshalb>> schrieb ich das überhaupt.>> Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Hast recht, eher nicht.
Von Spectre habe ich auch eher zufällig und erst vor kurzem gelesen.
Die letzte Zeit war ich selten hier und habe auch nur notwendige
Reparaturen gemacht und ansonsten habe ich mich in meinem Kummer und in
Trauer ertränkt.
rbx schrieb:> Wie darf man sich die so schnellen Patches auf Softwareebene vorstellen,> wo doch das Hauptproblem recht tief in Hardware (+ Paralleltheorie usw.)> (ver-)steckt?
Das Thema war über Monate unter Verschluss. Ganz so schnell ging das
also nicht, Intel hatte schon etwas Zeit.
An der grundlegenden Arbeitsweise kann nicht viel gedreht werden. Aber
erstens kann man versuchen, die konkreten Angriffe zu erschweren.
Zweitens gibt es mindestens bei Intel im Rahmen der Microcode Patches
neue Prozessorbefehle (und ein neues CPUID Bit), die dabei helfen
können, Programme gegen Spectre sicherer zu machen. Hab grad keine
Details.
So kann man neue Befehle einführen, oder bestehende ohnehin schon per
Microcode implementierte Befehle so erweitern, dass sie für Spekulation
an kritischer Stelle eine Barriere bilden. Das hilft bestehenden
Programmen nicht, lässt sich aber einbauen. Man könnte auch dafür
sorgen, dass zumindest in Kontextwechseln die Sprungvorhersage etwas auf
die Mütze kriegt, um Spectre über Threadgrenzen zu erschweren. Evtl.
lässt sich das auch in Browsern nutzen um getrennten Code auch wirklich
zu trennen. Bremst natürlich.
Programmiertechnisch kann man auch ohne Microcode Patches dagegen
angehen, indem man beispielsweise Bereichsüberprüfungen nicht per Sprung
erledig. Wenn man Bereiche per
if (index >= min && index <= max)
... = array[index];
else
panic();
absichert und das mit bedingten Sprüngen abwickelt, ist man der
Spekulation ausgeliefert. Ersetzt man das durch Code, der nicht springt,
sondern Daten abhängig von der Bereichsüberprüfung durchreicht, wie etwa
temp = (index >= min && index <= max) ? index : 0;
... = array[temp];
und dieser ?: Datenmultiplexer arbeitet rein über ALU-Operationen, dann
ist man sicher. Auch das ist natürlich etwas Arbeit.
Kaj G. schrieb:> Oder man laesst es einfach den Bootloader machen:> https://wiki.archlinux.org/index.php/Microcode#Installation
Ehrlich gesagt, klingt das viel komplizierter als die andere Methode,
die ich nach Intels Anleitung implementiert habe und für die Debian die
richtigen Mechanismen schon hat. Also Microcode Verzeichnis in
/lib/firmware kopieren und dann in der rc.local
'echo 1 > /sys/devices/system/cpu/microcode/reload'
Fertig.
Matthias S. schrieb:> Kaj G. schrieb:>> Oder man laesst es einfach den Bootloader machen:>> https://wiki.archlinux.org/index.php/Microcode#Installation>> Ehrlich gesagt, klingt das viel komplizierter als die andere Methode,> die ich nach Intels Anleitung implementiert habe und für die Debian die> richtigen Mechanismen schon hat. Also Microcode Verzeichnis in> /lib/firmware kopieren und dann in der rc.local> 'echo 1 > /sys/devices/system/cpu/microcode/reload'>> Fertig.
Ist der Microcode eigentlich persistent? Haben die ein Flash eingebaut?
Ist in den CPUs noch ein Controller eingebaut, der das Flash
aktualisiert? :)
Mampf F. schrieb:> Ist der Microcode eigentlich persistent?
Ich gehe davon aus, dass der gesamte für den Befehlssatz benötigte Teil
des Microcodes auf der CPU hart verdrahtet ist und lediglich
Microcode-Modifikationen nachträglich in ein spezielles RAM in der CPU
geladen werden können. Das System startet also mit dem
Standard-Microcode und kann Modifikationen selbst nachladen.
A. K. schrieb:> Ich gehe davon aus, dass der gesamte für den Befehlssatz benötigte Teil> des Microcodes auf der CPU hart verdrahtet ist und lediglich> Microcode-Modifikationen nachträglich
Hmm schaut nicht so aus ... Hab gelesen, mit dem Microcode-Update für
Intel-CPUs würden auch noch 3 weitere neue Befehle dazu kommen.
Mampf F. schrieb:> Hmm schaut nicht so aus ... Hab gelesen, mit dem Microcode-Update für> Intel-CPUs würden auch noch 3 weitere neue Befehle dazu kommen.
Das ist kein Widerspruch.
Mampf F. schrieb:> Ist der Microcode eigentlich persistent?
Das Update ist es bei mir nicht. Auf meinem Desktop (AMD FX-8350) faellt
mir das aber nicht auf, weil:
1
For AMD processors the microcode updates are available in linux-firmware,
2
which is installed as part of the base system. No further action is needed.
[ 6.085810] microcode: CPU0: new patch_level=0x0600084f
12
[ 6.096507] microcode: CPU2: new patch_level=0x0600084f
13
[ 6.112628] microcode: CPU4: new patch_level=0x0600084f
14
[ 6.128558] microcode: CPU6: new patch_level=0x0600084f
sieht man, dass der Patch erst geladen wird. Der eigentliche Microcode
ist aber persistent.
Ich habe mein Notebook (Intel i7-irgendwas) vor ein paar Wochen neu
aufgesetzt, da musste ich das Microcodeupdate erst neu einrichten. Auch
dort ist das Update also nicht persistent.
Ist ja aber in 15 Sekunden fertig, also kein wirklicher aufwand.
https://wiki.archlinux.org/index.php/Microcode#Verifying_that_microcode_got_updated_on_bootMampf F. schrieb:> Haben die ein Flash eingebaut?
Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS
(Minix/Linux) fuer die Intel ME liegen ;)
Ja, das liegt in der CPU.
Matthias S. schrieb:> Kaj G. schrieb:>> Oder man laesst es einfach den Bootloader machen:>> https://wiki.archlinux.org/index.php/Microcode#Installation>> Ehrlich gesagt, klingt das viel komplizierter als die andere Methode
Versteh ich nicht... Unter Arch muss ich lediglich
1
...installing the intel-ucode package...
also einmalig ein
1
pacman -S intel-ucode
machen und dann ein
1
grub-mkconfig -o /boot/grub/grub.cfg
ausfuehren. Fertig. Keine Ahnung was daran jetzt soooo kompliziert sein
soll. :-|
Und das betrifft auch nur Intel CPUs. Und abgesehen von diesem
einmaligen Schritt muss ich da nie wieder was machen. Microcodeupdates
kommen ab da ganz normal mit dem Systemupdate (mach ich jeden Tag) mit.
Wenn ich da also nicht aktiv drauf achte bekomme ich nicht mal mit, das
es ein Microcodeupdate gibt. Wird eingespielt und fertig. Will man kein
automatisches Update des Microcodes kann man das Paket einfach in die
pacman.conf eintragen. Dann wird das Paket vom Update ausgenommen und es
gibt eine Warnung, das es eine neue Version des Pakets gibt, dieses aber
nicht automatisch installiert wird.
Matthias S. schrieb:> Also Microcode Verzeichnis in /lib/firmware kopieren
Das entfaellt bei mir ja schon.
Matthias S. schrieb:> und dann in der rc.local> 'echo 1 > /sys/devices/system/cpu/microcode/reload'
Da fuehre ich lieber ein einziges mal grub-mkconfig aus.
Fuer mich klingt ja das eintragen in ein Scripte viel komplizierter und
vorallem fehleranfaelliger. :)
Ausserdem kommt das Script erst nach dem Bootloader. Ich befuerworte bei
dieser Sache dann doch eher das frueh moeglichste laden des Updates.
Und ich vertraue an der Stelle auch eher den Anleitungen meiner Distri,
als irgendwelchen Herstellern die, pauschal gesagt, womoeglich noch
nichtmal die Mechanismen meiner Distri ausreichend kennen.
Aber das ist am Ende ja geschmackssache, wie so vieles bei Linux :)
Lasst uns jetzt nicht streiten, was jetzt wirklich 'besser' oder
'schlechter' ist.
Kaj G. schrieb:> Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS> (Minix/Linux) fuer die Intel ME liegen ;)
Code und Daten der ME liegen nicht in der CPU. Der Code liegt im
gleichen ROM wie das BIOS und die Daten liegen in einem reservierten und
für die x86 CPU geblockten Bereich vom DRAM.
Ursprünglich lag auch die ME-CPU extern, im Grafik/Memory-Hub. Nur ist
der mittlerweile Teil des Prozessorchips, also wohl auch die ME-CPU.
https://de.slideshare.net/codeblue_jp/igor-skochinsky-enpub
A. K. schrieb:> Kaj G. schrieb:>> Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS>> (Minix/Linux) fuer die Intel ME liegen ;)>> Code und Daten der ME liegen nicht in der CPU. Der Code liegt im> gleichen ROM wie das BIOS und die Daten liegen in einem reservierten und> für die x86 CPU geblockten Bereich vom DRAM.
Ja, da hab ich mist geschrieben. Asche auf mein Haupt :(
Hier stehts ja auch:
https://www.heise.de/newsticker/meldung/Hacker-dringt-weiter-in-Intels-Management-Engine-vor-3884928.html
1
Er kündigte auf dem Open Source Summit beziehungsweise der
2
Linuxcon 2017 eine Non-Extensible Reduced Firmware (NERF)
3
als Kontrast zum Unified Extensible Firmware Interface (UEFI) an.
4
5
NERF ersetzt das komplette UEFI-BIOS inklusive der meisten
Kaj G. schrieb:> Ausserdem kommt das Script erst nach dem Bootloader. Ich befuerworte bei> dieser Sache dann doch eher das frueh moeglichste laden des Updates.
In dem Fall wäre der Weg über ein BIOS-Update der richtige. Dann ist da
alles schon erledigt, bevor grub oder sonstwas des OS überhaupt loslegt.
Oliver
A. K. schrieb:> erstens kann man versuchen, die konkreten Angriffe zu erschweren.> Zweitens gibt es mindestens bei Intel im Rahmen der Microcode Patches> neue Prozessorbefehle (und ein neues CPUID Bit), die dabei helfen> können, Programme gegen Spectre sicherer zu machen. Hab grad keine> Details.https://www.amd.com/en/corporate/speculative-execution
Google Project Zero (GPZ)
Variant "One Bounds Check Bypass":
Resolved by software / OS updates to be made available by system vendors
and manufacturers. Negligible performance impact expected.
Variant "Branch Target Injection":
Differences in AMD architecture mean there is a near zero risk of
exploitation of this variant. Vulnerability to Variant 2 has not been
demonstrated on AMD processors to date
Variant Three "Rogue Data Cache Load":
Zero AMD vulnerability due to AMD architecture differences.
As always, AMD strongly encourages its customers to consistently
undertake safe computing practices, examples of which include: not
clicking on unrecognized hyperlinks, following strong password
protocols, using secure networks, and accepting regular software
updates.
Kaj G. schrieb:> NERF ersetzt das komplette UEFI-BIOS inklusive der meisten> ME-Funktionen durch einen Linux-Kernel.
Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?
Oliver S. schrieb:> In dem Fall wäre der Weg über ein BIOS-Update der richtige.
Klar. Nur muss man erst einmal ein entsprechendes BIOS für ein nicht
mehr frisches Board kriegen.
A. K. schrieb:> Alles Humbug schrieb:>> https://www.amd.com/en/corporate/speculative-execution>> Es geht momentan wohl eher um das, was Intel tut. Wenn AMD nicht> betroffen ist, müssen sie auch nichts tun. Intel ist aber betroffen und> da wird etwas getan.
Ich weiß. Ich wollte ja nur mal dezent und in voller Hochachtung vor dem
Marktführer INTEL aufzeigen wie es aktuell um die AMD Prozzen steht bzw.
was AMD dazu so vermeldet.
Man könnte dazu natürlich auch einen neuen Thread aufmachen, aber wozu
eigentlich?
In deutsch steht's auch hier nochmals:
http://www.planet3dnow.de/cms/36069-amd-stellt-klar-ms-patch-nur-gegen-spectre-auf-amd-hardware/
Aber die Dinge können sich natürlich auch jederzeit ändern ..
A. K. schrieb:> Kaj G. schrieb:>> NERF ersetzt das komplette UEFI-BIOS inklusive der meisten>> ME-Funktionen durch einen Linux-Kernel.>> Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?
So liest sich das fuer mich. In dem PDF gibt es mehr Informationen dazu,
wobei ich jetzt beim Ueberfliegen nicht gesehen habe, wo der Code
letztlich liegt. Interessant finde ich aber:
Kaj G. schrieb:>> Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?> So liest sich das fuer mich.
Erinnert mich an Skylla vs Charybdis. Linux wird zwar sicherer sein als
Minix, aber auch Linux erwischt es immer wieder mal. Irgendwie finde ich
es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen
muss. Die Hersteller vom BIOS finden das vermutlich auch.
A. K. schrieb:> Irgendwie finde ich> es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen> muss. Die Hersteller vom BIOS finden das vermutlich auch.
Der Update-Spaß funktioniert nur WENN dafür noch ausreichend Speicher
verfügbar ist. Außerdem wäre noch zu untersuchen, wieviel faule Eier im
CMOS/EEPROMs versteckt sind. Mancher Virus/Kopierschutz hat das schon
ausgenutzt.
Kaj G. schrieb:> A. K. schrieb:>> Winfried, das ist was für dich. ;-)> Er koennte auch AMD nehmen>> AMD Secure Processor PSP wohl bei einigen Ryzen-Mainboards abschaltbar
Mal vorab als Info auch für Leute die sich nicht jeden Tag mit Innereien
auf dem Mainboard befassen:
Zitat sinngemäß:
"Intels Pendant zu AMDs Platform Security Processor PSP ist die Intel
Management Engine (IME) oder kurz ME, welche sich in den letzten Tagen
als Sicherheitslücke herausstellte."
http://www.pcgameshardware.de/AMD-Zen-Codename-261795/News/AMD-Platform-Security-Processor-per-BIOS-Update-deaktivierbar-1245467/
War es nicht so als dieses undurchsichtige Chip HW-BIOS-Addon mal
andedacht wurde, dass nach Abschaltung dessen geradezu geschrien wurde,
weil man dadurch zuviel Kontrolle von außen befürchtete? Und nun, da
der Kram sich auch per BIOS Schalter deaktivieren lässt, wird wieder das
schlimmste befürchtet?
https://www.heise.de/security/meldung/Intel-Management-Engine-ME-weitgehend-abschaltbar-3814631.html
Zitat:
"Russische Sicherheitsexperten haben große Teile des Codes von Intels
Management Engine ME 11 entschlüsselt und eine Möglichkeit gefunden,
wesentliche Teile abzuschalten.
Kurioserweise ermöglicht eine Funktion, die Intel eigens für den
US-Geheimdienst NSA in die ME-Firmware eingebaut hat, nun die
Abschaltung dieser viel kritisierten Management Engine (ME). Denn die
NSA selbst wünschte sich Intel-Computer ohne riskante Firmware, die
Hintertüren aufreißen könnte – etwa durch Sicherheitslücken."
Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS
Abschaltmöglichkeit oder eine ohne?
Alles Humbug schrieb:> Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS> Abschaltmöglichkeit oder eine ohne?
Die NSA will natürlich eine mit Abschaltmöglichkeit, nur sollte das
nicht jeder wissen. Damit man es zumindest in kritischen Rechnern
abschalten kann. Oder wenn es die "bösen Russen" irgendwann auszunutzen
wissen.
A. K. schrieb:> Erinnert mich an Skylla vs Charybdis. Linux wird zwar sicherer sein als> Minix, aber auch Linux erwischt es immer wieder mal.
Klar. Ich denke, das wird auch keiner abstreiten. Nicht mal Google. Das
trifft aber auf alle Betriebssysteme zu. Und da bin ich dann doch
"froh", wenn es ein Linux ist, das besser durchleuchtet ist, als
irgendein anderes OS, wie z.B. das Dingens das Samsung auf seinen
Geraeten einsetzt (Tizen), oder irgendwas anderes, das von den
Herstellern unter verschluss gehalten wird und man Luecken nur
aufwaendig per reverseengineering finden kann.
https://www.hackread.com/samsung-tizen-os-contains-tons-of-critical-security-flaws/
1
“Everything you can do wrong there, they do it. You can see that nobody
2
with any understanding of security looked at this code or wrote it. It’s
3
like taking an undergraduate and letting him program your software.”
Natuerlich, auch Linux ist voll mit Luecken. Aber an der Stelle haben
wir leider nur noch die Wahl zwischen Pest, Cholera und einem Pickel am
Hintern. Und da sehe ich Linux mehr als den Pickel am Hintern. Ist nicht
schoen, ist aber immernoch das kleinere Uebel.
Man kann von Google halten was man will, und auch ich bin kein Freund
von dieser Datenkrake. Trotzdem bin ich froh, das Google NERF ins leben
ruft. Denn so hat es erheblich hoeres Potenzial, als wenn es irgend
jemand in seiner Freizeit macht. Google hat einfach das Geld, das
Personal, das Know-How und auch ein eigenes, berechtigtes, interesse
diesen Rotz von Intel ME loszuwerden.
Mal abwarten was da noch kommt. :)
A. K. schrieb:> Irgendwie finde ich> es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen> muss.
Ich sehe das tatsaechlich nicht sooo kritisch. Denn im Gegensatz zu
einem PC wird im BIOS ja nichts nachinstalliert -> Das System aendert
sich nicht. Man nimmt also einen Kernel X zum Zeitpunkt T und braucht
"nur noch" diesen pflegen. Man muss sich nicht um Luecken in Programmen
kuemmern. Die Anzahl an Luecken ist also (mehr oder minder) fest auf die
vorhandenen Luecken zum Zeitpunkt T beschraenkt. Es kommen keine Luecke
durch andere Programme hinzu. Natuerlich, wird eine Luecke gefunden und
gefixt, koennen sich dadurch, moeglicherweise, neue Luecken ergeben. Die
Anzahl der Luecken ist damit also relativ "ueberschaubar".
Nicht falsch verstehen:
Ich will hier nichts klein reden. Aber ich denke, dass es nicht wirklich
schlimmer wird, als es eh schon ist.
Alles Humbug schrieb:> Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS> Abschaltmöglichkeit oder eine ohne?
Ich formuliere das mal so:
"Wir wollen eine Schnittstelle, mit der wir alles und jeden
ausschnueffeln koennen. Diese Schnittstelle muss aber bei unserer
Hardware abschaltbar sein, weil WIR wollen unter gar keinen Umstaenden
niemals nie nicht darueber ausschnueffelbar sein. Das waere ein viel zu
grosses Risikio fuer die nationale Sicherheit!!1elf"
Erinnert mich an eine Aussage eines deutschen Politikers (ich weiss
leider nicht mehr welcher Vollhorst das war... ist vielleicht auch
bessor so), als es um die VDS ging (sinngemaess):
"VDS und Massenueberwachung muss sein! Wir muessen alles und jeden,
immer und ueberall Ueberwachen! Terror, Kipo, etc. Aber Politiker muesse
davon ausgenommen werden! Das wuerde ja die Demokratie untergraben!"
Regeln die fuer alle gelten, ausser fuer einen selbst.
Alle sind gleich und manche sind gleicher...
Keine weiteren Fragen euer Ehren...
Kaj G. schrieb:> Besonders betroffen: SSD-Systeme.
Was nicht heisst, dass man mit HDDs besser dran wäre. Die
Transaktionsrate von SSDs ist auch hinterher viel höher als die von
HDDs. Es ist einfach so, dass es von der Anzahl System-APIs pro Sekunde
abhängt, wie stark ein System betroffen ist.
A. K. schrieb:> Kaj G. schrieb:>> Besonders betroffen: SSD-Systeme.>> Was nicht heisst, dass man mit HDDs besser dran wäre. Die> Transaktionsrate von SSDs ist auch hinterher viel höher als die von> HDDs.
Ich hab nie gesagt, das man SSDs jetzt wegschmeissen kann. Ich zitiere
nur die Artikel :)
Aus dem Artikel:
1
c't hat ebenfalls bereits starke Einbrüche bei der SSD-Leistung nach dem
2
Einspielen von BIOS- und Sicherheits-Updates feststellen können (Core
3
i7-8700K, Asus Maximus X Hero, Samsung 960 Pro). Die Samsung-SSD erreichte
4
nur noch 105.986 I/Ops beim Lesen und 79.313 I/Ops beim Schreiben im
5
Vergleich zu 197.525/185.620 I/OPs (vorheriges BIOS, Windows mit KB4054517).
6
Weitergehende Analysen, Benchmarks zu den Auswirkungen der Patches und
7
Untersuchungen der Updates finden Sie in der kommenden c't-Ausgabe 3/18.
Kaj G. schrieb:> Ich hab nie gesagt, das man SSDs jetzt wegschmeissen kann. Ich zitiere> nur die Artikel :)
Und ich habe nie angenommen, dass dir das nicht klar wäre. ;-)
Kaj G. schrieb:> "VDS und Massenueberwachung muss sein! .."> Keine weiteren Fragen euer Ehren...
Hohes Gerücht, sehr verkehrte Damen und Herren, Angesagter:
Geben Sie hier offen zu, sich der Mittäterschaft der allumfassenden
privaten Datenverschleuderung Schuldig gemacht zu haben, in dem Sie
tagtäglich ihr Leben, ihre Aktivitäten, ihre Vorlieben, ihr Bildmaterial
mit ihrem Smartphone in sog. sozialen Netzwerken verstreuten?
War Ihnen zu diesem Zeitpunkt denn nicht bewusst wie viele Dienste,
Geheimdienste, Werbefirmen, Versicherungen, Hacker und all die anderen,
die hier im Prozess aus Zeitgründen nicht genannt werden sollen, Sie
Teilnehmen ließen an ihrem Leben, an ihrem privatesten Aktivitäten?
Angesagter, gestehen Sie!
Alles Humbug schrieb:> Hohes Gerücht, sehr verkehrte Damen und Herren, Angesagter:> Geben Sie hier offen zu, sich der Mittäterschaft der allumfassenden> privaten Datenverschleuderung Schuldig gemacht zu haben, in dem Sie> tagtäglich ihr Leben, ihre Aktivitäten, ihre Vorlieben, ihr Bildmaterial> mit ihrem Smartphone in sog. sozialen Netzwerken verstreuten?>> War Ihnen zu diesem Zeitpunkt denn nicht bewusst wie viele Dienste,> Geheimdienste, Werbefirmen, Versicherungen, Hacker und all die anderen,> die hier im Prozess aus Zeitgründen nicht genannt werden sollen, Sie> Teilnehmen ließen an ihrem Leben, an ihrem privatesten Aktivitäten?>> Angesagter, gestehen Sie!
:)))
Einspruch, Euer Merkwürden!
Du passt in die Welt!
MfG Paul
Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von
diesem Problem betroffen ist? Sage jetzt aber niemand: "Auf der
Intel-Webseite" -da komme ich nämlich nach 1-stündiger Suche gerade her.
Die Windows 7-Updates sind fehlerfrei gelaugfen, wahrscheinlich, weil
ich vorsichtshalber noch einen Plattenabzug gemacht habe.
:)
MfG Paul
Paul B. schrieb:> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von> diesem Problem betroffen ist?
Ich würde mich da zu einem Glas klarem JAIN hinreißen lassen.
The following Intel-based platforms are impacted by this issue. Intel
may modify this list at a later time.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
"2nd generation Intel® Core™ processors"
https://de.wikipedia.org/wiki/Intel_Core_2
"Die Bezeichnung Intel Core 2 .. steht .. für die zweite Generation ..
nicht jedoch für die zweite Generation der Core-Mikroarchitektur, da der
Intel Core auf einer stark abgewandelten Version der P6-Architektur
basiert und daher lediglich einen Vorläufer der neuen Mikroarchitektur
darstellt."
Die Aufdröselung scheint dem geneigten (verunsicherten) Leser und
INTEL-Anwender im Kleingedruckten noch reichlich
Interpretationsspielraum zu belassen. Ungefähr ähnlich wie bei der
Einschätzung ob ein Gefährder nun wirklich zur Gefahr wird oder auch
nicht.
Gefährdungstechnisch ausgedrückt trägt deine CPU ein gewisses
Gefahrenpotential in sich und könnte somit mit zur Zielgruppe der
Auserwählten gehören.
Paul B. schrieb:> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von> diesem Problem betroffen ist?
Liste von Intel:
Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series
Nachdem der aktuelle Firefox gepatched wurde, gibt es zum
Firefox 52 ESR auch was:
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
"Update [January 4, 2018]: We have released the two timing-related
mitigations described above with Firefox 57.0.4, Beta and Developers
Edition 58.0b14, and Nightly 59.0a1 dated “2018-01-04” and later.
Firefox 52 ESR does not support SharedArrayBuffer and is less at risk;
the performance.now() mitigations will be included in the regularly
scheduled Firefox 52.6 ESR release on January 23, 2018."
Der FF 52 ESR ist wohl aufgrund seiner relativen Lahmheit deutlich
weniger betroffen als sein schneller Nachfolger.
Alles Humbug schrieb:> Paul B. schrieb:>> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von>> diesem Problem betroffen ist?>> Ich würde mich da zu einem Glas klarem JAIN hinreißen lassen.
Danke für Deine Antwort.
Tja -dann mal abwarten.
Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann
ich damit nichts.
MfG Paul
Paul B. schrieb:> Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann> ich damit nichts.
Kann ich nachvollziehen, die ist wirklich schwer zu interpretieren. Aber
dein Prozessor steht da tatsächlich nicht drauf.
A. K. schrieb:> Kann ich nachvollziehen, die ist wirklich schwer zu interpretieren. Aber> dein Prozessor steht da tatsächlich nicht drauf.
Ja, danke. Die o.g. Bezeichnung habe ich mit dem Programm "Everest"
auslesen lassen, da geht eben die Nomenklatur von der Intel-Webseite
nicht
konform.
MfG Paul