News Sicherheitslücke Spectre: BIOS-Updates von ASRock, Asus, MSI, Gigabyte & EVGA

[*VeGa*]

Ich warte mit dem Update von meinem Board.
Erstmal Berichte abwarten von anderen Usern.
Hab weder Bock auf irgendein vermurkstes Bios noch auf XX% weniger Leistung

so sehe ich das auch !
Wir wurden eh schon so viele Monate nicht unterrichtet, da werde ich den Teufel tun und bei dieser Hauruck Aktion auch noch Versuchskaninchen spielen.
Ich denke, für den normalen Privatanwender besteht auch ohne Biosupdate kein Grund zur Sorge !
Damit meine ich nicht, dass ich jetzt nicht angreifbar wäre, sondern das ich als kleiner Privatanwender für einen potenziellen Angreifer einfach ein unattraktives Ziel bin.

 

[The_Void]

Ich denke, für den normalen Privatanwender besteht auch ohne Biosupdate kein Grund zur Sorge !

dann denk du mal weiter so. ich, für meinen teil, habe die erfahrung gemacht, daß sicherheitslücken früher oder später auch ausgenutzt werden, denn was für die malwaremacher/hacker möglich ist, wird auch gemacht. daher werde ich das BIOS update, sollte es eins geben, frühzeitig aufspielen, sollten sich im internet nicht die fehlerberichte von usern häufen.

generell zu sagen, es bestünde hier "kein grund zur sorge", halte ich für falsch, ja fast fahrlässig. das gegenteil ist der fall und meltdown/spectre ist zu vergleichen, mit einem super gau in der pc geschichte, den es in der form noch nicht gegeben hat.

edit: keiner kann sagen, ob die sicherheitslücken meltdown/spectre nicht bereits ausgenutzt wurden, denn bei einfallstoren auf hardwarebene gibt es keinen eintrag in der ereignisanzeige oder ähnlichem - es gibt keine logs und keinerlei beweis, daß jemand den pc kompromittiert hat. daher spreche ich vom größten, anzunehmenden unfall. das muß einfach gefixt werden und zwar schleunigst. wer anders denkt, dem ist es wohl egal oder er ist möglicherweise einfach ahnungslos.

 

[Sun_set_1]

Artikel-Update: Die Meldung wurde um Informationen zu Updates von EVGA ergänzt. Zu Mainboards von Biostar liegen aktuell weder Informationen vor, noch stehen nach Recherchen der Redaktion neue BIOS-Versionen zum Download bereit.

Viel Erfolg. Habe gestern Abend versucht herauszufinden welche AGESA Version denn nun offiziell von AMD in Umlauf gebracht wurde... Habe nach zwei Stunden bei Google dann aufgehört

Ich vermute zumindest was AMD angeht:

Das jetzige aktuelle Update, welches bei den Linux-Distris auftaucht, ist ein normales "Turnus-gemäßes" Update und hat nichts mit Spectre zu tun. In der Regel veröffentlicht AMD ca. alle 6 Monate ein Update, das Letzte kam im Juni/Juli 2017 -> passt.

AMD ist davon ausgegangen, dass man von Spectre nicht oder fast nicht betroffen ist. Dementsprechend wird man die Prio des Fixes niedriger angesetzt haben. Nach dem Hype in den ersten zwei Wochen hat sich AMD entschieden, wohl doch ein AGESA Update vorzuziehen, was Heise zu der überhasteten Meldung führte. Was AMD wohl meinte ist, dass ein Update im Februar / März kommt, anstelle von (turnusgemäß) Juli 2018.


Parallel mit der Aussage von AMD folgte die Veröffentlichung des Microcode-Update bei den Linux-Distris.
Da kann man an der Stelle wohl zusammenfassend sagen, blöd gelaufen.

Ich denke die VO des Updates war länger geplant, die Aussage von AMD hatte wahrscheinlich schlicht darauf keine Rücksicht genommen und war vom Timing her damit entsprechend äußerst unglücklich.

Jedenfalls enthält dieses Microcode-Update nicht die Spectre Mitigations. Zumindest nicht laut den Skripts, sie melden weiterhin "vulnerable", respektive "hardware support: false".

 

[DaZpoon]

Das Microcode Update bewirkt eigentlich nur, dass man per Code erfahren kann ob man einen betroffenen Prozessor hat und die spekulative Ausführung eingrenzen kann. Das heißt, dass je nach Anwendung der Performancevorteil dadurch nicht mehr zur Verfügung steht. Mir wäre da aber die Sicherheit wichtiger als die Performance. Der Meltdown-Workaround macht sich zwar vor allem bei Verschlüsselungen (eCryptFS) bemerkbar, aber damit muss man Leben bis Ersatz da ist.

Bevor man aber bzgl. der Unterstützung alter Boards auf die MB-Hersteller losgeht: Ich habe gestern mal die von Intel zur Verfügung gestellten intel-ucodes angeschaut, da hat sich seit Mai 2017 für Sandy Bridge (06-2a-07) nix geändert:

