A. K. schrieb: > 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. Bist du sicher? Auf der INTEL Liste steht der Eintrag "2nd generation Intel® Core™ processors" affected und laut Wikipedia gilt: a) "Die „2“ steht vielmehr für die zweite Generation" b) "Die Variante für den Massenmarkt mit zwei Prozessorkernen (Doppelkernprozessor) wird Core 2 Duo genannt" Also scheint doch der Core 2 Duo wohl zu den "affected products" zu gehören, wenn Paul einen Core 2 Duo E8400 sein eigen nennt oder etwa nicht? Lediglich der Hinweis im Wiki auf eine abgewandelten Version der P6-Architektur hat mich ins Schleudern gebracht.
Die Frage bezüglich dieser ominösen Liste ist natürlich, ob Intel sich die Mühe gemacht hat, alle Prozessoren bis zurück zu Adam und Eva zu beerücksichtigen. Es fällt nämlich auf, dass sämtliche Intel OOO Prozessoren angefangen mit den Pentium Pro über Pentium 4 bis zu Pauls Wolfdale Core darin fehlen. Obwohl die ebenso spekulativ arbeiten wie ihre Nachfolger. Eine technische Grenze gibt es allerdings. Und zwar zwischen Pauls Wolfdale Core und dem Nachfolger Nehalem. Ab Nehalem steht jeder drin, davor keiner. Sind diese Oldtimer wirklich nicht betroffen, oder hat sich Intel bloss nicht die Mühe gemacht, sich darum zu kümmern?
:
Bearbeitet durch User
Alles Humbug schrieb: > Bist du sicher? Nur so sicher wie Intels eigener Marketing-Dekoder. Was immer das heisst. https://www.intel.com/content/www/us/en/processors/processor-numbers.html Demzufolge beschreibt die "2nd Generation Intel® Core™ Processor Family" Prozessoren der Nomenklatur "Core ix 2yyy". Pauls Prozessor fällt unter "Intel® Core™2 Duo Processor Family" und ist damit der Vorgänger der "Intel® Core™ Processor Family". Etwas kompliziert wirds allerdings bei den dreistelligen "Core ix yyy", denn die sind zwar "Intel® Core™ Processor Family" und damit draussen, aber andererseits "Core ix" mit maximal 45nm und damit drinnen. Dass die "Intel® Core™ Processor Family" nicht in der Liste steht, deren Prozessoren aber schon, sorgt etwas für Verwirrung.
:
Bearbeitet durch User
A. K. schrieb: > Sind diese Oldtimer wirklich nicht betroffen, oder hat sich Intel bloss > nicht die Mühe gemacht, sich darum zu kümmern? Meiner Einschätzung nach ist Pauls Core 2 Duo E8400 betroffen. Heise schrieb im FAQ: 5. Welche Prozessoren sind genau betroffen? "Dazu gehören etwa sämtliche Intel-Core-Prozessoren seit 2008, dazu die Serien Intel Atom C, E, A, x3 und Z sowie die Celeron- und Pentium-Serien J und N. Außerdem nahezu alle Server-Prozessoren der vergangenen Jahre sowie die Rechenkarten Xeon Phi" Nimm mal die 2008er Einführungszeit der CPU als untere Grenze an Nun wirf mal einen Blick hier drauf: https://ark.intel.com/products/33910/Intel-Core2-Duo-Processor-E8400-6M-Cache-3_00-GHz-1333-MHz-FSB "Launch Date Q1'08" und damit leider betroffen. Das Problem ist halt INTEL und dessen zweideutiges Geschwurbel.
Alles Humbug schrieb: > Das Problem ist halt INTEL und dessen zweideutiges Geschwurbel. Yep. Ich bin ja nicht immer ein Fan von Linus' Ausdrucksweise. Aber manchmal passt sie. Da allerdings die technische Seite des Problems weniger vom Datum als vom konkreten Core abhängen muss, habe ich das vorhin aus dieser Warte betrachtet. Und da ergibt Intels Liste m.E. eindeutig eine Grenze zwischen Pauls Wolfdale und dem Nachfolger Nehalem. Nur kann es natürlich sein, dass Intel bei dieser Liste mal wieder Nebenkerzen zündete und alles alte Zeug schlicht durch den Raster fallen liess.
:
Bearbeitet durch User
Wobei man das natürlich ausprobieren kann. Der Code von Spectre ist öffentlich.
Alles Humbug schrieb: > Meiner Einschätzung nach ist Pauls Core 2 Duo E8400 betroffen. Durchaus möglich. Ich schrieb nicht ohne Grund nur, dass Pauls Prozessor nicht auf der Liste stünde. Ich liess bewusst offen, ob er betroffen sei.
Beitrag #5275605 wurde vom Autor gelöscht.
Apropos Nebelkerze: In Intels Original (Link siehe oben) steht wörtlich "The following Intel-based platforms are impacted by this issue." Formaler Logik folgend sagt das natürlich nichts über jene Produkte aus, die nicht darin stehen. ARM wies in deren Liste freundlicherweise auch auf jene hin, die nicht betroffen sind. Diese Aussage fehlt bei Intel. Also Paul, du bist immer noch im Limbo.
A. K. schrieb: > Also Paul, du bist immer noch im Limbo. Im Limbo?! Mit dem Prozessor bin ich eher beim langsamen Walzer. MfG Paul
Paul B. schrieb: > Im Limbo?! Mit dem Prozessor bin ich eher beim langsamen Walzer. Sorry, das Tanzen wollte ich dir ersparen. Englisch Limbo = Deutsch Limbus.
:
Bearbeitet durch User
O.T. A. K. schrieb: > Sorry, das war ein Anglismus. Englisch Limbo = Deutsch Limbus. Man muß nicht unbedingt mit Fremdworten beeindrucken wollen -das kann auch zur völligen Verwirrung führen: https://de.wikipedia.org/wiki/Limbus Paul
Paul B. schrieb: > Man muß nicht unbedingt mit Fremdworten beeindrucken wollen ... sondern eher mit fremden Ausdrucksweisen, auch unbeabsichtigt. Hier passte diese perfekt: "in an uncertain or undecided state or condition" https://www.merriam-webster.com/dictionary/in%20limbo
:
Bearbeitet durch User
Alles Humbug schrieb: > 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. Leider von der Wirklichkeit überholt. Mist! "AMD rudert zurück: Prozessoren doch von Spectre 2 betroffen, Microcode-Updates für Ryzen und Epyc in Kürze" https://www.heise.de/newsticker/meldung/AMD-rudert-zurueck-Prozessoren-doch-von-Spectre-2-betroffen-Microcode-Updates-fuer-Ryzen-und-Epyc-in-3939975.html
Hi Um feedback/Verbesserungen wäre ich dankbar: Beitrag "Feedback GCC Spectre LFENCE patch" MfG und schönes WE
Lustig ist ja, dass das laut Intel kein Fehler ist, sondern alles wie gewünscht funktioniert. So heißt es auf https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html : Is this a bug in Intel hardware or processor design? No. This is not a bug or a flaw in Intel® products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Rolf M. schrieb: > Lustig ist ja, dass das laut Intel kein Fehler ist, sondern alles wie > gewünscht funktioniert. Das wurde oben schon mal thematisiert. Man kann das tatsächlich so sehen wie Intel. Die Funktion der Prozessoren ist völlig korrekt, es lassen sich aber Nebenwirkungen des Laufzeitverhaltens ausnutzen. In diesem Sinn stimme ich ihm zu: Andreas S. schrieb: > Auf einer sehr abstrakten Ebene kann man das ganze zwar schon als Bug > bezeichnen, nicht jedoch auf der Implementierungsebene der Prozessoren. Man hat auch schon Security Chips per side channel geknackt, indem man deren Stromverbrauch analysierte - ist das ein echter Fehler im Sinn der Spezifikation?
Kleiner Spass am Rande: Ich bin gespannt, ob demnächst Android-Patches auftauchen werden, offizielle oder inoffizielle, die das Problem besserer Mobilgeräte in bester Apple-Manier lösen. Wenn von den enthaltenen Cores die meist 4 langsamen Stromspar-Cores (A53) sicher sind und die sowieso nur bei Bedarf eingeschalteten 2-4 Performances-Cores (A57 aufwärts) nicht - was könnte man da wohl tun? Sobald sehr ernst zu nehmende Schädlinge unterwegs sind wär mir das nicht einmal unrecht. Ok, ein Hersteller-Patch wär natürlich besser, aber wenns den nicht gibt und nur die Alternative bliebe, das keine 2 Jahre alte Teil andernfalls wegzuwerfen? Als ARM Strategie würde ich dann für die Zukunft empfehlen, nicht lauter gleiche Cores einzubauen, sondern lauter verschieden arbeitende (*). Bei künftig aufkommenden Bugs kann man die dann sukzessive einen nach dem anderen abschalten. Mikrocode gibts in RISCs ja nicht, kann man also auch nicht patchen. ;-)) *: Intel und AMD auf der gleichen CPU gibts zwar mittlerweile auch schon, aber leider nicht in diesem Sinn. ;-)
:
Bearbeitet durch User
Update zu anfänglichen Verschwörungstheorien: Wenn Intel das verbrochen hätte, um neue Prozessoren zu verkaufen, dann ergäbe das auf den ersten Blick sogar Sinn. Der als Spekulationsbremse gehandelte und in aktuellen Linux Kernels deshalb vermehrt genutzte LFENCE Befehl ist bei neueren Intels deutlich schneller (4T) als bei alten (8-9T) und erst recht dem P4 (38/50T). Blöd für Intel wär dann bloss, dass AMD dabei einmal mehr vorne liegt (1T, 4x parallel). Also abgesehen von seiner Funktion als Spekulationsbremse, die natürlich ebenfalls zu Wartezyklen führen kann. Quelle: die Tabellen von Agner Fog.
:
Bearbeitet durch User
Apropos LFENCE: Bei genauer Betrachtung der Definition dieses Befehls fällt mir auf, dass sich diese mit den Jahren verändert hat. Bezog er sich in der Referenz von 2009 ausschliesslich auf die Ordnung von Load-Befehlen untereinander, liest sich die Referenz von 2015 so, als ob alle Befehle betroffen sind, nicht nur Loads. Intel 2009: "Performs a serializing operation on all load-from-memory instructions that were issued prior the LFENCE instruction. This serializing operation guarantees that every load instruction that precedes in program order the LFENCE instruction is globaly visible before any load instruction that follows the LFENCE instruction is globally visible. ..." Intel 2015 (ebenso Dezember 2017): "Performs a serializing operation on all load-from-memory instructions that were issued prior the LFENCE instruction. Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE completes. ..." AMDs aktuelle Referenz von Dezember folgt Intels ursprünglicher Definition: "Acts as a barrier to force strong memory ordering (serialization) between load instructions preceding the LFENCE and load instructions that follow the LFENCE. Loads from differing memory types may be performed out of order, in particular between WC/WC+ and other memory types. The LFENCE instruction assures that the system completes all previous loads before executing subsequent loads. ..." Das wirft zwei Fragen auf: Hilft die ursprüngliche Definition überhaupt gegen Spectre? Ist das eine Änderung im Verhalten von Intels Prozessoren, oder folgt die Beschreibung dem sowieso immer schon vorhandenen Verhalten?
:
Bearbeitet durch User
Meltdown & Spectre: Google brüstet sich mit "unbemerkten" Cloud-Patches https://www.heise.de/security/meldung/Meltdown-Spectre-Google-bruestet-sich-mit-unbemerkten-Cloud-Patches-3942644.html
1 | Google hat die Super-GAU-Lücke nach eigenen Angaben schon vor |
2 | Monaten gepatcht, ohne irgend jemandem was davon zu erzählen. |
3 | Auch will man Spectre ohne Wenn und Aber gebannt haben, was den |
4 | Aussagen der Entdeckern der Lücke widerspricht. |
5 | |
6 | Forscher von Googles Project Zero waren maßgeblich an der |
7 | Entdeckung und Erforschung der Sicherheitslücken Meltdown und |
8 | Spectre beteiligt. Google wusste daher seit mindestens Mitte 2017 |
9 | von den drei verschiedenen Sicherheitslücken und dem Einfluss der |
10 | Patches auf die Performance der betroffenen Prozessoren. Nun brüstet |
11 | sich die Firma damit, die ersten Patches schon im September, |
12 | beziehungsweise im Oktober 2017 auf den eigenen Cloud-Servern |
13 | ausgespielt zu haben. Kunden hätten dabei keine Performance-Verluste |
14 | bemerkt ("no perceptible impact"). Der Allgemeinheit bekannt geworden
|
15 | waren die Lücken erst im Januar 2018. |
16 | |
17 | |
18 | Google widerspricht dem Spectre-Paper |
19 | |
20 | Außerdem ist Google mächtig stolz auf seine Compiler-Modifikation |
21 | Retpoline: Software, die mit Hilfe dieser Technik kompiliert wird, |
22 | soll gegen die zweite Variante von Spectre komplett immun sein. Eine |
23 | Behauptung, die den Einschätzungen in der akademischen Veröffentlichung |
24 | der Entdecker der Lücken widerspricht. Google nennt seine Entdeckung |
25 | einen "Moonshot" – eine unwahrscheinliche Entdeckung oder Leistung, in |
26 | der viel Arbeit steckt und die revolutionäre Auswirkungen hat. |
A. K. schrieb: > 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. Genau so ist es. Wen es interessiert, kann sich den Vortrag vom letzten CCC anschauen, da hat sich jemand damit befasst und die (leichte) Verschlüsselung für die Microcode-Images geknackt. Daraus lassen sich interessante Angriffe basteln. "Everything you want to know about x86 microcode, but might have been afraid to ask An introduction into reverse-engineering x86 microcode and writing it yourself" https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask
Beitrag #5282770 wurde von einem Moderator gelöscht.
Beitrag #5282830 wurde von einem Moderator gelöscht.
Die Neuerungen von Linux 4.15 https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
1 | Das noch diesen Monat erwartete Linux 4.15 schützt vor den Auswirkungen |
2 | der Sicherheitslücken Meltdown und Spectre. Ohne Performance-Verlust geht |
3 | das aber auch bei Linux nicht. An weiteren Gegenmaßnahmen schrauben die |
4 | Kernel-Entwickler bereits. |
Meltdown & Spectre: Microsofts C/C++-Compiler schützt vor bestimmten Angriffen https://www.heise.de/newsticker/meldung/Meltdown-Spectre-Microsofts-C-C-Compiler-schuetzt-vor-bestimmten-Angriffen-3944889.html
1 | Microsoft hat seinen C/C++Compiler um eine Option erweitert, |
2 | mit der er Befehle in den erzeugten Code einbaut, die die |
3 | übersetzte Anwendung vor Angriffen nach Spectre Variante 1 |
4 | schützen soll. |
Lady Hesketh-Fortescue aus North Cothelstone Hall schrieb im Beitrag #5282770: > Das ist ja mal richtig schmierig. Wenn es dann irgendwann mal genutzt > wird, kriegt man den Ausführenden dieses Vortrages eventuell wegen > Mitwirkung an Sabotage am Arsch. Oh ja, lasst es uns totschweigen, wird schon kein anderer auf die Idee kommen da mal nachzusehen. Hallooo? Security by obscurity funktioniert nicht!
Karl schrieb: > Security by obscurity funktioniert nicht! Vielleicht merkt es ja keiner,oder es ist ihnen egal? Hier will der Innenminister zukünftig nichtmal mehr protokollieren lassen welcher Polizist wann warum welche Daten abfragt. Und du willst einen saven Prozessor. Wie bist du den drauf? Willst du vielleicht auch noch auf Privatspähre, Perönlichkeitsrechte, (auch elektronisches) Briefgeheimnis, Telekommunikationsgeheimnis und umfassenden Datenschutz bestehen? Na du bist mir ja Einer, hast du was zu verbergen? Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > Na du bist mir ja Einer, hast du was zu verbergen? Auch wenn dein Post ironisch/sarkastisch gemmeint ist (hoffe ich), lautet die Antwort: JA! Ein bisschen Geschichtsunterricht gefaellig? Wuerde dem Herrn Innenminister auch gut tun... https://www.heise.de/ct/ausgabe/2015-17-Editorial-Nichts-zu-verbergen-2755486.html
Winfried J. schrieb: > Willst du vielleicht auch noch auf Privatspähre, > Perönlichkeitsrechte, (auch elektronisches) Briefgeheimnis, > Telekommunikationsgeheimnis und umfassenden Datenschutz bestehen? Nicht das da noch jemand behauptet, diese Schutzrechte würden bei Nutzung sozialer Netzwerke nicht umfangreich beachtet. Das wäre vielleicht ein Schelm. > Na du bist mir ja Einer, hast du was zu verbergen? Darüber muss er gleich via Twitter mit seiner Gefolgschaft plaudern.
Karl schrieb: > Security by obscurity funktioniert nicht! Da kann ich nur zustimmen. Nur wenn eine Sicherheitslücke bekannt ist, kann diese behoben werden, aber wenn eine Sicherheitslücke nicht bekannt ist, kann diese von läuten, die zufällig darauf stossen trozdem ausgenutzt werden. Winfried J. schrieb: > Na du bist mir ja Einer, hast du was zu verbergen? Ja, ist doch langweilig keine Geheimnisse zu haben, und alles muss nun wirklich nicht jeder über mich wissen. Auf jeder Webseite nutze ich eine andere E-Mail/Account. Ich habe einen Twitter Account für Leute die danach Suchen, und einen den ich eigentlich nutze, mit Dingen von denen es zwar nichts ausmacht, wenn jemand davon weiss, die aber auch nicht jeder zu wissen braucht. Und dann habe ich noch ein Pseudonym, dass ich nur auf dedizierten Systemen nutze, dessen Internet Traffic nur über Tor geroutet werden kann, für Dinge, von denen wirklich niemand wissen soll, von wem sie sind. Dann habe ich noch Privates, das auf meinem Server Zuhause gespeichert ist und nicht öffentlich zugänglich und nicht auf Fremden Systemen ist. Und dann noch die Dinge, die nur Lokal auf meinem eigenen PC sind. So kann man recht gut kontrollieren, wer was weiss. Ich habe mal einen Artikel geschrieben, warum Internetüberwachung keine gute Idee ist: https://www.danielabrecht.ch/internetueberwachung/ Es ist doch immer das Gleiche mit der Überwachung, immer heisst es man müsse eben ein paar Rechte und Freiheiten opfern, wenn man sicher leben wolle, aber was dies am Ende bedeuted, wozu dies alles Führt, daran denkt natürlich keiner. Man hätte ja nichts zu verbergen. Die Daten könnten ja nicht misbraucht werden, es währe ja alles Gesetzlich geregelt. Korruption wäre nur in anderen Ländern möglich, sowas gäbe es hier nicht. Das habe ich andere alles schon sagen hören, es ist schon unglaublich, wie Naiv viele Menschen sind. Sicher, es gibt manchmal Terroranschläge, und das ist schrecklich und alles, aber das passiert derart selten und trifft derart wenige Menschen im vergleich zu anderen Tragödien wie Autounfällen usw., dass ich nicht glaube dass es es wert ist, deswegen jeden seine Freiheiten aufgeben zu lassen. Man sollte einfach bei guten und Bewährten prinzipien bleiben: Die Leute erst verurteilen, wenn diese auch tasächlich etwas unrechtes getan haben.
Beitrag #5283963 wurde von einem Moderator gelöscht.
Beitrag #5283970 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
Sarcasm.png
110 KB
Sorry, hatte es nicht zur Hand. deshalb um der um sichgreifenden Verwirrung entgegenzuwirken. und noch das: "Aber ich habe doch gar kein facebook?" Namaste
:
Bearbeitet durch User
Kaj G. schrieb: > Ein bisschen Geschichtsunterricht gefaellig? Wuerde dem Herrn > Innenminister auch gut tun... > https://www.heise.de/ct/ausgabe/2015-17-Editorial-Nichts-zu-verbergen-2755486.html hm, den Geschichtsunterricht in dieser Sache benötige ich nicht mir ist das klar. Auch Innenminister Kickl weiß genau was er tut: "Die ÖVP-FPÖ-Koalition bezeichnete Kickl als Gegenentwurf zur linken 68er-Generation." https://kurier.at/politik/inland/fpoe-innenminister-kickl-erteilte-auftrag-fuer-eigene-grenzschutzeinheit/307.283.193 Und die Physiognomie des Herren hat auch ein gewisses dejá vue Potential. Namaste
Stephan B. schrieb: > ...und es geht wohl weiter: Vielleicht. Vielleicht aber doch nicht so. Das wird von Heise und der TU Graz bislang eher als Scherz gehandelt. Man muss nicht jeder Karotte hinterher laufen, die einem vor die Nase gehalten wird. Sondern kann abwarten, bis mehr dahinter ist als 2 Webseiten ohne Inhalt.
:
Bearbeitet durch User
A. K. schrieb: > nicht jeder Karotte hinterher laufen, Nu freilisch, als kennte er nicht seine Pappenheimer! Namaste
Und es geht weiter: Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Intel-zieht-Microcode-Updates-fuer-Prozessoren-zurueck-3948447.html
1 | Noch größeres Chaos bei den Sicherheitslücken in Intel-Prozessoren: |
2 | Weil Updates im manchen Fällen Probleme verursachen, rät Intel von |
3 | der Installation ab; unter anderem HPE, Ubuntu, Red Hat und VMware |
4 | ziehen Updates zurück. |
5 | |
6 | Die Probleme reißen nicht ab: Intel rät davon ab, die zuvor |
7 | bereitgestellten CPU-Microcode-Updates einzuspielen, die zum Schließen |
8 | der Sicherheitslücke Spectre Variante 2 (Branch Target Injection, BTI, |
9 | CVE-2017-5715) nötig sind. Einige PC-Hersteller haben zuvor |
10 | bereitgestellte BIOS-Updates mit diesem Microcode-Updates wieder von |
11 | ihren Webseiten genommen. Auch einige Linux-Distríbutionen ziehen |
12 | Microcode-Updates zurück. |
Linus Torvalds auf der Mailingliste: http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html
1 | > We do need the IBPB feature to complete the protection that retpoline |
2 | > gives us â it's that or rebuild all of userspace with retpoline. |
3 | |
4 | BULLSHIT. |
:
Bearbeitet durch User
Kaj G. schrieb: > Linus Torvalds auf der Mailingliste: > BULLSHIT. Nun ist Linus nicht gerade für besondere Zurückhaltung bekannt, weshalb es bei ihm nicht immer leicht ist, ein ernstes Bullshit vom Grundrauschen zu unterscheiden. ;-) Aber so wie das läuft frage ich mich schon, was im derzeitigen Stadium gefährlicher ist: die Löcher, oder die Versuche, sie zu stopfen. Interessanterweise zieht HPE zwar haufenweise Server-Updates zurück, aber das BIOS eines HP PCs mit Haswell drin gab es heute noch. Ok, HP und HPE sind wohl geschiedene Leute, aber ich wüsste schon gern, ob das System hat, oder bloss Zufall ist. Immerhin, der PC läuft noch.
:
Bearbeitet durch User
A. K. schrieb: > Interessanterweise zieht HPE zwar haufenweise Server-Updates zurück, > aber das BIOS eines HP PCs mit Haswell drin gab es heute noch. Das war Stand gestern. Heute gibts das nicht mehr. Sinn für Timing...
Zhaoxin KX-5000: Auch Chinas x86-Chips sind anfällig für Spectre https://www.golem.de/news/zhaoxin-kx-5000-auch-chinas-x86-chips-sind-anfaellig-fuer-spectre-1801-132309.html
1 | Nach der Ankündigung der KX-5000 (Wudaokou) hat der chinesische Hersteller |
2 | Zhaoxin die technischen Daten der x86-Prozessoren veröffentlicht und sich |
3 | auch zur Anfälligkeit für Meltdown und Spectre geäußert. Die Chips basieren |
4 | auf einem Centaur-Design von Via, wie Wikichip unter Berufung auf Zhaoxin |
5 | berichtet. Es bleibt unklar, ob es sich um eine Abwandlung der Isaiah- oder |
6 | der Isaiah-2-Technik handelt, wobei Letzteres wahrscheinlicher ist. |
7 | |
8 | Laut Zhaoxin sind die Wudaokou nicht für Meltdown anfällig, allerdings für |
9 | eine nicht genannte Variante von Spectre. Laut Hersteller sei ein Angriff |
10 | aber aufwendig, da die Sprungvorhersage mit sehr vielen Befehlen bearbeitet |
11 | werden müsste, um ausgehebelt zu werden - das ist aber bei Chips von AMD, |
12 | ARM oder Intel nicht viel anders. |
Was mich hier etwas stoert, ist dieser Satz:
1 | Laut Zhaoxin sind die Wudaokou nicht für Meltdown anfällig, allerdings für |
2 | eine nicht genannte Variante von Spectre. |
"nicht genannte Variante von Spectre" -> Soll das heissen, das der Hersteller nicht sagt fuer welche Variante, oder heisst das, das es noch eine andere, bisher unbekannte Variante von Spectre gibt? Ich frage mich, ob es schon mal ein aehnliches Sicherheitsproblem dieser Groesse gab? Klar, Heartbleed war auch riesig und wurde auch durch alle Medien getreten, war aber vergleichsweise einfach zu beheben.
Spectre adressiert das Grundprinzip von Out-Of-Order Prozessoren. Interessanter wären folglich ausdrückliche Aussagen, dass bestimmte Typen mit OOO Implementierung definitiv nicht anfällig wären. Kaj G. schrieb: > "nicht genannte Variante von Spectre" Da die Spectre Exploits den Sprungvorhersagemechanismus trainieren müssen, um Wirkung zu erzielen, sind sie abhängig von dessen Implementierung. Weshalb ein Exploit für Intels Skylake bei AMDs Zen nicht wirken muss. Da ist ja auch AMD anfangs drauf reingefallen.
Zu VMware ESXi und dem Microcode Problem gibts auch etwas mehr als nur den KB-Artikel https://kb.vmware.com/s/article/52345. Um rauszufinden, was aktiv ist, und den Microcode auch wieder los werden zu können: https://www.heise.de/forum/heise-online/News-Kommentare/Meltdown-und-Spectre-Neustart-Probleme-auch-mit-Skylake-und-Kaby-Lake-CPUs-neue-Intel-Benchmarks/ESXi-Microcode-Update-wieder-loswerden/posting-31708040/show/
"Absoluter Müll": Linus Torvalds verliert die Geduld mit Spectre-Patches https://www.heise.de/newsticker/meldung/Absoluter-Muell-Linus-Torvalds-verliert-die-Geduld-mit-Spectre-Patches-3948756.html
1 | "Diese Patches sind absoluter Müll", stellte er fest. "Sie machen |
2 | buchstäblich wahnsinnige Dinge. Dinge, die keinen Sinn machen." |
Interessant finde ich den nachfolgenden Satz:
1 | Jemand, so Linus, wolle diese Patches aus Gründen im Kernel haben, |
2 | über die er nicht die Wahrheit sagen wolle. Eine klare Beschuldigung |
3 | gegenüber Woodhouse und seinem ehemaligen Arbeitgeber Intel. |
Achtung, Aluhut: Hoert sich fuer mich so an, als ob an den Patches irgendwas faul ist, und zwar so richtig. Und damit meine ich nicht nur die Codequalitaet...
Kaj G. schrieb: > "Absoluter Müll": Linus Torvalds verliert die Geduld mit Spectre-Patches "... dass er es wohl lieber gesehen hätte, dass die Firma betroffene Prozessoren austauscht anstatt die Sicherheitslücken per Software-Update im Betriebssystem und im Microcode der Prozessoren zu stopfen." Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde das für Intel an Selbstmord grenzen und bis das durch auch nur zurück bis Haswell durch wäre, wären die Systeme längst gehackt. Nope. Da hat sich Linus Torvalds verrannt. Wenn das nicht per Software geht, Microcode eingeschlossen, dann kurzfristig überhaupt nicht. PCs und Systeme haben eine Einsatz-Lebensdauer von mindestens 5 Jahren, Server und Blackboxes nicht selten bis zu 10 Jahren. Mit einer Verweigerung pragmatischer Lösungen fordert Linus Torvalds im Grunde, dass weltweit alle Systeme ausser den letzten 1-2 Chipgenerationen noch dieses Jahr weggeworfen und ersetzt werden sollten, weil FUBAR. Ach ja: Und Apple tauscht kostenlos alle iPhones der letzten Jahre aus, sobald sie welche haben, die mit sicheren Prozessoren ausgestattet sind. Bis dahin müssen sich die iPhone-Jünger mit Android Lowend/Midrange-Geräten mit Cortex A53 bescheiden. ;-)
:
Bearbeitet durch User
Kaj G. schrieb: > Hoert sich fuer mich so an, als ob an den Patches irgendwas faul ist, > und zwar so richtig. Und damit meine ich nicht nur die Codequalitaet... Das hört sich für mich zunächst nur so an, als ob Torvalds aus der Haut fährt. Das macht der allerdings öfter und "Nach Torvalds Wutausbruch gingen die Kernel-Entwickler wie gewohnt schnell wieder zum Tagesgeschäft über und widmeten sich der Arbeit an den Spectre-Patches." Man kennt sich.
:
Bearbeitet durch User
A. K. schrieb: > Kaj G. schrieb: >> "Absoluter Müll": Linus Torvalds verliert die Geduld mit Spectre-Patches > > "... dass er es wohl lieber gesehen hätte, dass die Firma betroffene > Prozessoren austauscht anstatt die Sicherheitslücken per Software-Update > im Betriebssystem und im Microcode der Prozessoren zu stopfen." > > Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde > das für Intel an Selbstmord grenzen und bis das durch auch nur zurück > bis Haswell durch wäre, wären die Systeme längst gehackt. > > Nope. Da hat sich Linus Torvalds verrannt. Wenn das nicht per Software > geht, Microcode eingeschlossen, dann kurzfristig überhaupt nicht. Das schöne an solchen Meldungen ist immer, dass anscheinend kaum mal jemand in den Redaktionen den gesamten Text/Thread ließt... Liste http://lkml.iu.edu/hypermail/linux/kernel/1801.2/index.html#05708 Message http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html Es war nicht Linus, sondern David Woodhouse
1 | From: Linus Torvalds |
2 | Date: Sun Jan 21 2018 - 16:36:05 EST |
3 | Next message: Jes Sorensen: "Re: [PATCH] rtl8xxxu: Fix trailing semicolon" |
4 | Previous message: Heiko Stübner: "Re: [PATCH 0/2] Input: auo-pixcir-ts: Adjustments for two function implementations" |
5 | In reply to: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation" |
6 | Next in thread: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation" |
7 | Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] |
8 | On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: |
9 | > On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: |
10 | >> All of this is pure garbage. |
11 | >> |
12 | >> Is Intel really planning on making this shit architectural? Has |
13 | >> anybody talked to them and told them they are f*cking insane? |
14 | >> |
15 | >> Please, any Intel engineers here - talk to your managers. |
16 | > |
17 | > If the alternative was a two-decade product recall and giving everyone |
18 | > free CPUs, I'm not sure it was entirely insane. |
19 | |
20 | You seem to have bought into the cool-aid. Please add a healthy dose |
21 | of critical thinking. Because this isn't the kind of cool-aid that |
22 | makes for a fun trip with pretty pictures. This is the kind that melts |
23 | your brain. |
> PCs und Systeme haben eine Einsatz-Lebensdauer von mindestens 5 Jahren, > Server und Blackboxes nicht selten bis zu 10 Jahren. Mit einer > Verweigerung pragmatischer Lösungen fordert Linus Torvalds im Grunde, > dass weltweit alle Systeme ausser den letzten 1-2 Chipgenerationen > noch dieses Jahr weggeworfen und ersetzt werden sollten, weil FUBAR. Er verweigert sich ja nicht, sondern will nur keinen sinnlosen Schwachsinn mit massiven Performanceeinbußen, wenn es auch anders/besser geht. Von Ingo Molnar kommt später noch ein interessanter Vorschlag ohne den Intel-Kram im Kernel http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05628.html
1 | So I talked this over with PeterZ, and I think it's all doable: |
2 | |
3 | - the CALL __fentry__ callbacks maintain the depth tracking (on the kernel |
4 | stack, fast to access), and issue an "RSB-stuffing sequence" when depth reaches 16 entries. |
5 | |
6 | - "the RSB-stuffing sequence" is a return trampoline that pushes a CALL on the stack which is executed on the RET. |
7 | |
8 | - All asynchronous contexts (IRQs, NMIs, etc.) stuff the RSB before IRET. (The tracking could probably made IRQ and maybe even NMI safe, but the worst-case nesting scenarios make my head ache.) |
9 | |
10 | I.e. IBRS can be mostly replaced with a kernel based solution that is better than IBRS and which does not negatively impact any other non-SkyLake CPUs or general code quality. |
11 | |
12 | I.e. a full upstream Spectre solution. |
Fakt ist doch, dass diese Patzer der Hersteller sich in einer gewaltigen Umsatzwelle ($$$) für diese niederschlagen wird. Das Gejammer der User kostet sie dagegen wenig. Da finde ich die Idee gar nicht abwegig, selbst in wirtschaftlichen Sinne, daß sie sich an einer breiten Umrüstung bestehender Systeme beteiligen.
A. K. schrieb: > Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde > das für Intel an Selbstmord grenzen > > Ach ja: Und Apple tauscht kostenlos alle iPhones der letzten Jahre aus, > sobald sie welche haben, die mit sicheren Prozessoren ausgestattet sind. > Bis dahin müssen sich die iPhone-Jünger mit Android > Lowend/Midrange-Geräten mit Cortex A53 bescheiden. ;-) Ja und? Dann ist das eben so. Was Du schreibst kommt folgendem gleich: "Wir sind too big to fail. Hier gibt's nichts zu sehen, bitte weiter gehen. Konsequenzen bleiben aus. Wir machen, was wir wollen. Deshalb kann ähnliches auch zukünftig immer wieder passieren. Warum auch nicht?" Solch eine Einstellung kann man gut finden, muss man aber nicht.
...jedes KMU wäre platt, aber so ist es natürlich was anderes...
Debian: Spectre & Meltdown vulnerability/mitigation checker A simple shell script to tell if your Linux installation is vulnerable against the 3 "speculative execution" CVEs that were made public early 2018. https://packages.debian.org/stretch-backports/spectre-meltdown-checker
Rolf M. schrieb: > Winfried J. schrieb: >> Costum Prozessoren > > Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching > verkleide. > > /SCNR/ Und dabei die Bitmaske nicht vergessen!
:
Bearbeitet durch User
Intel scheint doch schon so früh von diesem Datenleck gewusst zu haben, dass sie ihr Logo entsprechend designen konnten: https://twitter.com/nixcraft/status/955873630646280192
:
Bearbeitet durch User
GCC 7.3 Released https://gcc.gnu.org/ml/gcc/2018-01/msg00197.html
1 | GCC 7.3 is a bug-fix release from the GCC 7 branch |
2 | containing important fixes for regressions and serious bugs in |
3 | GCC 7.2 with more than 99 bugs fixed since the previous release. |
4 | |
5 | This release includes code generation options to mitigate |
6 | Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. |
A. K. schrieb: > AMDs aktuelle Referenz von Dezember folgt Intels ursprünglicher > Definition: Das Verhalten von LFENCE lässt sich bei den meisten AMD Prozessoren per MSR so anpassen, dass der Befehl vollständig serialisiert. Aus AMDs Text zur Umgehung. Den hat allerdings garantiert noch niemand korrekturgelesen, derzeit wird viel mit der heissen Nadel gestrickt: http://developer.amd.com/wordpress/media/2013/12/Managing-Speculation-on-AMD-Processors.pdf PS: Aluhut-Trägern wird bestimmt was im Filenamen auffallen. ;-)
:
Bearbeitet durch User
Guter Artikel über die Folgen für Sysadmins: https://www.heise.de/ix/heft/Gespensterjagd-3948309.html
Ein Vortrag von der BTU Cottbus-Senftenberg zu Meltdown und Spectre: Kernschmelze der Computersicherheit https://youtu.be/PsC8lse2u54
:
Bearbeitet durch User
Danke für den Clip, spannend wie ein Krimi. Mal wieder ne Bitte um Einschätzung der Brisanz für Otto Normal: Geht nicht generell nach wie vor eine viel größere Gefahr durch defekte oder manipulierte Treiber aus, die einfach in den Kernel- oder Realspeicher greifen?
batman schrieb: > Mal wieder ne Bitte um Einschätzung der Brisanz für Otto Normal: Das Risiko geht von Fremdsoftware auf dem Rechner aus. Je dynamischer desto höher. Den krassesten Fall bilden deshalb Browser über Javascript in Webseiten. Da kommt täglich tonnenweise Zeug aus den fragwürdigsten Quellen rein. Weshalb deren Hersteller auch schnell mit ersten Massnahmen reagierten. Deshalb: Augen offen halten, was man da ggf. machen kann, einschalten kann. Also ob der Browser beispielsweise die Möglichkeit bietet, Seiten gegeneinander zu isolieren. Ich habe da nicht den Überblick, aber bei Opera ist das derzeit eine Beta-Option, also explizit einzuschalten. Sinnvoll sind auch Werbefilter, Browser-Plugins als Javascript-Filter, sofern man diesem Plugins über den Weg traut. Der am wenigsten kontrollierte und unsicherste Kram ist Werbung. Da wissen auch die seriösesten Websites meist selber nicht, was auf ihren Seiten zeitweise rumlungert. > Geht nicht generell nach wie vor eine viel größere Gefahr durch defekte > oder manipulierte Treiber aus, die einfach in den Kernel- oder > Realspeicher greifen? Bei Software, die eigene Treiber mitbringt, generell privilegierten Code nutzt, braucht man sich um Spectre/Meltdown wenig zusätzliche Gedanken zu machen. Die können auch ohne diese Lücken viel Unfug stiften. Das war schon immer Vertrauenssache. Software, die ohne privilegierte Komponenten auskommt, gewinnt durch die Lücken erhebliche Möglichkeiten. Es war schon bisher klug, nicht alles zu installieren, was Web oder Freundeskreis bieten, ist jetzt noch mehr.
:
Bearbeitet durch User
Beitrag #5295075 wurde vom Autor gelöscht.
Nochmal zu Massnahmen: Dass man bei Intel-Prozessoren einen Kernel einsetzen sollte, der gegen Meltdown geschützt ist, sollte selbstverständlich sein. Dagegen spricht auch die Malaise mit dem Mikrocode nicht, die hat damit nämlich überhaupt nichts zu tun. Es was schon bisher sinnvoll, kritische Operationen wie Banking, Einkäufe etc nicht neben anderen Browser-Sessions durchzuführen. Jetzt noch mehr. Sicherer wirds dann noch, wenn man vorher und nachher den Browser schliesst - und zwar wirklich, da sollte kein Schnellstart-Zombie in der Prozessliste mehr rumlungern. Wer es nicht lassen kann, permanent eine sicherheitskritische Seite offen zu halten, der kann drüber nachdenken, dafür einen separaten Browser zu verwenden.
:
Bearbeitet durch User
Also selbst wenn man nichts ändert, bleiben hoch sicherheitskritische Systeme relativ sicher, weil kein Fremdcode reinkommt, dem man viel Handlungsspielraum bietet? Der heimische PC bleibt unsicher, weil man weiterhin genau das Gegenteil tut und alle möglichen brandheißen Anwendungen und Gerätchen ausprobiert. Auch wenn man hier mit speziellen Browsern, Plugins o.ä. gegensteuern will, schafft man damit doch eher noch bessere Angriffsmöglichkeiten oder? Glaube nicht so ganz daran, daß jemand sowas gut prüft.
batman schrieb: > Also selbst wenn man nichts ändert, bleiben hoch sicherheitskritische > Systeme relativ sicher, weil kein Fremdcode reinkommt, dem man viel > Handlungsspielraum bietet? Ausser natürlich, der Fremdcode kommt über z.B. bereits bestehende Buffer Overflow Löcher rein, und der bekommt nun neue Möglichkeiten. > Der heimische PC bleibt unsicher, weil man weiterhin genau das Gegenteil > tut und alle möglichen brandheißen Anwendungen und Gerätchen > ausprobiert. Ja. > Auch wenn man hier mit speziellen Browsern, Plugins o.ä. > gegensteuern will, schafft man damit doch eher noch bessere > Angriffsmöglichkeiten oder? Massnahmen wie Site Isolation dienen generell der Sicherheit. Da entstehen m.E. auch keine neuen Angriffsvektoren. Ich habe nur, wie schon gesagt, keinen Überblick darüber, wie welcher Browser heute arbeitet. Zunächst einmal lebt es sich ohne Javascript sicherer als mit. Soweit ists einfach und war auch bisher schon so. Nur ist das nun dank der Lecks noch weit kritischer. Dass Plugins eigene Risiken enthalten könnten ist klar. Aber sich für jede Site durch die Einstellungen des Browser schlängeln zu müssen, um das je nach Bedarf ein- und auszuschalten - wer macht das freiwillig? Deshalb läuft es de fakto doch darauf hinaus, einen Kompromiss zwischen Sicherheit und Nutzbarkeit zu finden.
:
Bearbeitet durch User
Auch wenn ich gleich wieder, meine speziellen Freude finden werde, sei es noch mal ventiliert: Es gibt keine Möglichkeit weder ein Medium noch einen Kanal „sicher“ abzudichten. Man kann lediglich die Hürden für die Kompromittierung so hoch legen, dass dem potentiellen Angreifer andere Ziele lohnender erscheinen oder seine Resuorcen nicht ausreichen. Alle Daten welche außerhalb meiner Kontrolle liegen muss ich per se als potentiell kompromiitierbar erachten. Dazu zählt alles was auch nur zeitweise am Netz hängt. Namaste
:
Bearbeitet durch User
Das war schon immer so. Nur konnte man früher mal ein einfaches System im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen. Das ist bei den heutigen ständigen Bug-Exploit-Update-Spiralen leider utopisch georden. Wenn man sich da nicht mitdreht, kann das System quasi durch Rumstehen extrem angreifbar werden. Dann passiert sowas wie Stuxnet.
batman schrieb: > Das war schon immer so. Nur konnte man früher mal ein einfaches System > im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen. Das geht auch jetzt noch, wenn das Kämmerlein wirklich geschlossen ist. Also ohne Netzanbindung, ohne alle naselang reinspazierende Leutchen mit USB-Sticks etc.
A. K. schrieb: > batman schrieb: >> Das war schon immer so. Nur konnte man früher mal ein einfaches System >> im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen. > > Das geht auch jetzt noch, wenn das Kämmerlein wirklich geschlossen > ist. Also ohne Netzanbindung, ohne alle naselang reinspazierende > Leutchen mit USB-Sticks etc. Reinspazieren dürfen sie, nur die Stäbchen gehören vor dem Einsatz am Target unter Quarantäne und unters „Mikroskop“ und nie direkt an das Target. Es bedarf eines autarken Filters der die als save eingestuften Daten über einen physisch kontrollierten autarken Boten dem Target übergibt. Wobei für Boten Filter und Mikroskop die selben Kriterien gelten wie fürs Target selbst. Oberste Prämisse muss sein, dass die Chain nicht untertunnelt werden kann, und keine Daten ungefiltert rein noch raus können. Hier können wir von der Stasi lernen: jedes Glied der Überwachungskette muss autark arbeiten, darf nur über relevante Resuorcen und Kontakte verfügen und muss seinerseits unabhängig überwacht werden. Gilt ein Glied als komprommitiert, so ist die gesammte Kette als kompromiitiert zu betrachten. Enigma lehrt: Wiederkehrende Daten dürfen nicht wiederholt übetragen werden. Jeglicher Formalismus schwächt das kryptologische Prinzip. Deshalb sollte die notwendige Redundanz ebenfalls mindestens verschleiert werden. Siehe Wettertelegramm—backdoor.
:
Bearbeitet durch User
Zu Spectre Mitigations und Android: Anders als in Windows, iOS und Linux sollte es in Android eigentlich möglich sein, auch bestehende Anwendungen ohne Updates der Anwendungen teilweise abzusichern. Immerhin werden Anwendungen in Android nicht fertig übersetzt ausgeliefert, sondern in Form von Zwischencode, der erst auf dem Endgerät in Binärcode übersetzt wird. Deshalb sollte es eigentlich möglich sein, bestimmte Mitigations in bereits ausgelieferten Code einzuschleusen, indem man den Übersetzer des Zwischencodes entsprechend anpasst. Also beispielsweise indem die indirekten Sprünge aus Variante 2 nun systematisch durch das ARM Äquivalent von Retpoline implementiert werden. Übersetzer austauschen und alle Apps neu optimieren, wie es bei Firmware-Updates ohnehin geschieht. Klar, das wird bremsen, aber immerhin. Das sollte man dann natürlich adaptiv machen. Wer nur A53er im Gerät stecken hat, braucht das ja nicht. Hat jemand davon schon mal gelesen?
:
Bearbeitet durch User
Und es geht weiter in diesem Sumpf. Heute im Angebot: Intel Disclosed Meltdown Bugs To Chinese Companies Before The US Government https://fossbytes.com/intel-disclosed-meltdown-bugs-to-chinese-companies-before-the-us-government/ Microsoft deaktiviert Spectre-2-Patches für Windows https://www.golem.de/news/ausserordentliches-update-microsoft-deaktiviert-spectre-2-patches-fuer-windows-1801-132431.html
Kaj G. schrieb: > Und es geht weiter in diesem Sumpf. Heute im Angebot: Es gibt doch aber auch Hoffnung :-) https://www.engadget.com/2018/01/26/intel-spectre-meltdown-chips/
Mox schrieb: > Es gibt doch aber auch Hoffnung :-) Für die Anwender oder für Intel? ;-) Das ergibt ein böses Umsatzloch dieses Jahr, weil jeder seine für dieses Jahre geplanten Beschaffungen aufschieben wird, soweit möglich. Dafür werden nächstes Jahr die Fabs heisslaufen.
Irgendwie fehlt mir noch immer so richtig der passende Angriffsplan. Die Ausnutzung der Lücken erfordert ja einige "von hinten durch die Brust ins Auge"-Verrenkungen. Wenn ich das richtig verstanden habe, sind die Entdecker auf Datentransferraten im Bereich einiger kB/s gekommen. Damit wird doch der Zugriff auf irgendwelche Nutzdaten zum reinen Glüksspiel. Abgesehen davon, daß sich der Inhalt von dynamischen Speicher halt doch "ab und an" mal ändert, und man mit der niedrigen Datenrate dann zeitlich verschobene Inhalte erwischt. Mir fehlt dazu allerdings jeder Hintergrund. Daher die Frage an die Experten hier: Was könnte ein Angreifer denn sinnvolles mit den Lücken anstellen? Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Daher die Frage an die Experten hier: Was könnte ein Angreifer denn > sinnvolles mit den Lücken anstellen? Stell dir mal einen grossen Hoster vor, z.B. Amazon oder Google. Kunde A und Kunde B haben jeweils eine eigene VM. Jetzt kann ein Angreifer ueber einen Angriff auf Kunde A, auch die Daten von Kunde B auslesen, z.B. Kryptographische Schluessel (SSL/TLS). Und da so ein Hoster in der Regel mehrere tausend Kunden hat, von privat Personen bis hin zu riesigen Konzernen, sind durch einen Angriff auf einen Kunden, moeglicherweise viele, viele Kunden und Daten kompromitiert. Aber auch fuer privat Anwender: Dadurch, dass sich die Luecke auch ueber JavaScript ausnutzen laesst (sofern der Browser noch nicht gepatched ist, und ja, einige Menschen halten nicht viel von Updates) kann auch da ein Angreifer z.B. Passwoerter auslesen. Einfach das JavaScript in die tollen Werbebanner einschleusen, und fertig. Hier noch mal eine Erklaerung, auch fuer Leute mit wenig technischem Hintergrund, von Radio Fritz rbb mit dem CCC: CR242: Einmal einschmelzen bitte Warum modernes CPU-Design uns jetzt in Teufels Küche bringt https://media.ccc.de/v/cr242
1 | Mit Meltdown und Spectre sind zwei Sicherheitslücken bekannt geworden, |
2 | die sich von traditionellen Problemen unterscheiden, denn sie betreffen |
3 | die CPU, also jene Bausteine, der das Herz eines jeden elektronischen |
4 | Gerätes bilden. Und weil man sie nicht einfach tauschen kann, ist es nun |
5 | an den Betriebssystemherstellern, die Probleme soweit wie möglich |
6 | einzudämmen. Doch noch sind Experten skeptisch, ob diese Maßnahmen |
7 | ausreichen werden. Im Chaosradio 242 werfen wir einen Blick auf die |
8 | aktuelle Situation. Live im Frl. Fritz in Kreuzberg versuchen wir nicht |
9 | nur zu erklären, was sich hinter Meltdown und Spectre verbrigt, sondern |
10 | auch herauszufinden, welche Konsequenzen und Lehren wir aus den Lücken |
11 | ziehen sollten. |
Oliver S. schrieb: > Irgendwie fehlt mir noch immer so richtig der passende Angriffsplan. Ein kleiner Tipp von mir, fuer alle die mit sowas nichts oder nur wenig anfangen koennen: Nur weil Ihr euch keinen Nutzen von solchen Angriffen vorstellen koennt (und nein, man muss nicht immer alles verstehen, dazu ist die Welt der IT zu komplex), heisst das nicht, das andere dafuer keine Anwendung finden. Vielleicht nutzt jemand die Luecke nur zum Spass, um zu sehen was so geht. Andere nutzen das vielleicht um Code einzuschleusen und den Rechner fuer ein Botnet zu uebernehmen. Aber spaetestens die Geheimdienste haben fuer sowas verwendung. Sei es nun um kryptographische Schluessel, Passwoerter, oder sonst was abzugreifen. Oliver S. schrieb: > sind die > Entdecker auf Datentransferraten im Bereich einiger kB/s gekommen. Spielt doch keine Rolle, wenn die Luecke Tage, Wochen, oder Monate offen steht. Es wird gesammelt was geht. Oliver S. schrieb: > Damit wird doch der Zugriff auf irgendwelche Nutzdaten zum reinen > Glüksspiel. Irgendwas sinnvolles wird schon dabei sein. Das reicht. 50% von etwas (egal was es ist) ist mehr als 100% von nichts. Selbst wenn man es nicht schafft, den kompletten kryptographischen Schluessel abzugreifen: Ein kleiner Teil ist schon viel Wert, weil man dann den Bereich fuer einen Brute-Force-Angriff verkleinern kann, oder womoeglich sogar den Restlichen Schluessel berechnen kann.
Kaj G. schrieb: > Vielleicht nutzt jemand die Luecke nur zum Spass, um zu sehen was so > geht. Andere nutzen das vielleicht um Code einzuschleusen und den > Rechner fuer ein Botnet zu uebernehmen. Die Lücken können ja nur zum Lesen ausgenutzt werden, schreiben geht nicht. Und auch wenn da eine Schadsoftware im Hintergrund längerfrsitig mitliest, bekommt die trotzdem nur Daten mit ein paar kB/s ausgelesen. Da dauert das auslesen eines einzigen Megabytes Stunden. Und in der Zeit werden sich die Daten darin so oft geändert haben, daß der ausgelesene Datenblock selber als kryptografischer Einmalschlüssel verwendbar ist, zu mehr aber auch nicht. Wenn man ganz genau weiß, wo man Daten findet, fuktioniert das, aber mal eben den Speicher nach bekannten Daten durchsuchen wird so nicht klappen. Oliver
Oliver S. schrieb: > Wenn man ganz genau weiß, wo man Daten findet, fuktioniert das, aber mal > eben den Speicher nach bekannten Daten durchsuchen wird so nicht > klappen. Früher wusste man, an welcher Stelle im Kernel welche Informationen liegen. Das machte es Angreifern per vorhandenem Leck leicht, Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen zufällig zu verteilen, aka Kernel Address Space Layout Randomization = KASLR. Das wiederum verlangte geradezu zu nach Wegen, per Side Channel Attack diese Adressen rauszufinden. Im Rahmen dieser Thematik fand man nicht nur einen Weg zu den Adressen, sondern auch Meltdown, den Weg zum Inhalt.
:
Bearbeitet durch User
Naja dem Meltdown-Prozeß muß man schon eine Menge Zeit geben, wie ich das sehe und der kann auch nicht mal am nächsten Tag weitermachen, wenn der User den Rechner abgeschaltet hat. Wenn man den Browser beendet, sind die besonders gefährlichen Javascripte schon tot. Einen aussichtsreichen Angriffsplan auf heimische PCs will ich sehen.
dafür hat der patch auf dem arbeits PC für spontanes herunterfahren gesorgt :D am 22. kam der patch ... und ich hatte mich gewundert warum das ding nach der mittagspause aus war patch deinstalliert , alles wieder gut
Tja, keine wirksame Medizin ohne Nebenwirkung nech. :)
Hallo Paul! Paul B. schrieb: > Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann > ich damit nichts. Wenn Du die Intel-Liste mit der Liste in dem folgenden Link abgleichst, kannst Du feststellen, dass Dein Core 2 Duo E8400 nicht auf der Intel-Liste steht. https://en.wikipedia.org/wiki/Intel_Core Allerdings besagt die Intel-Liste aber auch nicht, dass alle anderen Prozessoren nicht betroffen sind. Es bleibt also beim JEIN.
Kaj G. schrieb: > Oliver S. schrieb: >> Daher die Frage an die Experten hier: Was könnte ein Angreifer denn >> sinnvolles mit den Lücken anstellen? > Stell dir mal einen grossen Hoster vor, z.B. Amazon oder Google. > Kunde A und Kunde B haben jeweils eine eigene VM. > Jetzt kann ein Angreifer ueber einen Angriff auf Kunde A, auch die Daten > von Kunde B auslesen, z.B. Kryptographische Schluessel (SSL/TLS). > Und da so ein Hoster in der Regel mehrere tausend Kunden hat, von privat > Personen bis hin zu riesigen Konzernen, sind durch einen Angriff auf > einen Kunden, moeglicherweise viele, viele Kunden und Daten > kompromitiert. A. K. schrieb: > Früher wusste man, an welcher Stelle im Kernel welche Informationen > liegen. Das machte es Angreifern per vorhandenem Leck leicht, > Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen > zufällig zu verteilen, aka Kernel Address Space Layout Randomization = > KASLR. findet man dann auch in einer akzeptablen Zeit heraus, wo man suchen muss? Ich mein', wenn man die Daten gefühltermassen "telexen" lassen muss, um zu sehen was da steht und man dann auch noch tausende male ins Blaue schiessen muss um was interessantes zu finden? andererseits: Arbeitslose Nerds mit genügend Zeit gibts genug.
● J-A V. schrieb: > findet man dann auch in einer akzeptablen Zeit heraus, > wo man suchen muss? Keine Ahnung, ich bin kein Hacker. Ich würde aber rein vorsorglich davon ausgehen, dass es mit vertretbarem Aufwand möglich ist, das zu finden wonach man sucht. > andererseits: Arbeitslose Nerds mit genügend Zeit gibts genug. Träumst du nachts von Gigabytes an Hexdumps statt von Schafen? Gute Nerds suchen nicht selbst, sondern lassen suchen. Arbeitslose Rechner. Indem sie Programme dafür bauen.
:
Bearbeitet durch User
Peter M. schrieb: > Allerdings besagt die Intel-Liste aber auch nicht, dass alle anderen > Prozessoren nicht betroffen sind. > > Es bleibt also beim JEIN. Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben kann. Dieser gezeigte Vierzeiler in Assembler müßte doch so ähnlich auf allen Systemen laufen, zumindest als Test für Meltdown?
Oliver S. schrieb: > Unter Windows vielleicht mit dem Tool von Microsoft: > > https://www.heise.de/tipps-tricks/Prozessor-Sicherheitsluecke-So-findest-du-heraus-ob-du-gegen-Meltdown-und-Spectre-geschuetzt-bist-3937717.html Oliver
Da wird nur auf Windows-Patches geprüft. Die grundsätzliche Verwundbarkeit des jeweiligen Prozessors ist eine andere Frage.
batman schrieb: > Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben > kann. Kommt drauf an von wem du diese Aussage haben willst. (1) Testprogramm. Nicht trivial, da das Training des Branch Predictors abhängig von dessen Implementierung sein kann. Eine Positivauskunft (betroffen) wird sich ableiten lassen, eine Negativauskunft (nicht betroffen) eher nicht. (2) Für Spectre 1 und 2 steht die Aussage um Raum, dass diese Lücke eine Folge des Arbeitsprinzips ist, und somit alle OOO Prozessoren betroffen sein sollten (plus POWER6). Das wäre bei Intel fast alles ab Pentium Pro. (3) Will man sich bei Intel als autoritativer Quelle informieren, dann ist man auf das entsprechende Dokument angewiesen, aus dem sich für dort nicht explizit aufgeführte Prozessoren nichts ableiten lässt. Ergo: Die Aussage "ist betroffen" lässt sich leichter treffen als die gegenteilige Aussage. Und dann könnte es noch Grauwerte geben, etwa "prinzipiell betroffen, aber praktisch nicht ausnutzbar".
:
Bearbeitet durch User
batman schrieb: > Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben > kann. Dieser gezeigte Vierzeiler in Assembler müßte doch so ähnlich auf > allen Systemen laufen, zumindest als Test für Meltdown? Folgende Szenarien sind denkbar: 1. Sie wollen nicht. Sie sehen die Altsysteme als veraltet und überholt an, verweisen auf die durchschnittliche Lebenszeit von Rechnern im Unternehmen und wollen keinen Ressourcen auf die Altsysteme verschwenden. 2. Sie können nicht. Ihnen fehlt ein Testzentrum mit Althardware, auf der sie Exploits testen können. 3. Rechtliche Konsequenzen: Sie wollen keine Einschätzung abgeben. Sie haben Angst vor Klagen. Eine ehrliche Aussage der Form: Wir schätzen die Wahrscheinlichkeit der Ausnutzbarkeit auf einem Core 2 Duo E8400 auf 1% oder geringer könnte sie bei Beweis des Gegenteils viel Geld kosten.
Microsoft stuft das PoC-Programm zu Spectre als bösartig ein https://www.heise.de/security/meldung/Microsoft-stuft-das-PoC-Programm-zu-Spectre-als-boesartig-ein-3959995.html
1 | Wer auch immer die Strings "Squeamish Ossifrage" oder "malicious_x = %p" |
2 | in seinem Programm verwendet, darf sich seit Neuestem nicht wundern, |
3 | dass Microsoft ihn oder sie als Schädlingsprogrammierer einstuft. |
4 | ... |
5 | Schon beim Erstellen eines Programms in Visual Studio gibt es eine |
6 | Fehlermeldung und der Defender blendet sich mit "Bedrohung gefunden" |
7 | ein, ohne diese weiter aufzuschlüsseln. |
IPS/Firewalls sind auch schon rührig. Hauptsächlich wird so der Eindruck erweckt, Virenscanner und IPS seien nicht völlig nutzlos.
:
Bearbeitet durch User
A. K. schrieb: > Gute > Nerds suchen nicht selbst, sondern lassen suchen. Arbeitslose Rechner. > Indem sie Programme dafür bauen. die einem dann endlich sagen, von wem die Daten stammen? BTW meine Träume sind nicht jugendfrei, das kann ich hier nicht schreiben ;)
first: Aluhut aufsetz. Der Witz ist doch, dass mit der Patcherei eine Sicherheit propagiert wird, welche de facto weder existiert noch herstellbar ist, solange man diese HW zusammen Software von nicht zertifizierten Herstellern nutzten will. Und auch bei den Zertifikaten wie beim OS ist es eher wie mit Geld: Die Vertrauenswürdigkeit ist um so stärker zu relativieren je höher der Sicherheitsanspruch ausfällt. Und das war noch immer eine Preis-Leistungs-Abwägung. Wobei die Qualität des nun publikumswirksam aufgeführten Theaters eher in dem vorgeblich "ewig" unentdeckten Aspekt liegt, denn in seiner schieren Existenz. Vielmehr erscheint es mir als wolle man unvorbereitet und überhastet eine Backdoor schließen, deren Aufdeckung man nicht so bald erwartet hatte und welche sich für die Verursacher zum Boomerang zu entwickeln droht. Die Frage ist ob sie wirklich ungewollt auf Grund ökonomisch-technologischer Aspekte entstand und billigend genutzt wurde, wobei das ob für mich außer Frage steht, oder ob sie vielmehr gezielt schon in der Entwicklung nicht geschlossen wurde. Die zufällige Entdeckung durch verschiedene Teams nach einer initialen Mutmaßung einer Einzelperson halte ich für eine Legende, welche leicht zu implizieren war. last: Aluhut ab Namaste
:
Bearbeitet durch User
● J-A V. schrieb: > A. K. schrieb: >> Früher wusste man, an welcher Stelle im Kernel welche Informationen >> liegen. Das machte es Angreifern per vorhandenem Leck leicht, >> Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen >> zufällig zu verteilen, aka Kernel Address Space Layout Randomization = >> KASLR. > > findet man dann auch in einer akzeptablen Zeit heraus, > wo man suchen muss? > Ich mein', wenn man die Daten gefühltermassen "telexen" lassen muss, > um zu sehen was da steht und man dann auch noch tausende male ins Blaue > schiessen muss um was interessantes zu finden? KASLR (Linux und Windows) ist ein Witz. Wenn der Prozessor TSX (Transactional Synchronization Extensions) unterstützt, geht's innerhalb von Millisekunden und man hat die "randomisierte" Basisadresse: https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf 5 ms unter Linux (i7-6700K) für die Basisadresse, etwa 0.5 Sekunden für Kernel und alle Module. Allerdings hilft dagegen KPTI/KAISER... https://gruss.cc/files/kaiser.pdf
MeltdownPrime & SpectrePrime: Neue Software automatisiert CPU-Angriffe https://www.heise.de/security/meldung/MeltdownPrime-SpectrePrime-Neue-Software-automatisiert-CPU-Angriffe-3970686.html MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols https://arxiv.org/pdf/1802.03802.pdf
Kaj G. schrieb: > MeltdownPrime & SpectrePrime: Neue Software automatisiert CPU-Angriffe > https://www.heise.de/security/meldung/MeltdownPrime-SpectrePrime-Neue-Software-automatisiert-CPU-Angriffe-3970686.html > > > MeltdownPrime and SpectrePrime: > Automatically-Synthesized Attacks Exploiting > Invalidation-Based Coherence Protocols > https://arxiv.org/pdf/1802.03802.pdf Wer keine Lust hat den Artikeln und/oder das Paper zu lesen: "Given our observations with mfence and lfence successfully mitigating Spectre and SpectrePrime in our experiments, we believe that any software techniques that mitigate Meltdown and Spectre will also be sufficient to mitigate MeltdownPrime and SpectrePrime. On the other hand, we believe that microarchitectural mitigation of our Prime variants will require new considerations. Where Meltdown and Spectre arise by polluting the cache during speculation, MeltdownPrime and SpectrePrime are caused by write requests being sent out speculatively in a system that uses an invalidation-based coherence protocol."
Beitrag #5317516 wurde von einem Moderator gelöscht.
Na also, so langsam wird's doch. :-) https://www.itproportal.com/news/intel-claims-it-may-finally-have-fixed-spectre-flaw/
Mal was neues: Angriff auf SGX-Enklaven 1) mit Spectre. Es helfen nur Microcode-Updates, Retpoline alleine reicht nicht. https://arxiv.org/pdf/1802.09085.pdf 1) "Intel SGX is a set of central processing unit (CPU) instruction codes from Intel that allows user-level code to allocate private regions of memory, called enclaves, that are protected from processes running at higher privilege levels." https://en.wikipedia.org/wiki/Software_Guard_Extensions
Es kann und darf nicht sein, dass Linux-Anwender besser dran sind als Windows-Anwender. Und so installiert nun auch Windows Microcode-Patches: https://www.golem.de/news/windows-catalog-microsoft-verteilt-kuenftig-selbst-spectre-patches-1803-133093.html
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. Welche denn? Oder sind die noch in der Entwicklung? Hier ein Auszug von mir von /prog/cpuinfo (i5-3570k): bugs : cpu_meltdown spectre_v1 spectre_v2 bogomips : 6784.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual Gaaanz toll ;-)
:
Bearbeitet durch User
Pete K. schrieb: > Welche denn? Oder sind die noch in der Entwicklung? > > Hier ein Auszug von mir von /prog/cpuinfo (i5-3570k): Da wunderst du dich? Das ist ja noch die dritte Core-i-Generation aus dem Jahr 2012. Gerade kommen die ersten Rechner mit der achten Generation raus. Interessant wäre, ob die schon einen Hardware-Fix enthalten, aber ich vermute mal nicht.
Rolf M. schrieb: > Interessant wäre, ob die schon einen Hardware-Fix > enthalten, aber ich vermute mal nicht. Mit Glück haben die bereits den vorläufig richtigen Microcode.
A. K. schrieb: > vorläufig richtigen Die Betonung sollte hier auf dem 1 Adjektiv liegen ;) aja, an alle Saftyjünger unter euch, gerade haben die höchsten Stellen für Computersicherheit in der BRD eingeräumt das 100% sichere Computersystem eine Utopie sind und bleiben. Gleichzeitig sehen sie sich wohl zur Beruhigung der aufgebrachten Abgeordneten gezwungen öffentlich zu verkünden sie hätten alles unter Kontrolle und führten die unbekannten "Hacker" am Ring durch die Manege, um sie zu lokalisieren. Da möchte man doch Kabarettist werden, mit solchen Steilvorlagen, obwohl das wäre zu leicht. Namaste
Winfried J. schrieb: > aja, an alle Saftyjünger unter euch, gerade haben die höchsten Stellen > für Computersicherheit in der BRD eingeräumt das 100% sichere > Computersystem eine Utopie sind und bleiben. ... und in China ist vorhin ein Sack Reis umgefallen.
A. K. schrieb: > vorhin ein Sack Reis umgefallen. schon wieder? Ich hatte Ihnen erst letzten Monat ein Zertifizierung angeboten, um dies zukünftig zu vermeiden. Aber auf mich hört ja keiner. Resignierend den Kopf mit dem schütteren Haar schüttelnd.--> ab Namaste
Winfried J. schrieb: > und führten die > unbekannten "Hacker" am Ring durch die Manege, um sie zu lokalisieren. Übst du schon fürs Kabarett? Denn ... > Da möchte man doch Kabarettist werden, mit solchen Steilvorlagen, obwohl > das wäre zu leicht. ... einen noch nicht lokalisierten Hacker am Ring rumzuführen ist schon ein recht bizarres Bild. ;-)
Ich habe nur zusammengefasst, vertönt wurde das auf der Pressekonferenz gestern im Anschluss an eine Sitzung des Parlamentarischen Kontrollgremiums des Bundestages. Leider finde ich die gesamte Pressekonferenz nicht wieder. Aber es war schon eine Sternstunde. rudimente davon finden sich im ersten Beitrag allerdings haben sie die Extrapossen da weggelassen. http://mediathek.daserste.de/Tagesschau/tagesschau-20-00-Uhr/Video?bcastId=4326&documentId=50493528 Namaste
:
Bearbeitet durch User
Arc N. schrieb: > Mal was neues: Angriff auf SGX-Enklaven 1) mit Spectre. Es helfen nur > Microcode-Updates, Retpoline alleine reicht nicht. Jetzt auch bei Golem: Spectre-Angriff kann Intel SGX überwinden https://www.golem.de/news/sgxpectre-spectre-angriff-kann-intel-sgx-ueberwinden-1803-133209.html
Spectre v2: Linux- und Windows-Updates für Intel-Chips verfügbar https://www.golem.de/news/spectre-v2-linux-und-windows-updates-fuer-intel-chips-verfuegbar-1803-133336.html
1 | Das KB4090007 genannte Update für Windows 10 v1709 (Fall Creator's Update) |
2 | und Windows Server v1709 enthält Microcode, um Intel-CPUs ab der Skylake- |
3 | Generation gegen Spectre v2 zu patchen. Das Update muss manuell |
4 | heruntergeladen und installiert werden. Gedacht ist es für aktuelle und |
5 | bis zu drei Jahre alte Prozessoren. Es werden Skylake (6th Gen Core), |
6 | Kaby Lake (7th/8th Gen Core) und Coffee Lake (8th Gen Core) als Client- |
7 | Version unterstützt, hinzu kommen Server-Ableger wie Skylake-SP (Xeon SP), |
8 | Skylake-D (Xeon D) und die noch nicht veröffentlichten Xeon E3 auf Basis |
9 | von Coffee Lake. |
10 | |
11 | Auch für Linux verteilt Intel inzwischen ein aktualisiertes Firmware-Paket |
12 | mit den Microcode-Updates. Die Updates sind wie für die OEM-Partner für |
13 | CPUs ab der Sandy-Bridge-Generation verfügbar. |
Immerhin gibts nun auch BIOS Updates mit Microcode bis zurück zu Sandy Bridge, z.B. von HP und Lenovo.
Spectre und Meltdown: Intel-Prozessoren mit vollem Hardwareschutz bereits 2018 https://www.heise.de/security/meldung/Spectre-und-Meltdown-Intel-Prozessoren-mit-vollem-Hardwareschutz-bereits-2018-3995993.html
1 | Die kommenden Intel-Prozessoren der Xeon-Serie Cascade Lake sowie neue |
2 | Core-i-8000-Prozessoren sollen Änderungen der Mikroarchitektur enthalten, |
3 | die vor den Spectre-Angriffsszenarien schützen. |
4 | |
5 | Der Prozessorhersteller Intel hat das Hardware-Design kommender |
6 | Hautprozessoren geändert, um sie gegen die Angriffsszenarien Spectre 2 |
7 | und Meltdown zu schützen. Dies hat Intel auf seiner Website bekannt |
8 | gegeben. Man habe Teile des Prozessors umgestaltet, um neue Schutzstufen |
9 | durch Partitionierung einzuführen, die sowohl gegen Spectre Variante 2 |
10 | (BTI, CVE-2017-5715) als auch gegen Variante 3 (Meltdown, Rogue Data |
11 | Cache Load, CVE-2017-5754) schützen. |
Drum sind bei uns Invests in neue PCs und Server aufgeschoben. War eigentlich vorgesehen.
:
Bearbeitet durch User
Kaj G. schrieb: > Der Prozessorhersteller Intel hat das Hardware-Design kommender > Hautprozessoren geändert, um sie gegen die Angriffsszenarien Spectre 2 > und Meltdown zu schützen. Ah, da war wohl der Zeitpunkt der Veröffentlichung doch ein PR-Push um die neuen am Markt zu etablieren? Namaste
Winfried J. schrieb: > Ah, da war wohl der Zeitpunkt der Veröffentlichung doch ein PR-Push um > die neuen am Markt zu etablieren? Gut möglich. Da heisst es einfach abwarten und sehen, was dabei rauskommt. Intel muss natürlich die Leute bei Laune halten, damit die Kundschaft nicht zu sehr abwartet oder gar auf AMD umsteigt. War da nicht grad auch was? Honi soit qui mal y pense ;-).
:
Bearbeitet durch User
A. K. schrieb: > Winfried J. schrieb: >> Ah, da war wohl der Zeitpunkt der Veröffentlichung doch ein PR-Push um >> die neuen am Markt zu etablieren? > > Gut möglich. Da heisst es einfach abwarten und sehen, was dabei > rauskommt. > > Intel muss natürlich die Leute bei Laune halten, damit die Kundschaft > nicht zu sehr abwartet oder gar auf AMD umsteigt. War da nicht grad auch > was? Honi soit qui mal y pense ;-). Ja, da ist sogar was, was auch Intel bzw. div. Chipsätze betrifft. Allerdings ist Root-Zugriff nötig, um es ausnutzen zu können. https://www.heise.de/security/meldung/Hintertueren-in-USB-Controllern-auch-in-Intel-Systemen-vermutet-3996868.html Überraschen sollten die Fehler in AMDs PSP allerdings nicht: TEE/TrustZone https://media.ccc.de/v/34c3-8950-microarchitectural_attacks_on_trusted_execution_environments https://googleprojectzero.blogspot.de/2017/07/trust-issues-exploiting-trustzone-tees.html
:
Bearbeitet durch User
A. K. schrieb: > Intel muss natürlich die Leute bei Laune halten, damit die Kundschaft > nicht zu sehr abwartet oder gar auf AMD umsteigt. AMD ist eben wohl auch keine so gute Idee: https://www.crn.com/news/security/300100596/spectre-meltdown-part-two-research-firm-audit-reveals-critical-flaws-backdoors-in-four-amd-processors.htm
René K. schrieb: > AMD ist eben wohl auch keine so gute Idee: > https://www.crn.com/news/security/300100596/spectre-meltdown-part-two-research-firm-audit-reveals-critical-flaws-backdoors-in-four-amd-processors.htm Das ist reine Sensationspresse. Das ist alles nichts neues und nichts allzu gravierendes. Was CTS da geboten hat ist reines Marketing mit dem einzigen Zweck AMD zu schaden. Die haben schon Wochen davor Webseiten und Logos gestaltet, danach die Presse schon mal vorinformiert bevor man AMD was sagt: https://www.anandtech.com/show/12525/security-researchers-publish-ryzen-flaws-gave-amd-24-hours-to-respond http://www.zdnet.com/article/linus-torvalds-slams-cts-labs-over-amd-vulnerability-report/ Und das ist nur eine kleine Auswahl der Links dazu.
:
Bearbeitet durch User
Daniel A. schrieb: > René K. schrieb: >> AMD ist eben wohl auch keine so gute Idee: >> > https://www.crn.com/news/security/300100596/spectre-meltdown-part-two-research-firm-audit-reveals-critical-flaws-backdoors-in-four-amd-processors.htm > > Das ist reine Sensationspresse. Das ist alles nichts neues und nichts > allzu gravierendes. Was CTS da geboten hat ist reines Marketing mit dem > einzigen Zweck AMD zu schaden. Die haben schon Wochen davor Webseiten > und Logos gestaltet, danach die Presse schon mal vorinformiert bevor man > AMD was sagt: ... > Und das ist nur eine kleine Auswahl der Links dazu. AMD hat die Lücken bestätigt und zwar alle... Patches sind unterwegs. https://www.heise.de/newsticker/meldung/Ryzenfall-Fallout-Co-AMD-bestaetigt-Sicherheitsluecken-in-Ryzen-und-Eypc-Prozessoren-4000040.html Zum Ausnutzen braucht ein Angreifer zwingend Root-/Adminrechte...
Und die nächste Technik, die die Eigenschaften spekulativer Ausführung bzw. der Sprungvorhersage ausnutzt, um Angriffe (u.a. gegen Intels SGX) ausführen zu können: BranchScope http://www.cs.ucr.edu/~nael/pubs/asplos18.pdf https://arstechnica.com/gadgets/2018/03/its-not-just-spectre-researchers-reveal-more-branch-prediction-attacks/
Microsoft hat es mal wieder verkackt: Kernel-Lücke Total Meltdown: Meltdown-Patch für Windows 7 verschlimmert die Lage dramatisch https://www.heise.de/security/meldung/Kernel-Luecke-Total-Meltdown-Meltdown-Patch-fuer-Windows-7-verschlimmert-die-Lage-dramatisch-4006862.html
1 | Aufgrund der Verwundbarkeit soll jeder Prozess – auch ohne Admin-Rechte – |
2 | den kompletten Inhalt des Kernelspeichers mit sehr hoher Geschwindigkeit |
3 | auslesen können. Es kommt aber noch schlimmer: Bei einer erfolgreichen |
4 | Attacke ist sogar Schreibzugriff auf den Kernel gegeben, führt Frisk aus. |
5 | So könnten Angreifer beispielsweise via Malware Informationen aus dem RAM |
6 | auslesen und manipulieren und im Endeffekt das komplette System |
7 | kompromittieren. |
8 | |
9 | ... |
10 | |
11 | Das liegt daran, dass die Meltdown-Patches die Erlaubnis für den Zugriff |
12 | auf PSML4 Page Tables für alle Nutzer und Prozesse freigegeben haben. |
13 | Darauf darf eigentlich nur der Kernel selbst zugreifen. |
Tja Sicherheit ist wie Lottoglück. Greifst du nach ihnen sind sie fort. ;) Was wohl der Heisenberg dazu sagte? Namaste
Es gibt mal wieder eine neue Liste von Intel. https://www.golem.de/news/spectre-v2-intel-liefert-keinen-microcode-fuer-core-2-duo-quad-1804-133657.html Paul B. schrieb: > Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von > diesem Problem betroffen ist? Betroffen ja, Microcode-Entwicklung wurde aber eingestellt.
:
Bearbeitet durch User
Winfried J. schrieb: > gerade haben die höchsten Stellen > für Computersicherheit in der BRD eingeräumt das 100% sichere > Computersystem eine Utopie sind und bleiben. Nein? Doch! Ohhh... Ja, 100% sichere Computersysteme sind genau so Utopie wie alles andere was damit wirbt, 100% sicher zu sein (inklusive Aufzügen). Merkregel: Sicher ist nur der Tod. Jeder, der sich ernsthaft mit der Thematik beschäftigt (das meinst du wohl mit "Safetyjünger", weiß das).
vn nn schrieb: > Winfried J. schrieb: >> gerade haben die höchsten Stellen >> für Computersicherheit in der BRD eingeräumt das 100% sichere >> Computersystem eine Utopie sind und bleiben. > > Nein? Doch! Ohhh... > > Ja, 100% sichere Computersysteme sind genau so Utopie wie alles andere > was damit wirbt, 100% sicher zu sein (inklusive Aufzügen). Ja. Auch die Titanic galt als unsinkbar - allerdings nicht sehr lange. "Absolut sichere" Dinge sind ungefähr so sicher, wie "umweltfreundliche" Dinge freundlich zur Umwelt sind.
:
Bearbeitet durch User
Spectre-NG: Intel-Prozessoren von neuen hochriskanten Sicherheitslücken betroffen https://www.heise.de/security/meldung/Spectre-NG-Intel-Prozessoren-von-neuen-hochriskanten-Sicherheitsluecken-betroffen-4039302.html
1 | Intel-Prozessoren enthalten acht weitere, bisher unbekannte |
2 | Sicherheitslücken, von denen manche wesentlich gravierender |
3 | ausfallen als Meltdown und Spectre. |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.