News Foreshadow/L1TF: Intels Albtraum-Jahr der Sicherheitslücken geht weiter

[XTR³M³]

Intel hat einen neuen Kanal
Intel Graphics (Twitter)

Graphics sollten sie durch graphic ersetzen, passt in deren situation derzeit besser X-D

" .... wenn alle "Bremsen" (Patches) raus sind noch mit AMD mithalten kann. "

Bin sehr gespannt wie schnell ehhhh, langsam der 9900k nachher mit allen eingespielten patches ist

Reicht auch eine Wollmütze mit Kupferspray eingesprüht?

Ne, aber kupferpaste anstelle haargel funtz, kommt auch auf jedem rave sehr gut an

 

[xexex]

Selbst mit Microcode Update , OS Patch und Software Patch kann es notwendig sein HT zu deaktivieren , und zwar dann wenn dem VM Nutzer erlaubt ist ein eigenes Betriebssystem zu installieren , bei dem man nicht kontrollieren kann ob es gepatcht wurde oder nicht .

Im Moment ist der Status folgender:

Hyper-V 2016 ist gepatcht und braucht keine Deaktivierung von HT oder speziell gepatchte Guest-VMs. (Core Scheduler)
https://blogs.technet.microsoft.com/virtualization/2018/08/14/hyper-v-hyperclear/
ESXi ist gepatcht und braucht es ebenfalls nicht. (ESXi Side-Channel-Aware Scheduler)
https://kb.vmware.com/s/article/55806
Xen ist gepatcht, es wird aber noch an einer besseren Lösung gearbeitet
https://xenbits.xen.org/xsa/advisory-273.html
KVM ist ähnlich wie Xen

Disabling Extended Page Tables (EPT) for KVM guests mitigates the L1TF issue, because it essentially lets the VMM/Hypervisor manage the address translations for the guest. If EPT is disabled, one does not need to disable Hyper-Threads (SMT) and flush L1 data cache as listed above.
https://access.redhat.com/security/vulnerabilities/L1TF

Citrix hat mal wieder nichts getan und bietet keine Mitigation auf Hostlevel.
https://support.citrix.com/article/CTX236548

Grundsätzlich scheinen die Linux basierten Virtualisierungslösungen noch etwas Arbeit zu benötigen. Wie es bei weiteren kommerziellen Lösungen aussieht ist mir nicht bekannt.

 

[CS74ES]

Schonmal drüber nachgedacht, dass Heimanwender einfacher erpressbar sind?

Ja, und am Ende ist es die NSA, die einen nach Guantanamo verschleppt. Sorry, musste sein.
Bist du denn so "betucht", dass bei dir so viel Geld zu holen ist?
Aber die Diskussion ist sowieso sinnlos, jede Seite hat 1000 Gründe.
Gibt da nen Spruch: "Wer bei mir was holen will, muss was mitbringen"
Aber richtig, die Gefahr lauert überall, vielleicht sind es am Ende die eigenen Eltern, die einen fertig machen

 

[Zuckerwatte]

Was Meltown&Spectre betrifft, sind Heimanwender für die Angreifer völlig uninteressant, da lohnt der Aufwand nicht, da man den Ertrag nicht einschätzen kann. Da sind Firmen, Institutionen, Behörden, Verwaltungen deutlich interessanter und auch lukrativer.

Privatanwender über Meltown&Spectre anzugreifen ist auch gar nicht nötig, da reicht es schon, wenn man sich ein Laptop und zwei bis drei Programme normal im Internet zieht und ich kann bei unverschlüsselte Wlan Netze
die Daten abgreifen und speichern, da gibt es immer noch genügend User die ungeschützt sind!
[...]

Hm.. ob Firmenchefs auch Heimanwender sind und ob die auch von ihrem privaten Heimgerät auf die Firmendaten zugreifen können und die dort auch liegen haben?

unverschlüsseltes Wlan.............. da kannste sowieso nicht mehr helfen.

Ergänzung (16. August 2018)