md5deep64.exe D:\ucodes\*.uc
891f89c31a5f9f01705cce1d55e7f14d  D:\ucodes\06-2a-07.2017-05-11.uc
891f89c31a5f9f01705cce1d55e7f14d  D:\ucodes\06-2a-07.2018-01-08.uc

 

[The_Void]

hier mal ein link zu pcgh, um meine aussagen in meinem post #143 zu untermauern.

 

[Delgado]

Ne, das "öffnen mit" Fenster in der PowerShell hatte ich auch. Scheint ein Problem zu sein, wenn man von Win7 auf 10 gegangen ist.

Dann wird die installierte Repo als untrusted bewertet, was bedeutet, das die Policy RemoteSigned nichts bringt.

Die Policy anstelle von "RemoteSigned" auf "Unrestricted" setzen, dann gehts. Das Ganze natürlich mit Rechtsklick -> Als Admin ausführen.

Das trifft hier zu (Win 7 > 10), ich teste deinen Vorschlag mal, danke

 

[sdfighter]

Finde es amüsant, dass in den Medien berichtet wurde, dass "nur" Intel Prozessoren der alten Generationen betroffen waren. Habe mich da immer sicher gefühlt mit meinem 7700k und B250F Strixx. Gut dass es euch gibt... mache heute erstmal ein BIOS update abends.

 

[DocWindows]

Der Hersteller selber hat allerdings bereits am 8. Januar Microcode-Updates auch für ältere CPUs wie Haswell und Broadwell zur Verfügung gestellt, die Basis ist also gelegt. Nur nutzen können Privatanwender sie unter Windows nicht.

Denn unter Windows kann Microcode im Gegensatz zu Linux nicht ohne weiteres separat eingespielt werden

"Unter Linux"geht das doch auch nicht mehr, weil die CPU dann bereits in einem Modus operiert wo man keinen Microcode mehr reinladen kann, oder nicht?
Wenn es hingegen noch in GRUB funktioniert, dann müsste es auch beim Bootprozess von Windows funktionieren, zumindest auf UEFI Systemen. Man bräuchte halt eine EFI-Anwendung die Microcode laden und anwenden kann. Die kann dann zwischen bootx64.efi und bootmgfw.efi geladen werden, oder man integriert sowas gleich in den bootmgfw. Dann müsste Microsoft lediglich ein Update ausrollen, was die bootmgfw.efi Anwendung aktualisiert.

 

[CS74ES]

ASUS kommt mir auf jeden Fall nicht mehr ins Haus...selten soviele Probleme mit einem Mainboard gehabt...das Teil freezt so oft ein oder killt sich teilweise komplett selbst > Alles schön nach Ablauf der Garantie und Gewährleistung.

Das ist wahrscheinlich Jacke wie Hose. Ich habe bis vor einiger Zeit nur Asrock gekauft, weils halt vom P/L gut war, aber da hatte ich immer wieder Probleme mit den Slots (Kontaktprobleme an RAM, Grafik-Slots). Jetzt kaufe ich Asus und habe immer wieder Probleme mit dem Bios (Lüftersteuerung gesponnen, RAM geht nicht richtig). Einmal habe ich jeweils MSI und Gigabyte versucht, beim MSI kam ich mit dem Bios absolut nicht zurecht und das Gigabyte hat von vorn herein den Dienst versagt.
So hat wahrscheinlich alles seine Macken.

@News

Bin mal gespannt wie lange Asus mit meinem Board auf sich warten lässt.

 

[Spike S.]

Ebenfalls am 12. Januar veröffentlichte Updates für ältere Platinen adressieren bei ASRock vorerst nur die Sicherheitslücke in Intels Management Engine.

Für mein >150€ Z170 Board gibt es seit 2016 keine Updates mehr
Ich kaufe künftig nur noch Boards für nen Fuffie...statt BIOS Updates dann einfach ein neues Board.

 

[Sun_set_1]

"Unter Linux"geht das doch auch nicht mehr, weil die CPU dann bereits in einem Modus operiert [...].

Doch unter Linux geht es, da Grub den Microcode laden kann bevor der Kernel initalisiert wird.

Der Windows "OS-Loader" sieht diese Möglichkeit aber bisher nicht vor. Die Technik funktioniert anders. Der OSLoader initalisiert die Laufwerke und lädt zum Start erforderliche Treiber in den Speicher. Dann wird der Kernel initalisiert und holt sich anschließend die Treiber ab.

Bei Linux wird der Microcode geladen bevor der Kernel gestartet wird.

Ganz simpel,

Linux: Microcode -> Kernel -> System
MS: Kernel -> Treiber, (ggf Microcode), System.

Das geht theoretisch natürlich auch unter Windows, nur müssten diese dafür den OSLoader umbauen, wozu sie wahrscheinlich relativ wenig Motivation hatten.

