Reinarden
Anmeldungsdatum: 29. September 2014
Beiträge: 1044
|
Kann ein BIOS-/UEFI-Fachmann das folgende bitte mal auf deutsch für normale Benutzer erklären, die zwar Ahnung haben von Bit und Bytes und (grundsätzlichem) Programmieren, aber nicht viel von BIOS und UEFI ? Danke! Phoronix: Google even fear Intel ME, reduce their attack vector with NERF Die wichtigsten Sätze scheinen mir zu sein:
NERF is short for the Non-Extensible Reduced Firmware and is their effort to replace most of the UEFI firmware with a small Linux kernel and initramfs while their custom portions of the code are written in the Go programming language. NERF is developed by Ron Minnich and Google's other Coreboot developers. Minnich was talking about their NERF project at this week's Embedded European Linux Conference. NERF delivers "Linux performance and reliability in firmware" as well as eliminates all post-boot activity of UEFI and the Management Engine, rather than allowing it to run concurrently in the background. Currently the NERF effort is focused on Intel hardware while the Coreboot developers acknowledge the latest AMD chips are closed up too and "Don’t believe all you read about Ryzen."
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Golem bringt das auf Deutsch: https://www.golem.de/news/freie-linux-firmware-google-will-server-ohne-intel-me-und-uefi-1710-130840.html Ja, nach dieser Meldung will Google ME totlegen und UEFI durch eine Minimallösung ersetzen.
|
Reinarden
(Themenstarter)
Anmeldungsdatum: 29. September 2014
Beiträge: 1044
|
Sehr informativ der Golem-Artikel, danke für den Verweis!
So läuft die sogenannte Intel Management Engine (ME) auf einem vom Rest des Systems getrennten Prozessor, hat aber im Prinzip Vollzugriff auf das System und damit zum Beispiel auch auf Passwörter, ohne dass etwa ein Linux-Betriebssystem dies bemerken könnte. [..] Quasi eine Ebene höher als ME läuft dann das UEFI. Dieses System nutzt die gleiche CPU wie das Linux-Betriebssystem, hat laut Minnich einen ähnlich komplexen Kernel und besteht außerdem aus Millionen Zeilen von Code. Zudem laufe das UEFI immer weiter, so lange die Rechner angeschaltet seien.
Das verstehe nun auch ich: Hinter unserem eigentlichen Betriebssystem (Ubuntu) läuft also ständig das fette UEFI-Schattenbetriebssystem, und dahinter läuft dann noch das ebenfalls fette Schattenbetriebssystem „ME“ im Falle von Intel-Prozessoren mit ME. Was für ein „Angriffsvektor”-Alptraum, vom Kontrollverlust des Benutzers gar nicht zu reden. Darum schalte ich auf allen PCs, wo ich was installieren muß, immer UEFI als erstes ab, falls das geht (ging früher immer, neuerdings nicht mehr immer.)
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Reinarden schrieb: Darum schalte ich auf allen PCs, wo ich was installieren muß, immer UEFI als erstes ab, falls das geht (ging früher immer, neuerdings nicht mehr immer.)
Das kannst du nicht (wenn du es nicht gerade z.B. durch Coreboot ersetzen kannst) - der BIOS-Kompatibilitätsmodus hat keinen Einfluss darauf, was das UEFI/BIOS im Hintergrund tut und ein proprietäres BIOS hat prinzipiell ähnliche Probleme hinsichtlich der Anfälligkeit, nur ist es da normalerweise etwas schwieriger Code einzuschleusen.
|
Reinarden
(Themenstarter)
Anmeldungsdatum: 29. September 2014
Beiträge: 1044
|
seahawk1986 schrieb: Reinarden schrieb: Darum schalte ich auf allen PCs, wo ich was installieren muß, immer UEFI als erstes ab, falls das geht (ging früher immer, neuerdings nicht mehr immer.)
Das kannst du nicht (wenn du es nicht gerade z.B. durch Coreboot ersetzen kannst) - der BIOS-Kompatibilitätsmodus hat keinen Einfluss darauf, was das UEFI/BIOS im Hintergrund tut
Ich verstehe. Schade.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
Reinarden schrieb: Sehr informativ der Golem-Artikel, danke für den Verweis!
Es geht so mit den Informationen. Positive Seiten von UEFI und Intel ME werden da beispielsweise gar nicht erwähnt. So läuft die sogenannte Intel Management Engine (ME) auf einem vom Rest des Systems getrennten Prozessor, hat aber im Prinzip Vollzugriff auf das System und damit zum Beispiel auch auf Passwörter, ohne dass etwa ein Linux-Betriebssystem dies bemerken könnte.
Ich denke, das gleiche trifft auch auf UEFI und BIOS zu. [..] Quasi eine Ebene höher als ME läuft dann das UEFI. Dieses System nutzt die gleiche CPU wie das Linux-Betriebssystem, hat laut Minnich einen ähnlich komplexen Kernel und besteht außerdem aus Millionen Zeilen von Code. Zudem laufe das UEFI immer weiter, so lange die Rechner angeschaltet seien.
Auch ein BIOS läuft die ganze Zeit.
Was für ein „Angriffsvektor”-Alptraum, vom Kontrollverlust des Benutzers gar nicht zu reden.
Ich denke für Angreifer ist das programmieren für spezifische UEFI-Versionen wohl auch kein Vergnügen. Entweder der Angreifer kennt dein UEFI und entwickelt entsprechende Malware, um dich gezielt anzugreifen oder du wirst eher zufällig infiziert. Reinarden schrieb: seahawk1986 schrieb: Reinarden schrieb: Darum schalte ich auf allen PCs, wo ich was installieren muß, immer UEFI als erstes ab, falls das geht (ging früher immer, neuerdings nicht mehr immer.)
Das kannst du nicht (wenn du es nicht gerade z.B. durch Coreboot ersetzen kannst) - der BIOS-Kompatibilitätsmodus hat keinen Einfluss darauf, was das UEFI/BIOS im Hintergrund tut
Ich verstehe. Schade.
Coreboot würde das Problem auch nicht lösen, höchstens etwas entschärfen.
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
apt-ghetto schrieb: Ich denke für Angreifer ist das programmieren für spezifische UEFI-Versionen wohl auch kein Vergnügen. Entweder der Angreifer kennt dein UEFI und entwickelt entsprechende Malware, um dich gezielt anzugreifen oder du wirst eher zufällig infiziert.
UEFI ist standardisiert. Eine UEFI-Malware läuft theoretisch auf allen UEFI-basierten Rechnern. Aber trotz allem ist das nur ein theoretischer Angriffsvektor, da es deutlich einfacher ist das Betriebssystem selbst zu infizieren.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
glasenisback schrieb: apt-ghetto schrieb: Ich denke für Angreifer ist das programmieren für spezifische UEFI-Versionen wohl auch kein Vergnügen. Entweder der Angreifer kennt dein UEFI und entwickelt entsprechende Malware, um dich gezielt anzugreifen oder du wirst eher zufällig infiziert.
UEFI ist standardisiert. Eine UEFI-Malware läuft theoretisch auf allen UEFI-basierten Rechnern. Aber trotz allem ist das nur ein theoretischer Angriffsvektor, da es deutlich einfacher ist das Betriebssystem selbst zu infizieren.
Die Schnittstelle ist mehr oder weniger standardisiert. Die jeweilige Implementierung der Schnittstelle ist dann meiner Meinung nach von Hersteller zu Hersteller ziemlich verschieden.
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
glasenisback schrieb: apt-ghetto schrieb:
UEFI ist standardisiert. Eine UEFI-Malware läuft theoretisch auf allen UEFI-basierten Rechnern. Aber trotz allem ist das nur ein theoretischer Angriffsvektor, da es deutlich einfacher ist das Betriebssystem selbst zu infizieren.
Schau dir die Mainboards mit der recht neuartigen Netzwerk-/WiFi-Updatefunktion für den BIOS-Flash an, bei dem Updates vollautomatisch eingespielt werden (können). Irgendwann wird ein Angreifer sich vielleicht denken, hach, ich machs einfach hintenrum und flashe allen für meine Schadware+Firmware-inclusive, passenden Boards mal einige hübsche Extras drauf. Das Aldi-PC-UEFI reicht ja schon, dieses Drecks-BIOS, was keiner mag und von dem mir der Name adhoc gerade entfallen ist, zum Beispiel. Auf jedem Schrott ist das ja drauf. Ahhh ja richtig... InsydeH2O!! Das Grauen hat einen Namen! Ist das ein Superbeispiel? Der Angreifer darf natürlich die erweiterten Funktionen, die alle ANDEREN auf ihren ECHTEN unbeschnittenen Mainboards seit Jahren genießen, gerne aus Faulheit mit draufflashen, merkt ja eh keiner. ^^ Das ganze garniert man dann mit der nicht-möglich-ein-älteres-UEFI-zu-flashen-Vorgabe des Mainboardherstellers und Zack. Schon hast du ein echt tolles System an der Hand, welches nur noch vom Hersteller selbst gefixt werden könnte. Oder sehe ich das Ganze dramatischer, als es zu sein scheint?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Zu den möglichen Gefahren bei Intel CPUs und deren Firmware: Joanna Rutkowska: Intel x86 considered harmful als PDF: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf Die Produkte anderer Hersteller enthalten jedoch auch Überraschungen.
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
Dogeater schrieb: Oder sehe ich das Ganze dramatischer, als es zu sein scheint?
Meiner Meinung nach ja, da man zum flashen weitgehende Admin-Rechte benötigt. Da ist es eben einfacher einen Windows-PC mit "normaler" Malware zu infizieren. Vor allem weil man als Malware-Entwickler nicht sicher sein kann, dass diese auch auf wirklich jedem Mainboard funktioniert bzw. sich die Malware überhaupt in die Firmware integrieren lässt. Malware lohnt sich nur in der Masse. Die neuesten Spielereien benötigen nur noch einen Browser: http://www.nerdcore.de/2017/09/27/in-browser-bitcoin-mining-als-alternative-zu-banner-werbung/ Ein anderes Thema sind Geheimdienste oder anderer staatliche Behörden: Für diese wäre eine solche "Super-Malware" in der Firmware natürlich perfekt, da sie so gut wie nicht zu entdecken ist und sich in vielen Fällen auch für einen einzelnen Rechner lohnt.
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
Geheimdienste wollte ich sogar noch dazuschreiben, hatte es aber gelassen. Ja das stimmt natürlich. Wenn eine absichtliche Lücke eingebaut wurde, dann schlummert da ein neuer UEFI-Wannacry halt so vor sich hin. Ich meine bei heise gab es da mal einen Artikel. Ich suche ihn jetzt aber nicht raus.
|
Reinarden
(Themenstarter)
Anmeldungsdatum: 29. September 2014
Beiträge: 1044
|
kB schrieb: Zu den möglichen Gefahren bei Intel CPUs und deren Firmware: Joanna Rutkowska: Intel x86 considered harmful als PDF: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
Auch dieser zweite Verweis von Dir enthält erstklassige Ausführungen. Vielen Dank dafür, KB! Zusammenfassend besonders erhellend ist im kurzen Kapitel „4) The Intel Management Engine (ME)“ der erste Abschnitt „Problem #1: zombification of general-purpose OSes?” Da wird klar, wohin die Reise geht (bei Intel und auch bei AMD).
|