Ja, und am Ende ist es die NSA, die einen nach Guantanamo verschleppt. Sorry, musste sein.
[...]
Gibt da nen Spruch: "Wer bei mir was holen will, muss was mitbringen"
Aber richtig, die Gefahr lauert überall, vielleicht ist es die eigene Frau, die einen anschwärzt

Du scheinst zu vergessen, dass Heimanwender auch CEOs, Manager u.a. beinhaltet. (idr einfacherer Angriffspunkt als übers Firmennotebook und Netzwerk..)

Ist ja schön, dass du es anders siehst..aber mir einen Aluhut aufzusetzen weil ich skeptischer bin und nicht blind vertraue?

Es gibt viele Sprüche und viele sind für die Tonne.

Hinter jedem bösen Mann steckt eine viel viel bösere Frau!!!!einself

 

[CS74ES]

Ja, Datenschutz ist ganz wichtig.

Sei einfach nicht erpressbar, wie wärs damit? Oder steh einfach zu deinen Fehlern, dann kann dir auch niemand was.

 

[ZeusTheGod]

Und Ryzen bzw. Epyc sind alleine schon günstig weil du nicht nach einem Jahr auf ein neues Board wechseln musst.
Ergo musst du bei Intel rechnen: Umstieg von 7700k auf 8700k = cpu + Mainboard. Beim Amd konntest du einen x1800 duch einen 2700x einfach ersetzen. Das macht was? Richtig die CPU insgesamt billiger...
Zumal sie auch so billiger ist aber who cares nech?

Das ist aber aus zwei Gründe kein wirkliches Argument:

1. Haben bei Intel die 6xxx und die 7xxx auf das gleiche Board gepasst
2. Wechselt kaum jemand (der aufs Geld achten muss) Jährlich seine CPUs, insbesondere, wenn die Leistungssteigerungen so minimal ausfallen, wie in den letzten Jahren

@Topic:
Für Cloud/Server-Anbieter ist das sicherlich nicht der Hit, allerdings sehe ich bei den Heimusern die wesentlich größere Gefahr vor dem Bildschirm. Darüber ist nämlich jeder Heim/Office-PC angreifbar.

 

[gr3if]

Das ist aber aus zwei Gründe kein wirkliches Argument:

1. Haben bei Intel die 6xxx und die 7xxx auf das gleiche Board gepasst
2. Wechselt kaum jemand (der aufs Geld achten muss) Jährlich seine CPUs, insbesondere, wenn die Leistungssteigerungen so minimal ausfallen, wie in den letzten Jahren

Womit du den besten Grund gegen Intel und pro AMD gleich mitbringst. Ein Monopolist alleine tut dem Markt nicht gut und jetzt wo AMD dafür sorgt das sich Team Blau deutlich schneller bewegt als sie wollten, sollte man sie in meinen Augen unterstüzen.

 

[MK one]

Im Moment ist der Status folgender:

Hyper-V 2016 ist gepatcht und braucht keine Deaktivierung von HT oder speziell gepatchte Guest-VMs. (Core Scheduler)
https://blogs.technet.microsoft.com/virtualization/2018/08/14/hyper-v-hyperclear/
ESXi ist gepatcht und braucht es ebenfalls nicht. (ESXi Side-Channel-Aware Scheduler)
https://kb.vmware.com/s/article/55806
Xen ist gepatcht, es wird aber noch an einer besseren Lösung gearbeitet
https://xenbits.xen.org/xsa/advisory-273.html
KVM ist ähnlich wie Xen

Citrix hat mal wieder nichts getan und bietet keine Mitigation auf Hostlevel.
https://support.citrix.com/article/CTX236548

Grundsätzlich scheinen die Linux basierten Virtualisierungslösungen noch etwas Arbeit zu benötigen. Wie es bei weiteren kommerziellen Lösungen aussieht ist mir nicht bekannt.

https://access.redhat.com/security/vulnerabilities/L1TF

auch ein bisschen weitergelesen ?

Disable EPT:
Disabling Extended Page Tables (EPT) for KVM guests mitigates the L1TF issue, because it essentially lets the VMM/Hypervisor manage the address translations for the guest. If EPT is disabled, one does not need to disable Hyper-Threads (SMT) and flush L1 data cache as listed above.