Da zuerst der Kernel geladen wird, sind die Patches dann inaktiv. Bei Ubuntu kannst du es über die Softwareaktualisierung -> Andere Treiber einsehen, ob ein neuer Microcode geladen wurde.

 

[Syrell]

ich installier nichts und informier euch, wenn mir mal was zustösst. Keine Performanceeinbusse

 

[Moselbär]

Na dann - warten.....

 

[DaZpoon]

Die Möglichkeit mit GRUB wird ja auch im Artikel genannt, aber als nicht breit Praxistauglich eingestuft:

Und die Nutzung eines Bootloaders wie Grub, der den Microcode noch vor der Auswahl von Windows lädt, ist keine Lösung für den Massenmarkt.

Aber wie gesagt, wenn von Intel keine neuen Codes kommen nützt auch das nix. Ich versuche heute mal eine Übersicht auf Basis der angebotenen ucodes zu erstellen wo ersichtlich ist, wann sich was für welche Prozessorfamilie geändert hat. Laut meinem Linux Kernel sind die SandyBridge ucodes von 2013.

 

[Sun_set_1]

Die Möglichkeit mit GRUB wird ja auch im Artikel genannt, aber als nicht breit Praxistauglich eingestuft:

Japp, habe ich gestern Abend auch geprüft. Bei mir sieht es so aus (nicht sicher, though) als wenn der Microcode geladen wird sobald ich Ubuntu ausgewhält habe. Dann wird der Bildschirm für eine Sekunde schwarz (signal-loss) bevor der Ladebildschirm kommt. Das ist neu.

Dann gibt es die Möglichkeit, den Microcode in Grub zu integrieren und bei Grub-Initalisierung laden zu lassen. Das wird laut Linux-Foren aber nur sehr, sehr versierten Anwendern geraten.

Dann wäre er (der ucode) theoretisch aktiv bevor der Windows OSLoader geladen wird, und somit bei Initalisierung des Kernel aktiv, was theoretisch dazu führen würde, dass der Patch dann auch aktiviert ist.

 

[The_Void]

Das wird laut Linux-Foren aber nur sehr, sehr versierten Anwendern geraten.

man braucht doch gar nicht so weit zu denken. nehmen wir mal opa mustermann, der liest, oh, für meinen rechner gibt es eine sicherheitslücke, das macht mir angst. er hat keine ahnung, vom BIOS flashen, aber sein hersteller bietet ein tool an, was nicht nur die richtige BIOS version raussucht, sondern auch das flashen unter windows übernimmt. opa mustermann ist glücklich, wenn der rechner sich beim flashen nicht aufhängt. alles klar, BIOS geflasht, neustart. was ist das? der rechner bootet nicht mehr. opa mustermann ist unglücklich, weil sein rechner nicht geht, denn er weiß nicht, daß er von IDE auf AHCI (oder was anderes, egal) umstellen muß, damit der rechner bootet. opa mustermann sucht hilfe bei einem kommerziellen helfer, der nicht nur geld nimmt, sondern opa mustermann auch nicht erklärt, was genau er denn gemacht hat. von der zeit, in der opa mustermann den rechner nicht nutzen kann, rede ich erst gar nicht.

ok, das isn konstruiertes beispiel von mir. aber ich sehe trotzdem jede menge ärger auf die user zukommen, die nicht so versiert sind, wie der schnitt, hier auf CB. manch einer weiß ja nichtmal, wie er ins BIOS kommt, das darf man nicht vergessen.

 

[Sweepi]

Hi,

BIOS update für das Skull Canyon Nuc ist auch da:
https://downloadcenter.intel.com/de/download/27436/NUCs-BIOS-Update-KYSKLi70-86A-?product=89187

 

[Sun_set_1]

@Void

Du, ich sehe das prinzipiell ähnlich.

Ich kann auch Microsoft zu 100% verstehen. Einen OSLoader baut man nicht mal ebenso um.
Selbst wenn die Code-Anpassung noch so klein ist, muss das theoretisch auf hunderten Boards und Hardwarekombinationen durchgetestet werden.

Ein kleiner Bug und das System ist hinüber. Linux hat halt den sauberen Vorteil, dass sie die Technik seit Jahren bereits implementiert haben. Das kommt ihnen jetzt zu Gute.

 

[Atlan3000]

Na dann - warten.....

Da gibts nix zu warten bei deinem System, der total verarmte Intel Konzern hat entschieden Sandy (2xxx) und Ivy (3xxx) Bridge nicht mehr mit Microcode-Updates zu versorgen. Ich habe selbst einen 2500K@4.2 der noch super läuft und ziehe deswegen die Konsequenz, nächste CPU wird definitiv ein Ryzen 2.

 

[Pisaro]

Als ob ich dafür nen Bios-Update mache. Wird ingoniert und gut. Hier wird mittlerweile genauso eine "Welle" gemacht wie bei dem bösen Spionage-Windows 10.