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?
Beitrag #5266513 wurde vom Autor gelöscht.
Wer es mal selbst ausprobieren möchte: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6
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.
Michael R. schrieb: > Virtualisierung ist anfällig Aus dieser Ecke fand bisher allenfalls heisse Luft. Hast du mehr dazu?
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.
Beitrag #5266534 wurde vom Autor gelöscht.
Apple says Meltdown and Spectre flaws affect ‘all Mac systems and iOS devices,’ but not for long https://techcrunch.com/2018/01/04/apple-says-meltdown-and-spectre-flaws-affect-all-mac-systems-and-ios-devices-but-not-for-long/
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 |
17 | cache side-channel attacks. |
Microsoft Security Bulletin Summary For January, 2018 https://packetstormsecurity.com/files/145668 https://portal.msrc.microsoft.com/en-us/security-guidance
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.
:
Bearbeitet durch User
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...
Angehängte Dateien:
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
DLF_weiss_mehr_als_wir.png
650 KB
Icke ®. schrieb: > 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... Ist vom seriösen Qualitätsjournalismus bereits angekündigt: http://www.deutschlandfunk.de/sicherheitsluecken-in-computer-chips-der-grosse-crash-kommt.720.de.html?dram:article_id=407558 " .. Also, weitermachen, abwarten und hoffen - bis zum wirklichen Crash. Und der kommt - bei diesem Sicherheitsverständnis - todsicher." Da hilft nur.. ..warten auf den Untergang!
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Whitepaper von ARM: https://t.co/r6UCo3m0Cl
1 | Introduction |
2 | |
3 | This whitepaper looks at the susceptibility of Arm implementations |
4 | following recent research findings from security researchers at Google |
5 | on new potential cache timing side-channels exploiting processor |
6 | speculation. This paper also outlines possible mitigations that can be |
7 | employed for software designed to run on existing Arm processors. |
1 | LLVM Weekly @llvmweekly |
2 | |
3 | Patches posted for LLVM and Clang providing __builtin_load_no_speculate |
4 | and the llvm.nospeculateload intrinsic as a way of neutering potential |
5 | Spectre gadgets. |
https://reviews.llvm.org/D41760 https://reviews.llvm.org/D41761
1 | Windows Meltdown patch: Find out if your PC is compatible |
2 | |
3 | A list of which anti-virus products are incompatible with |
4 | the patch against the CPU flaws is now available. |
https://www.techrepublic.com/article/windows-meltdown-patch-find-out-if-your-pc-is-compatible/
Beitrag #5266965 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
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).
Mal eine dumme Frage ... Wenn unter Linux der gesamte Physikalische Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch überhaupt?
Mampf F. schrieb: > Mal eine dumme Frage ... Wenn unter Linux der gesamte Physikalische > Speicher ausgelesen werden kann, Wie? Also als normaler User.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Spectre und Meltdown: 90 Prozent der aktuellen Intel-CPUs werden gepatcht https://www.golem.de/news/spectre-und-meltdown-90-prozent-der-aktuellen-intel-cpus-werden-gepatcht-1801-131981.html
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.
Carl D. schrieb: > Aber für sowas sollten eigentlich keine > PC-Komponenten, sondern Mainframes benutzt werden, Die kochen auch nur mit Wasser. Übersicht über deren internen Aufbau: https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/3dff8d34-fcf9-4939-9efc-11f15a3ce0f8/media/IBM%20z%20Systems%20Processor%20Optimization%20Primer.pdf Seit 2010: "Z196 introduces the first generation out of order pipeline design". Gleiche Lösung, grundsätzlich gleiches Problem.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Mit runden Prozessoren wäre das alles nicht passiert: http://rebrn.com/re/aussehen-vor-sicherheit-eine-maxime-des-chipdesigns-3920519/
Nach dem Patch fuer clang/llvm Beitrag "Re: Schwere Sicherheitslücke in Intelprozessoren?" gibt es jetzt auch einen Patch fuer gcc: [PATCH 0/3] Add __builtin_load_no_speculate https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00205.html
Sa R. schrieb: > wo bitte? hab auch Dell... Dell: http://www.dell.com/support/article/ie/en/iebsdt1/sln308237/dell-client-statement-on-intel-me-txe-advisory--intel-sa-00086-?lang=en Lenovo: https://support.lenovo.com/ie/en/product_security/len-17297 ==================================== Intel Test-programm https://downloadcenter.intel.com/download/27150 ===================================== Hab heute das Windows 10 Patch installiert (8 Jahre alter Lappy).Konnte keine merkliche Geschwindigkeitseinbusse feststellen.
Toxic schrieb: > Intel Test-programm Der Vollständigkdeit halber: Da geht es um das Intel ME Problem. Nicht ums das Problem vom Thread.
:
Bearbeitet durch User
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.
Angehängte Dateien:
Ich musste schon sehr lachen :D
Luca E. schrieb: > Mit runden Prozessoren wäre das alles nicht passiert: > http://rebrn.com/re/aussehen-vor-sicherheit-eine-maxime-des-chipdesigns-3920519/ Bald gibt es dann wohl bei Prozessoren mit gutem Design ein Glasfenster ;-)
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #5267552 wurde von einem Moderator gelöscht.
Beitrag #5267554 wurde von einem Moderator gelöscht.
Beitrag #5267571 wurde von einem Moderator gelöscht.
Beitrag #5267574 wurde von einem Moderator gelöscht.
Stiller ist aus der Rente zurück und hat was zu Meltdown und Spectre geschrieben: https://www.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html
Prozessorlücke: Auch Qualcomm-CPUs sind anfällig https://www.heise.de/newsticker/meldung/Prozessorluecke-Auch-Qualcomm-CPUs-sind-anfaellig-3935270.html
1 | Qualcomm hat bestätigt, das zumindest einige seiner Snapdragon-Chips, |
2 | wie sie in einer Vielzahl von Smartphones zum Einsatz kommen, ebenfalls |
3 | für Spectre- und teils auch für Meltdown-Angriffe anfällig sind. |
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. ;-)
Nö, der liegt grad unter der Glaskugel und sucht nach der witzigen Stelle in deinem Post. ;) Namaste
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
:
Bearbeitet durch User
Billiger Kommentator schrieb: > Aber Spekulationen haben noch nie viel gebracht... Spekulatius ist mir lieber und noch von Weihnachten übrig. MfG Paul
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. ;-)
:
Bearbeitet durch User
Beitrag #5268693 wurde von einem Moderator gelöscht.
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/949361495468642304 https://twitter.com/cperciva/status/949216126331887616
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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."
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Winfried J. schrieb: > Schon vergessen? Wer mit dem Teufel speist braucht einen langen Löffel. In der Betriebskantine der NSA muss es lustig aussehen. ;-)
+1 von mir. Ja, nicht nur dort in dieser Kantine. Anders bei den Opfern aller Seiten. Namaste
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
:
Bearbeitet durch User
Will sagen, was öffentlich gemacht wird ist für den MIK verbrannte Technik. Namaste
Winfried J. schrieb: > Costum Prozessoren Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching verkleide. SCNR
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 :)
Raspberry Pi sind nicht betroffen? Alle modelle? Coole sache. Wird wohl doch zeit sich Zwei, Drei mehr von anzuschaffen.
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.
Beitrag #5271623 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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 Spectre Seuftz ... 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....
Ich hab hier ein Crosscall Odyssey+ IP68 http://mobiloscope.net/en/hardware/smartphones/2014/Crosscall-Odyssey-Plus.html Qualcomm Snapdragon 200 MSM8212 vier ARM Cortex-A7 Kerne Mal sehen was passiert. Namaste
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.
:
Bearbeitet durch User
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.html http://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.
Wenigstens beim Telefon brauche ich nichts zu befürchten wegen der Sache: https://de.wikipedia.org/wiki/Nokia_3210 ;-D
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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"
Veraltet. https://www.vmware.com/security/advisories/VMSA-2018-0004.html https://kb.vmware.com/s/article/52245 https://kb.vmware.com/s/article/52085
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.pdf https://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 :)
:
Bearbeitet durch User
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. https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1742364
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.
:
Bearbeitet durch User
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.
Matthias S. schrieb: > Das scheint zu klappen, aber man sollte es z.B. > in rc.local zünden. Oder man laesst es einfach den Bootloader machen: https://wiki.archlinux.org/index.php/Microcode#Installation
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. |
Beim ueberpreufen
1 | $ dmesg | grep microcode |
2 | [ 0.917300] microcode: CPU0: patch_level=0x06000803 |
3 | [ 0.917306] microcode: CPU1: patch_level=0x06000803 |
4 | [ 0.917310] microcode: CPU2: patch_level=0x06000803 |
5 | [ 0.917317] microcode: CPU3: patch_level=0x06000803 |
6 | [ 0.917325] microcode: CPU4: patch_level=0x06000803 |
7 | [ 0.917332] microcode: CPU5: patch_level=0x06000803 |
8 | [ 0.917340] microcode: CPU6: patch_level=0x06000803 |
9 | [ 0.917348] microcode: CPU7: patch_level=0x06000803 |
10 | [ 0.917381] microcode: Microcode Update Driver: v2.2. |
11 | [ 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_boot Mampf 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
:
Bearbeitet durch User
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 |
6 | ME-Funktionen durch einen Linux-Kernel. |
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ..
Kaj G. schrieb: > https://www.heise.de/newsticker/meldung/Hacker-dringt-weiter-in-Intels-Management-Engine-vor-3884928.html "dabei hatten sie den zuvor undokumentierten "ME-Ausschalter" gefunden, den Intel unter anderem auf Wunsch des US-Geheimdienstes NSA für dessen eigene Rechner einbaute, aber nicht offiziell unterstützt." Winfried, das ist was für dich. ;-)
:
Bearbeitet durch User
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 https://www.heise.de/newsticker/meldung/AMD-Secure-Processor-PSP-wohl-bei-einigen-Ryzen-Mainboards-abschaltbar-3913635.html oder einfach etwas von System 76 US-Amerikanisches Linux-Haus baut Systeme mit deaktivierter Intel-ME https://www.heise.de/newsticker/meldung/US-Amerikanisches-Linux-Haus-baut-Systeme-mit-deaktivierter-Intel-ME-3907151.html
1 | Um Bedenken seiner Kunden wegen möglicher Sicherheitslücken oder Backdoors |
2 | auszuräumen, stellt der amerikanische Anbieter von Linux-Komplettsystemen |
3 | System 76 ein Firmware-Update bereit, das die Intel Management Engine |
4 | deaktiviert. Möglich macht dies das sogenannte HAP-Bit, das einen Betrieb |
5 | als High Assurance Platform einleitet – und auf Betreiben der |
6 | Sicherheitsdienste Eingang in den Code gefunden haben soll. |
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:
1 | OCP boot time: 8 minutes -> 17 seconds |
Hier gibt es noch mehr Informationen: https://firmwaresecurity.com/2017/10/02/more-on-google-nerf/
1 | Google NERF looks interesting, they keep UEFI’s PI but replace the |
2 | UEFI layers with Linux kernel, and the code is written in Go. |
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
Intel-Benchmarks zu Meltdown/Spectre: Performance sackt um bis zu 10 Prozent ab, SSD-I/O deutlich mehr https://www.heise.de/newsticker/meldung/Intel-Benchmarks-zu-Meltdown-Spectre-Performance-sackt-um-bis-zu-10-Prozent-ab-SSD-I-O-deutlich-mehr-3938747.html
1 | Die Leistungsfähigkeit aktueller Intel-Prozessoren kann sich laut Intel |
2 | nach dem Einspielen von Sicherheitspatches um bis zu 10 Prozent verringern, |
3 | in Spezialfällen fällt der Performance-Verlust sogar noch höher aus. |
4 | Besonders betroffen: SSD-Systeme. |
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.
:
Bearbeitet durch User
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. |
Ist ja auch nur ein Einbruch von knapp 50%...
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. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Und ich habe nie angenommen, dass dir das nicht klar wäre. ;-) Schoen das wir uns so gut verstehen :D
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
:
Bearbeitet durch User
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
Übrigens, Heise hat einen Fragen- und Antwortkatalog ins Netz gestellt: "FAQ zu Meltdown und Spectre: Was ist passiert, bin ich betroffen, wie kann ich mich schützen?" https://www.heise.de/newsticker/meldung/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen-3938146.html
Beitrag #5275059 wurde vom Autor gelöscht.
Alles Humbug schrieb: > "2nd generation Intel® Core™ processors" = Core iX 2xxx, laut https://www.intel.com/content/www/us/en/processors/processor-numbers.html
:
Bearbeitet durch User
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.
Na Super, ein gepatchtes SSD-System kann schonmal 20% langsamer werden.
Beitrag #5275133 wurde vom Autor gelöscht.
Spectre-Lücke: Auch Server mit IBM POWER, Fujitsu SPARC und ARMv8 betroffen https://www.heise.de/newsticker/meldung/Spectre-Luecke-Auch-Server-mit-IBM-POWER-Fujitsu-SPARC-und-ARMv8-betroffen-3938749.html
1 | IBM stellt Firmware-Updates für Server mit POWER7+, POWER8 und POWER9 |
2 | bereit, Fujitsu will einige SPARC-M10- und -M12-Server patchen; |
3 | zu ARM-SoCs für Server fehlen Infos. |
Potential Impact on Processors in the POWER family https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ Side-Channel Analysis Method(Spectre & Meltdown)Security ReviewList of affected Fujitsu Products https://sp.ts.fujitsu.com/dmsp/Publications/public/Intel-Side-Channel-Analysis-Method-Security-Review-CVE2017-5715-vulnerability-Fujitsu-products.pdf
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.
Paul B. schrieb: > Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch > von > diesem Problem betroffen ist? 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
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
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.