Please note: disabling EPT will significantly hamper the system performance. It may not be a viable option.

EPT can be disabled in the hypervisor via the kvm-intel.ept parameter. It is enabled by default.

 

[duke1976]

Der Imageschaden für Intel ist jedenfalls da. Für eine Firma mit diesen Möglichkeiten ist diese offensichtliche Nachlässigkeit eigentlich schon unverzeihlich. Hoffe, wir sind hier irgendwann mal über den Berg.

 

[xexex]

auch ein bisschen weitergelesen ?

Klar! Deshalb steht auch beim Xen Projekt:

There are ongoing experimentation and development efforts to find lower
overhead mitigations for the HVM case.
https://xenbits.xen.org/xsa/advisory-273.html

Bei Hyper-V geht mit dem Core Scheduler so gut wie keine Leistung verloren. Beim ESXi Server lässt sich auch ohne Patch vermeiden, dass sich die VMs logische Kerne teilen. Die linuxbasierten Lösungen scheinen derzeit wie schon bei Spectre/Meltdown noch zusätzliche Zeit/Arbeit brauchen. Google und Amazon haben mal wieder eigene Lösungen.
https://www.securityweek.com/foreshadowl1tf-what-you-need-know
https://cloud.google.com/blog/produ...inst-the-new-l1tf-speculative-vulnerabilities

 

[TheLastHotfix]

... oops, falscher Tab, sorry.

 

[habla2k]

Ach das betrifft doch keine Normalbürger, ich hab nichts zu verbergen, wer will mich schon hacken? Außerdem bringt der 9900K mir 136 FPS, anstatt 123 FPS. Alles nur Panikmache durch AMD, nein halt, ne Verschwörung um Intel vom Thron zu stoßen! Kauft alle Intel um sie vor AMD zu schützen!

 

[TheLastHotfix]

Kauft alle Intel um sie vor AMD zu schützen!

fehlt noch der wichtigste Satz: "Es geht um die nationale Sicherheit!"

 

[Banned]

Ja, Datenschutz ist ganz wichtig.

Sei einfach nicht erpressbar, wie wärs damit? Oder steh einfach zu deinen Fehlern, dann kann dir auch niemand was.

Wo ist der Dislike Button, wenn man ihn mal braucht?

 

[-Firebat-]

@xexex
Scheinbar verstehe ich das dann anders als du. Bei VMware steht doch ganz klar, dass das ganze nur eine Option ist, wenn die Auslastung nicht höher als 70% liegt. Liegt sie höher, ist das Performance Penalty so groß, dass nur mit zusätzlicher Hardware der Betrieb aufrecht erhalten werden kann.

 

[MIWA P3D]

wenn das so weiter geht, ist der bulldozer doch wieder schneller als die 2te core generation

und im Win patch wurde jetzt auch noch die Handbrmse gelöst für Bulli und Jaguar

 

[max9123]

Das ist aber aus zwei Gründe kein wirkliches Argument:

1. Haben bei Intel die 6xxx und die 7xxx auf das gleiche Board gepasst
2. Wechselt kaum jemand (der aufs Geld achten muss) Jährlich seine CPUs, insbesondere, wenn die Leistungssteigerungen so minimal ausfallen, wie in den letzten Jahren

@Topic:
Für Cloud/Server-Anbieter ist das sicherlich nicht der Hit, allerdings sehe ich bei den Heimusern die wesentlich größere Gefahr vor dem Bildschirm. Darüber ist nämlich jeder Heim/Office-PC angreifbar.

Zwischen Skylake und dem 1. Skylake Refresh (Kabylake) besteht abseits von minimalen Fertigungsverbesserungen praktisch kein Unterschied.

Der 2. Skylake Refresh (Coffee Lake) bringt zumindest im Maximalausbau zwei Kerne mehr mit. Beim 3. Skylake Refresh (Whisky Lake) kommen abermals zwei Kerne bei minimal verbesserter Fertigung hinzu. Hier wird im Vergleich zu Skylake allerdings wieder ein neues Mainboard benötigt.

 

