|
|
|
|
|
|
|
Am Smartphone kann ich das jetzt nicht lesen, klingt zunächst wie Rowhammer für die CPU, aber dann wäre AMD ja genauso dran. Schon von Juli, Artikel dient nur als Referenz?
Wissen wir eigentlich ab welcher CPU-Generation?
// edit
Und ich war schon stolz auf mich, heute herausgefunden zu haben wie std::vector wächst bei resize() >= capacity(). Ist natürlich reine Implementierungsabhängig. Scheint so als ob LIBSTDC++ nur die Vorgänge über capacity()/2 betrachtet.
|
|
[Dieser Beitrag wurde 8 mal editiert; zum letzten Mal von hoschi am 02.01.2018 23:08]
|
|
|
|
|
|
|
|
|
Ich schaue mich gerade nach einem neuen Server für unsere Bude um. Thomas Krenn und ICO verbauen irgendwie nur Intel, kann das sein?
Gibt es irgendwo einigermaßen frei zusammenstellbare AMD-Server?
/ Der Intel-HW-Bug jetzt ist natürlich noch Wasser auf die Mühle. Aber v.a. wollte ich Konkurrenz-belebend kaufen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Phillinger am 03.01.2018 11:21]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brian Krzanich (Intel-CEO) hat wohl Ende November alle seine Intel-Aktion (bis auf die Anteile, die er als CEO verpflichtet ist zu halten) verkauft. Ein Schelm, wer Böses dabei denkt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von red am 03.01.2018 15:24]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich bin mir noch nicht sicher, was der Screenshot bedeutet. Kann der zwei Bytes Kernel-Speicher (mit einer brauchbaren Wahrscheinlichkeit) leaken? Das wäre ja wirklich eine größere Katastrophe. 
/ah nein, er findet die Adresse von einem Syscall. Ist das eine Adresse, an die man aus dem Userspace nicht dran kommen darf? Warum?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 03.01.2018 17:15]
|
|
|
|
|
|
|
|
|
Jo, sys_call_table ist, wonach es klingt, die Syscall-Tabelle vom Kernel in seinem Speicher.
Damit würde ich die Spekulationen, dass der Bug Kernel-Speicher-Lesezugriffe ermöglicht, als ziemlich sicher bestätigt ansehen. Gleichzeitig ist damit dann auch klar, warum die Entwickler da so auf die Tube drücken.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 03.01.2018 17:16]
|
|
|
|
|
|
|
|
|
Also heißt das, dass er jetzt einfach für seinen PoC diese Adresse gesucht hat weil einfach zu verifizieren, und theoretisch könnte er auch (beispielsweise) Bytes aus dem kryptographisch relevanten Speicher lesen, oder verstehe ich das falsch?
ich habe mehr Begeisterung als Wissen zu security 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 03.01.2018 17:19]
|
|
|
|
|
|
|
|
|
KASLR hebelt er via kallsyms aus, sys_call_table hat er sich da denke ich einfach als leicht nachvollziehbares Ziel rausgesucht. Wenn man z.B. was aus einem anderen Speicher haben möchte (say Page Cache), dann müsste man erstmal herausfinden, wo der ist. KASLR wurde aber, soweit ich weiß, schon öfter kaputt gemacht, also das Übergehen dieser Hürde halte ich nicht für sonderlich einschränkend.
KASLR passiert auch nur einmalig pro Boot und ist danach halt fest. Der Kernel verwürfelt sich nicht laufend selbst. Nicht das ich wüsste
ich habe mehr Begeisterung als Wissen zu security <-- bei dem Exploitkrams hörts bei mir auch ganz ganz schnell auf
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 03.01.2018 17:23]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Model name: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
Stepping: 7
CPU MHz: 2790.991
CPU max MHz: 3500.0000
CPU min MHz: 800.0000
BogoMIPS: 5584.56
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
| |
SandyBridge hat bei mir die Erweiterung, die dafuer sorgt dass der TLB nicht ganz verloren geht. Wenn ihr kein PCID habt wird es spuerbar langsamer mit dem Bugfix. Im Heiseforum hat wer zu mir gemeint, dass es X86_64 Server-Prozessoren von Intel gibt, ohne die Erweiterung 
// edit
Pyrrhussieg 
Alle Intel-CPUs vor Haswell sind damit erstmal ein gutes Stueck langsamer, sobald mal ein bisschen Kerne/Userspace vorkommt. Am besten ihr spielt CSGO 
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 03.01.2018 18:07]
|
|
|
|
|
|
|
|
|
|
Haha! Geeqie 1.4 verwendet endlich GTK3 und kann unter Wayland laufen, ausgerechnet unter Wayland rendert Geeqie keine Bilder mehr ):(
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 03.01.2018 18:31]
|
|
|
|
|
|
|
|
|
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
| |
INTEL RESPONDS TO SECURITY RESEARCH FINDINGS
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.
Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.
Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
| |
(Lesen ist ja auch nicht ändern
Ansonsten klingt das irgendwie sprachlich nach einer komischen Mischung aus angepisst sein und Trump'scher Trotzigkeit.
... und war Intel nicht die Firma, die erst kürzlich eine neue Generation mit Tara vorgestellt hat, die +-1 % schneller als die Vorgängergeneration war? Und jetzt ist Performance nicht mehr so wichtig?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 03.01.2018 22:00]
|
|
|
|
|
|
|
|
|
|
Warten wir es mal ab, am Ende zählen dann die Fakten. Immerhin ein Gutes hat die Sache, PCID wird mal genutzt - an und für sich kein doofes Feature. Mit dem überpräzisen Statement hast du vollkommen recht. Ich hoffe aber auf Firmwareupdates bzw. Microcode.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 03.01.2018 22:43]
|
|
|
|
|
|
|
|
|
| | Zitat von Phillinger
Ich schaue mich gerade nach einem neuen Server für unsere Bude um. Thomas Krenn und ICO verbauen irgendwie nur Intel, kann das sein?
Gibt es irgendwo einigermaßen frei zusammenstellbare AMD-Server?
/ Der Intel-HW-Bug jetzt ist natürlich noch Wasser auf die Mühle. Aber v.a. wollte ich Konkurrenz-belebend kaufen.
| |
http://www.pcgameshardware.de/Ryzen-7-1800X-CPU-265804/News/AMD-Linux-GCC-Segfault-Error-1235342/
Ich habe immer noch Aktien von AMD, aber frei von Fehlern ist AMD plötzlich nicht. Für den Bug gibt es - nach wie vor - keine Bugfix als Microcode. Alle AMD Ryzen der erste Woche fallen bei etwas Compilerworkload um, gerade eine Paradedisziplin für Mehrkernprozessoren. AMD hat zu wenig getestet, haufenweise Compilerstresstests sollten schon Standard sein. Immerhin, AMD tauscht auf Zuruf aus. Das die noch nicht in Laptops stecken, ist AMDs Glück. Der Fehler ist natürlich unabhängig vom Betriebssystem. Da draußen sitzen viele Windowsleute auf fehlerhaften CPUs und wissen es nicht, macht halt mal irgendwann bei einem anderen Programm „b00m“.
Ich würde jetzt keine Steine werfen, wenn ich AMD wäre
// edit
Ist das mit AMP von Google widerlich. Bis gerade eben noch nicht gesehen, die könnten genau so gut auf Facebook hosten. JavaScriptkiddies 
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 03.01.2018 22:42]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
| | | These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them. | |
AMD sagt aber, dass AMD nicht betroffen ist. Interessant.
vs
| | | To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time. | |
Und ja, VM-zu-VM Speicherleck ist inbegriffen. Deswegen also der große Druck auf der Blase.
| | | To provide additional protection, the update for CVE-2017-13218 included in this bulletin reduces access to high-precision timers, which helps limits side channel attacks (such as CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) of all known variants of ARM processors. | |
Das ist wohl der Fix seitens Androids.
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
https://twitter.com/nicoleperlroth/status/948684376249962496
| | | Looks like everyone is vulnerable to arbitrary user memory reads, while Intel and ARM are vulnerable to arbitrary kernel memory reads as well. | |
https://www.nytimes.com/2018/01/03/business/computer-flaws.html
Joar ich würd sagen das Embargo "9. Januar" hat sich damit erledigt.
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von csde_rats am 03.01.2018 23:50]
|
|
|
|
|
|
|
|
|
|
Tja. Dann weiß ich, wer morgen früh Hebelzertifikate auf AMD kauft.
|
|
|
|
|
|
|
|
|
|
|
XSA-254 ist tatsächlich (auch) hierfür und wurde jetzt vor dem Embargo veröffentlicht.
Und wir haben Webseiten!
https://meltdownattack.com/
https://spectreattack.com/
| | | In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it. | |
Ey die immer mit ihren JS-Exploits. Srsly.
repo-ck / linux-ck hat jetzt gerade ganz frisch aus dem Steinofen (traditionelle Zubereitungsweise™ die gepatchte Version (4.14.11), Archlinux-Core noch nicht (.10).
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 04.01.2018 0:12]
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Tja. Dann weiß ich, wer morgen früh Hebelzertifikate auf AMD kauft.
| |
Der Kurs ist bereits ein gutes Stück rauf.
|
|
|
|
|
|
|
|
|
|
|
|
So hoch nun auch wieder nicht. Immer habe ich zu wenig Aktien.
|
|
|
|
|
|
|
|
|
|
|
Apple: we're slowing down processors cause your battery might be bad
Intel:
(via)
|
|
|
|
|
|
|
|
|
|
|
Hmmm. Hätte mir von der offiziellen Doomsdaywebsite etwas mehr erhofft, ohne gleich das Monsterabstrakt durchzulesen. Zum Glück gibt XEN mehr her und folgt dem Mittelweg, nicht zu wenig und nicht zu viel Information:
Die Out-Of-Order-Execution ist kaputt und zwar bei Intel, AMD und ARM. Wenn ein vermuteter Branch nicht ausgeführt wird, wird dass nicht ohne Seiteneffekt aufgeräumt. Soll heißen, rollback() funktioniert nicht wirklich.
AMD widerspricht dem, bis jetzt, die reden auch von drei Varianten wie XEN.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 04.01.2018 0:55]
|
|
|
|
|
|
|
|
|
Die Kombination aus "wie weit werden Branches spekulativ ausgeführt ohne Berechtigungen zu prüfen" und "Seiteneffekte in der Cache-Hierarchie kennen kein rollback()" scheint den Intel-CPUs das Genick zu brechen, weil genau diese Geschichte nämlich DOCH funktioniert. Das negative Ergebnis am Ende von dem Post war nämlich...
| |
"Fortunately I did not get a slow read suggesting that Intel null’s the result when the access is not allowed."
That (read from kernel address returns all-zeroes) seems to happen for memory that is not sufficiently cached but for which pagetable entries are present, at least after repeated read attempts. For unmapped memory, the kernel address read does not return a result at all. | |
Sobald man also Speicher vom Kernel irgendwie in den L1D bekommt, funktioniert der Exploit, der prinzipiell tatsächlich auf
Mov rax, [somekerneladdress]
And rax, 1
Mov rbx,[rax+Someusermodeaddress]
hinausläuft. Die Idee ist, dass man danach schaut, wie lange der Zugriff auf rax+Someusermodeaddress dauert (wobei rax+Someusermodeaddress eine Cache-Line ist, und rax+Someusermodeaddress+1 die nächste). Wenn spekulativ von [somekerneladdress] ein Wort geladen wurde, wo das unterste Bit gesetzt ist, dann wäre rax+Someusermodeaddress+1 im Cache, aber nicht rax+Someusermodeaddress, und das kann man messen.
Das ist schon ein ziemlich arger Clusterfuck.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 04.01.2018 1:03]
|
|
|
|
|
|
|
|
|
Clusterfuck find ich nicht, es ist halt eine ziemlich schlaue side-channel (timing) Attacke und ist ja genau deswegen so devestating, weil es halt schwer zu beheben ist, ohne die Laufzeitvorteile von speculative branching wieder aufzugeben.
Ob Androids Zugriffseinschränkung auf die timer hilft? Vermutlich könnte man das immer noch zB per race condition testen?
Achja, kudos an @tehjh!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 04.01.2018 1:08]
|
|
|
|
|
|
|
|
|
Naja ich meine da primär, dass es nahezu alle Rechner betrifft und anscheinend durch JS ausgenutzt werden kann. Wohl nicht im vollen Umfang, sondern - vorerst - nur um den Speicher vom Browser auszulesen, aber da ist auch genug Zeugs drin.
... irgendwo aber schon auch die Idee "lass erstmal machen, sicherheitschecks dann hinterher". Gut. Hinterher ist immer gut reden.
| | » Defeating KASLR as a prerequisite is apparently now almost not worth mentioning. Seems about right.
| |
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 04.01.2018 1:20]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Die Gaming-affinen Leser von ComputerBase wird freuen, dass es in den Spiele-Benchmarks von Phoronix keine messbaren Leistungseinbußen gibt, sodass Gamer sich vermutlich entspannt zurücklehnen können – zumindest unter der Annahme, dass die Ergebnisse der Linux-Benchmarks auf Windows übertragbar sind, wovon man zunächst ausgehen sollte. So wie es aktuell aussieht könnten allenfalls die Ladezeiten durch PTI negativ beeinflusst werden. | |
computerbase.de
Jahr 2018. Linux hat immer noch nicht den Desktop erobert. Linux ist jetzt die Referenz für Spieleleistung! Unerwartet. Gut 
SPECTRE scheint die lästigere von Beiden Attacken zu sein. Und eben auch AMD und ARM zu treffen, ich nehme die Antwort von AMD auch als leicht überspezifiert wahr. Aber wie funktioniert SPECTRE, Branch-Prediction (siehe XEN)?
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
Clusterfuck find ich nicht, es ist halt eine ziemlich schlaue side-channel (timing) Attacke und ist ja genau deswegen so devestating, weil es halt schwer zu beheben ist, ohne die Laufzeitvorteile von speculative branching wieder aufzugeben.
| |
Eigentlich ist der Clusterfuck daran, dass das womöglich der erste Bug ist, den fast jeder Betroffene bemerken wird sofern die Patches wirklich bis zu 30% Performance abknapsen. Bei den letzten paar Dutzend Bugs-mit-Namen war es doch schlichtweg scheißegal ob da jemand gepatcht hat oder nicht - WoW und der Truck-Simulator liefen ja unberührt weiter. Dagegen kommt hier nun das Windows-Update reingepresst und ... naja, ich möcht danach nicht im Social Media Team von Intel sitzen.
Das Spectre-Gespenst is putzig.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 04.01.2018 2:34]
|
|
|
|
|
|
|
|
|
|
Zum Glück wird Windows traditionell immer größer und langsamer. Nur gibt es jetzt schon schlechte Presse dazu und alle werden Benchmarks durchführen.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