[Zuckerwatte]

[...]
Sei einfach nicht erpressbar, wie wärs damit? Oder steh einfach zu deinen Fehlern, dann kann dir auch niemand was.

Idealismus =! Realität
Subjektiv bin ich idealistisch irgendwo bei dir.... realistisch gesehen: Schwachsinn.

 

[xexex]

Liegt sie höher, ist das Performance Penalty so groß, dass nur mit zusätzlicher Hardware der Betrieb aufrecht erhalten werden kann.

Offizielle Aussage sagt folgendes

The following list summarizes potential problem areas after enabling the ESXi Side-Channel-Aware Scheduler:

• VMs configured with vCPUs greater than the physical cores available on the ESXi host
• VMs configured with custom affinity or NUMA settings
• VMs with latency-sensitive configuration
• ESXi hosts with Average CPU Usage greater than 70%
• Hosts with custom CPU resource management options enabled
• HA Clusters where a rolling upgrade will increase Average CPU Usage above 100%

"Potential" ist hier die entscheidende Aussage! Ich konfiguriere ESXi VMs seit Anbeginn bereits nur noch so:

Damit werden grundsätzlich die logischen Kerne eines physikalischen Kerns nicht auf zwei unterschiedliche VMs aufgeteilt. Es entspricht dem, was die Mitigation auf einer anderen Ebene macht. Teilen sich zwei Maschinen einen physikalischen Kern, geht die Leistung bei stark ausgelasteten Guests sowieso in den Keller.

VMware warnt nun davor, ohne weitere Tests, bei Hosts die im Durchschnitt bereits zu mehr als 70% ausgelastet sind, den neuen Scheduler zu aktivieren. Ich würde bei einer solchen Auslastung schon längst einen neuen Host ins Cluster hinzufügen.

Im Grunde genommen braucht man den neuen Scheduler aber nicht zu aktivieren. Der eigentliche Sicherheitspatch und die gezeigte Einstellung macht eigentlich das gleiche.

Attack Vector Summary

• Sequential-context attack vector: a malicious VM can potentially infer recently accessed L1 data of a previous context (hypervisor thread or other VM thread) on either logical processor of a processor core.
• Concurrent-context attack vector: a malicious VM can potentially infer recently accessed L1 data of a concurrently executing context (hypervisor thread or other VM thread) on the other logical processor of the Hyper-Threading enabled processor core

Mitigation Summary

• The Sequential-context attack vector is mitigated by a vSphere update to the product versions listed in the table below. This mitigation is dependent on Intel microcode updates (provided in separate ESXi patches for most Intel hardware platforms) also listed in the table below. This mitigation is enabled by default and does not impose a significant performance impact.
• The Concurrent-context attack vector is mitigated through enablement of a new feature known as the ESXi Side-Channel-Aware Scheduler. This feature may impose a non-trivial performance impact and is not enabled by Default.

https://www.vmware.com/security/advisories/VMSA-2018-0020.html

 

[Smartcom5]

Da frage ich mich nicht mehr wie dumm ein Konzern sein kann.
Mal erlich Intel hat genug Personal welches nicht aufm Kopf gefallen ist.

Das kommt davon wenn man am Anfang ein Fehler macht und ihn erst x Jahre später bemerkt aber zu "faul"
ist ihn zu beheben. Es folgen weitere Fehler.
Wie Paradox das Intel nicht logischerweise mal sein Prozessoren grundlägend überarbeitet.

Da wird Intel hoffentlich Kunden verlieren, das grenz ja schon an Fahrlässigkeit.

Nein, das grenzt nicht an Fahrlässigkeit, dies ist und war fahrlässig.
Es war auch kein Fehler, sondern schlicht Absicht – ansonsten würde AMD ja mit den selben Problemen bei Meltdown, Spectre, Hyper-Threading & Co geplagt sein, was sie ja nicht sind.

Man hat ja monatelang auch ebenso auf AMD-Prozessoren versucht diese Dinge nachzustellen …

Spoiler: Am Rande …

AMD‘s entsprechende Aussage eines 'near zero risk' bezüglich SPECTRE Variant #2 (Branch Target Injection), hat die Bedeutung eines praktischen und faktischen Risikos nahe Null.

Der Grund, weswegen diese Konstatierung überhaupt erhoben werden kann, ist, daß es zumindest theoretisch möglich sein müßte, entsprechende Lücken auszunutzen – es aber a) in der Praxis de facto (bisher) nicht möglich war und man b) bis jetzt auch keinen Weg gefunden hat, diese wenigstens c) theoretisch vorhandene Schwachstelle praktisch in einem Szenario umzusetzen und auszunutzen.

Ein präventiv veröffentlichtes BIOS-Update schließt nun diese theoretisch, bisher nicht nachweislich durch Exploits ausgenutzte Lücke und mach aus einem faktischen ›Nullrisiko‹ ein ›nicht anwendbar‹.
PS: Man verzeihe mir die möglicherweise zwecks Erläuterung erhebliche Simplifizierung der jeweiligen Sachverhalte.

…
Begriffsbestimmung
Ja, es müßte, zumindest theoretisch, möglich sein, diese Schwachstelle bei AMD-Prozessoren ebenfalls auszunutzen. Dieses eigentliche und eben jenes „theoretisch möglich“ ist hier aber lediglich eine A-priori-Wahrscheinlichkeit(Anfangswahrscheinlichkeit) – und damit lediglich aus dem Bereich der Er·kennt·nis·theo·rie.

Es ist in diese Falle auch nicht wirklich nötig, diese Aussagen sarkastisch zu interpretieren – und dafür muß man nicht einmal AMD-Fanboy sein. Die bloßen Möglichkeiten eines Exploits und daher des eigentlichen Angriffsszenariosbestehen bei den Prozessoren von AMD lediglich in der Theorie. Daher darf hier AMD berechtigterweise von einen faktischen Risiko nahe Null ausgehen.

Faktenlage
Man hat bereits monatelang ergebnislos versucht, diese theoretischen Lücken in der Praxis zu exploiten – ohne Erfolg, da es de facto und in praxi (→ nach Lage der Dinge und Tatsachen) unmöglich ist, diese Lücke auszunutzen.

Obwohl es prinzipbedingt und daher theoretisch möglich sein müßte, hat man seit geraumer seit nicht nur nicht (→ keinen) einen Weg gefunden, der nicht von Seiten der Prozessor-internen Schutzmechanismen abgefangen wird, sondern man hat auch bisher nicht einmal theoretisch eine Lösung dafür gefunden, die in der Praxis vorhandenen Schutzmechanismen wenigstens theoretisch auszuhebeln um – diese letztendlich überwunden – die dahinterliegende eigentliche Schwachstelle auszunutzen.

Es müßte prinzipbedingt und theoretisch möglich sein, daß die Schwachstelle in Prozessoren von AMD ebenfalls ausgenutzt werden kann, ja – diese Konstellation ist unbestreitbar logisch gegeben. Allerdings erweist sich das in der Praxis als faktisch und technisch Unmöglich und man hat bisher nicht einmal in der Theorie einen zumindest theoretisch möglichen und den Gesetzen der Logik folgenden Weg gefunden, diese Schwachstelle auszunutzen – wobei man zumindest theoretisch nicht ausschließen kann, daß man ihn in der Zukunft wird finden können.

Im Übrigen darf man mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, daß zumindest Intel alles daran gesetzt haben dürfte, diese Lücke eben auch bei AMD ausnutzbar zu machen – und wenn es nur dafür geeignet wäre, dem Gegenüber das obligatorische „Du aber auch!“ an den Kopf zu schmeißen. Damit wird Intel das letztes halbe Jahr unter Garantie beschäftigt gewesen sein …

Und wie bereits vielerorts erwähnt, sind die Probleme oder Risiken weder neu noch anderweitig unbekannt.
Das Ganze Thema Side-Channel (Seitenkanal-Attacken) ist nicht neu, schon seit Ende 1992 bekannt und erste größere Angriffe wurden bereits '96 von Kryptologen Paul C. Kocher demonstriert.

Nur zum Verständnis …
Insbesondere die explizite Lücke Meltdown war damals nicht neu, nicht mal so ein bisschen. Wer das trotz offensichtlich anders lautender Quellen noch immer behauptet, weiß es entweder nicht besser, oder aber unterschlägt diese Fakten wissentlich und mutwillig.

…
Daß man allerorten urplötzlich von der Gefahr überrascht wurde, entspricht schlicht nicht einmal im Ansatz den Tatsachen. Das Thema, etwaige theoretische Ansätze und dergleichen sind und waren seit Jahren ein Thema in der Sicherheitsbranche respektive unter Prozessor-Experten.

Und ja, explizit die von Intel verwendete Art und Weise der Handhabung der Caches war nicht nur bekannt sondern auch immer wieder ein oft diskutierter Knackpunkt und zentraler Inhalt von Sicherheitsforschungen. Das bedeutet, man war sich als Kollektiv in der Branche sehr wohl über jeweilige – mindestens theoretisch – hochgradig sicherheitskritischen Exploits bewußt und dies hat man auch schon vor geraumer Zeit an Intel herangetragen, mehr als einmal.

Stichpunkt ‚Risikomanagement‘
… und ja, Intel hat diese Angriffsszenarien stets als zu unbedeutend erachtet und evidente Geschwindigkeitsvorteile immer wieder als zu kapital erwogen, um sie zugunsten erhöhter Sicherheit fallen zu lassen. Wenn ich mich recht entsinne, ist das Thema fast genauso alt, wie die jeweilige Intel'sche Umsetzung in eben jenen Prozessoren. Ich meine mich zu erinnern, daß spätestens seit '06 es als kritisch angesehen wurde, wie Intel ihre Caches anspricht oder handhabt. Intel wußte das und hat es ignoriert.

… allerspätestens '16 war Meltdown groß und breit als prominenter Tagespunkt auf der Blackhat '16 angesetzt und wurde offen diskutiert, während die identische Thematik bereits '14 auf der selben Sicherheitskonferenz zumindest angeschnitten wurde.

Wurde der Bug oder zumindest Teile davon nicht bereits auf der Black Hat 2016^[2] am 3. und 4. August des selben Jahres publik gemacht – und war selbst davor schon bekannt …?

Lektüre:
BlackHat.com • Joseph Sharkey, Ph.D. – Siege Technologies: „Breaking Hardware-Enforced Security with Hypervisors“ (PDF; 2,85 MB)
BlackHat.com • Yeongjin Jang et al. – „Breaking Kernel Address Space Layout Randomization with Intel TSX“ (PDF; 19 MB)

Ich finde alleine diese herunterspielen à la „Es gibt eh keine sicheren Prozessoren“, „bei AMD wird man vergleichbares mit der Zeit finden“ oder „liegt nur an der Verbreitung der Intel-Prozessoren, daß da jetzt so viel gefunden wird“ et cetera pp. schon irgendwie krass.

Da wird ein Hersteller, dem im Augenblicke seiner kapitalen Änderung und (folgenschweren, weil grob fahrlässig) der Ansprechverhalten und Funktionsweisen seiner Chip-Interna bereits die Folgen seines Handelns nicht nur bewußt war, sondern von externen Experten immer wieder eindringlich davor gewarnt wurde, daß diese Änderungen schwerstmögliche und in höchstem Maße potentiell schwerwiegende Angriffsvektoren erst erschaffen würden, regelmäßig von dem Gros der Ahnungslosen die sprichwörtliche „Hand vor den Arsch“ gehalten – weil es „ja sowieso keine sichere Hardware gibt“.

Und es werden immer wieder kapitalste Sicherheitslücken herunter gespielt, weil „schon nicht so schlimm“ weil es ja nicht der Fehler des Unternehmens war, und; „damals konnte sowas ja noch Keiner ahnen“. Unglaublich …

Es war bekannt, sogar schon bevor Intel solche Änderungen überhaupt zum Zwecke der massiven Geschwindigkeitssteigerungen in Hardware integrierte – auf Kosten unser aller Sicherheit.


In diesem Sinne

Smartcom