Rechtliche Fragen zu UEFI
-
Wie anfangen, hmm ...
Letzte Woche war ich beim Händler meines Vertrauens, um mir ein neues Notebook zu holen. Hatte auch eines gefunden, war alles drin - aber das Board war ein UEFI-Board. Berüchtigt durch SecureBoot habe ich bereits von UEFI gehört, laut Spezifikation sollte es sich hierbei um eine Reihe von Schnittstellen handeln, mit denen eine neue Art von Firmware etabliert werden kann. Allerdings bin ich ein paranoider Linux-User, der es absolut nicht abkann, wenn noch etwas anderes, vor allem unkontrolliertes Etwas zwischen Kernel und Hardware liegt.
Ich lehnte also ab und begab mich auf die Suche im Internet nach einem vernünftigen BIOS (kein UEFI-System). Und es stellte sich heraus, dass die meisten Verkäufer/Hersteller es nicht für nötig erachten, eine Angabe für die Firmware des Boards auf der Produktseite zu machen. Das tollste aber war, dass selbst auf Nachfrage der Vertrieb keine Ahnung zu haben scheint, wie man dies prüft oder welche technischen Daten die Produkte, die man so vertreibt, haben. Einen Fefe zu pullen wäre einfach, aber aufgrund der Umstände wäre dies eher eine Tragödie denn eine Komödie.
Auf diversen Seiten und im Bekanntenkreis habe ich nach Informationen für UEFI gesucht, denn eventuell hätte ich mich mit UEFI anfreunden können. Was ich aber hörte, hat mich keinesfalls ermutigt, diesen Standard - oder zumindest die Firmen, die den Standard umsetzen - zu unterstützen. Eventuell kann jemand mit diesem Halbwissen aufräumen? Ich rede von der gesetzlichen Lage in Deutschland.
Folgende Punkte bleiben für mich offen:
1. Das Wort "Unified" in der Bezeichnung impliziert, dass die Schnittstelle einheitlich ist. Das sollte im Grunde bedeuten, dass man verschiedene Images von verschiedenen Herstellern verwenden kann, um die Firmware auszutauschen. Ist ein Mainboard-Hersteller verpflichtet, dass, wenn er mit im Boot der UEFI-Group sitzt, die in UEFI beschriebenen Features angeboten werden? Als Beispiel sage ich dreist, dass ich mein Mainboard mit gültigen Images flashe, und danach funktioniert das Board nicht mehr, weil der Standard fehlerhaft implementiert worden ist (wie bei Samsung, wo schon das Booten eines Linux-Kernels das Image vernichten kann und die Koreaner sich einfach mal weigern, Schadensersatz zu leisten).
Laut einem Kollegen scheint das häufiger der Fall zu sein. Ist das Rechtens?2. Wenn auf einer Internetseite dieses technische Angabe fehlt, ist die Firma abmahnfähig? Bspw. wird von der EU verlangt, dass Grundpreisangaben bei Flüssigkeiten angezeigt werden müssen, sonst kann die Firma hinter dem Angebot abgemahnt werden. Ist das beim Weglassen dieser technischen Angabe ebenfalls möglich?
3. Wenn ich ein bestimmtes Notebook kaufe und aufgrund der fehlendenen Angabe erst bei der Installation meines Systems bemerke, dass es sich um ein UEFI-Board handelt, und ich eine Konfiguration verwenden will, die ein minimalistisches System benötigt (Treiber sollen nur vom Kernel gestellt werden, oder ich verwende ein 32-Bit-System, das nicht gebootet werden kann, oder ich kompiliere einen Kernel, der einfach mal kein UEFI unterstützen soll, weil ich halt immer davon ausgehe, dass ich ein valides BIOS habe) - MUSS der Verkäufer die Ware dann zurücknehmen, weil diese Angabe fehlt?
Ich will sichergehen, dass ich nicht viel Geld aus dem Fenster werfe, weil keine Informationen verfügbar sind. Nein, ich reduziere UEFI _nicht_ auf SecureBoot, ja, diesen Thread habe ich durchgelesen:
http://www.c-plusplus.net/forum/315630-20
Ich weiß, in der Regel kann man Linux auf UEFI-Boards verwenden, es geht mir um die rechtliche Absicherung, wenn mal gar nichts funktioniert.
-
1. Die einheitliche Schnittstelle befindet sich zwischen der Firmware und der Software. Wie die Firmware diese Schnittstelle implementiert ist immer noch von der jeweiligen Hardware abhängig und dürfte nur schwer austauschbar sein.
2/3. Ich weiß zwar nicht wie das bei Laptops oder anderen Systemen mit vorinstalliertem OS ist, aber viele PC Boards mit UEFI haben eine BIOS Emulation. Praktisch ist der Unterschied nur, dass du deine BIOS Einstellungen grafisch mit der Maus einstellen kannst. Da dürfte keine Kennzeichnungspflicht für nötig sein.
-
Tobiking2 schrieb:
1. Die einheitliche Schnittstelle befindet sich zwischen der Firmware und der Software. Wie die Firmware diese Schnittstelle implementiert ist immer noch von der jeweiligen Hardware abhängig und dürfte nur schwer austauschbar sein.
Zwischen Firmware und Software oder Firmware und Kernel? Bei ersterem ergibt das keinen Sinn, denn zwischen Firmware und Software liegt ja das Betriebssystem mit Kernel.
Und der Kernel wird wohl immer eine eigene Schnittstelle bieten.
Sollte es das Zweite sein: meinst du damit sowas ähnliches wie ACPI? Aber DAS ist ja einheitlich (also, zumindest weitgehend). Sorry, aber mit der Aussage habe ich so ein paar Probleme.Tobiking2 schrieb:
2/3. Ich weiß zwar nicht wie das bei Laptops oder anderen Systemen mit vorinstalliertem OS ist, aber viele PC Boards mit UEFI haben eine BIOS Emulation. Praktisch ist der Unterschied nur, dass du deine BIOS Einstellungen grafisch mit der Maus einstellen kannst. Da dürfte keine Kennzeichnungspflicht für nötig sein.
Über den sog. Legacy Mode weiß ich bereits Bescheid. Aber würde dieser nicht auch wieder eine zusätzliche Schicht etablieren, weil das BIOS eben emuliert werden muss? Und wäre hier auch wieder nicht die Möglichkeit, dort Module unter dem Kernel zu schieben (als Beispiel eigener network stack des UEFI)?
-
UEFI ist mittlerweile wohl schon seit einiger Zeit Standard. SecureBoot lässt sich normalerweise abschalten, wobei ich mir nicht vorstellen kann, dass die bekannteren Linux Distros damit Probleme haben sollten, wieso also auf SecureBoot verzichten, wenn es funktioniert...
-
Weil ich keine Lust habe, immer eine neue Signatur einzutragen, wenn ich einen neuen Kernel kompiliert habe.
Wenn ich als Cracker die Möglichkeit habe, das Initramfs zu modifzieren oder zu überschreiben, habe ich eh gewonnen - da erstelle ich mir direkt einen zweiten Admin oder trage einen SSH-Schlüssel ein und installiere ein Skript, über das ich Zugriff auf den Rechner erhalte, wenn das Ding hochfährt. SecureBoot ist ein (gescheiteter? mal sehen) Versuch von MS, nur ihre Systeme zu vertreiben, und begründet wird es halt mit Sicherheit. Und es gibt genug Leute, die das glauben.Um SB geht's hier aber auch gar nicht.
-
Und nur, weils Standard ist, muss es ja nicht etabliert werden. Ist schon oft genug passiert - ich werde, falls mir dieser neue Standard nicht gefällt, halt mit dem Geldbeutel wählen und diese Systeme links liegen lassen. Wenn ich dann auf ältere Hardware umsteigen muss, um noch richtiges BIOS zu bekommen, ist das halt so. Kann ja nicht sein, dass man den Bloat, den man die Jahre rumgeschleppt hat, jetzt mit UEFI so richtig versemmelt ... Toll wär natürlich, wenn sich sogar ein freies UEFI installieren lassen könnte, das wäre ein Schritt in die richtige Richtung.
Ich meine, es ist das gleiche Spiel wie unter BIOS mit Windows und Linux. Die Plattform muss den Kernel ausführen können, wenn er die Hardware unterstützt, und er benötigt den kompletten Zugriff auf die Hardware, weil man dem Code vertraut/misstraut. Wenn man ein unfreies/nicht einsehbares System mit erweiterbaren Modulen unter den Kernel schiebt, ist die gesamte Sicherheit, die man sich in einem System aufgebaut hat, für die Katz. Ist wie Verschlüsselung unter Windows.
Im Grunde handelt es sich um ein zweites Betriebssystem, wenn das nicht frei ist ... haben die natürlich ganz toll hingekriegt. Aber was reg ich mich auf ...
-
Das was du ansprichst ist sogar ein Grund für Secure Boot. Grundsätzlich kann man sagen, dass Software, die auf der tieferen Ebene ausgeführt wird, gewinnt. Der höheren Ebene kann ein normales System vorgegaukelt werden, während von Außen analysiert und manipuliert wird.
Beim BIOS ist die tiefste Ebene, die man problemlos beschreiben kann, der MBR bzw. Bootloader. Schadsoftware die im MBR steht hat damit praktisch schon gewonnen.
Bei UEFI prüft die Hardware/Firmware ob der Code, der zuerst ausgeführt wird (und auch den der extern geladen wird), vertrauenswürdig ist. Sicherlich wird das System nicht 100%ig sicher sein und es ist auch immer so eine Sache, wen der Hersteller als vertrauenswürdig einstuft. Aber wenn irgendwo für Sicherheit gesorgt werden kann, dann eine Ebene näher an der Hardware.
Wenn du dir sorgen über eine proprietäre Firmware machst, könntest du dir mal coreboot angucken. Für bestimmte Boards soll das funktionieren und eine UEFI Implementierung gibt es auch.
-
Tobiking2 schrieb:
Das was du ansprichst ist sogar ein Grund für Secure Boot. Grundsätzlich kann man sagen, dass Software, die auf der tieferen Ebene ausgeführt wird, gewinnt. Der höheren Ebene kann ein normales System vorgegaukelt werden, während von Außen analysiert und manipuliert wird.
Ja, das ist auch meine Aussage.
Tobiking2 schrieb:
Beim BIOS ist die tiefste Ebene, die man problemlos beschreiben kann, der MBR bzw. Bootloader. Schadsoftware die im MBR steht hat damit praktisch schon gewonnen.
Und das ist es schon.
Was brauchst du, damit Schadcode in den MBR geschrieben werden kann - also in die ersten 512 Bytes von /dev/sdx? Root-Rechte. Aber wenn ich bereits Root-Rechte habe, werde ich mich als Cracker bestimmt nicht damit abgeben, in den MBR zu schreiben, da habe ich ganz andere Ideen, die sofort wirken.Tobiking2 schrieb:
Bei UEFI prüft die Hardware/Firmware ob der Code, der zuerst ausgeführt wird (und auch den der extern geladen wird), vertrauenswürdig ist. Sicherlich wird das System nicht 100%ig sicher sein und es ist auch immer so eine Sache, wen der Hersteller als vertrauenswürdig einstuft. Aber wenn irgendwo für Sicherheit gesorgt werden kann, dann eine Ebene näher an der Hardware.
Und wieder, mit Sicherheit wird das gerne begründet. Wenn du aber nicht über den PC/dessen Firmware mündig bist (und klar, ein Großteil der Leute brauchen die Mündigkeit und die Kontrolle nicht - ich aber schon ;)), wird "von außen" auf deine Sicherheit geachtet - und das schränkt deine Freiheit ein, mit der Maschine das zu machen, was du willst. Und das ist mein Problem - ich will experimentieren können. Ich will:
Tobiking2 schrieb:
Wenn du dir sorgen über eine proprietäre Firmware machst, könntest du dir mal coreboot angucken. Für bestimmte Boards soll das funktionieren und eine UEFI Implementierung gibt es auch.
an sich genau das. Und hey, mein eigenes BIOS auf der Basis von Coreboot zu programmieren - das hört sich echt nicht schlecht an.
Aber ich fürchte, bei OpenSource-SW wird der Hersteller keine Gewährleistung übernehmen, oder?
-
Sicherheitssysteme laufen ueber Ringe - Ringe an Sicherheitsvorkehrungen die nacheinander ueberwunden werden muessen.
Ein einzelner Ring bietet dabei nie 100% Schutz und man kann alles umgehen. Aber desto mehr Ringe ein angreifer umgehen muss, desto schwerer hat er es. Deshalb benutzt man ja nicht SecureBoot und sonst nichts. Es ist einfach ein weiterer Schutzmechanismus.
Wenn du ihn nicht benutzen willst, dann deaktivierst du es. Und fertig.
-
Mal ne ganz andere Frage.
Wie wird denn eigentlich die UEFI Firmware davor geschützt, dass sie mit Schadecode überschrieben oder manipuliert wird?
Beim BIOS war das immer so:
Die ersten MB hatten das BIOS in einem ROM, damit war es unveränderlich.
Später kam das BIOS auf EEPROMs, hierzu mußte man, mit Ausnahme der Intel 430 TX Boards, auf dem Mainboard einen Jumper setzen um das EEPROM in den Schreibmodus zu versetzen, ehe man das BIOS updaten konnte.
Aufgrund von Einsparmöglichkeiten und dem administrativen Aufwand dafür in großen Unternehmen viel dann aber auch der HW Jumper weg und es wurde ein SW Tool für DOS ausgeliefert, mit dem man ein anderes BIOS in das EEPROM laden konnte und damit man das tun konnte, mußte man im BIOS erstmal einen "schreiben erlaubt" Modus triggert.
Wie dabei Originalität des Updates sichergestellt wurde und was dieser reine SW BIOS Schreibschutz taugte, ist mir nicht bekannt.Noch ein paar Jahre wurde dieses BIOS Tool auch für Windows ausgeliefert, womit die Sicherheit noch weiter untergraben wurde, denn das Tool war nur so sicher wie die Sicherheit unter Windows gewährleistet werden konnte.
Später ersetzte man dann das EEPROM durch Flashspeicher, damit stieg die Größe des Verfügbaren Platzes, der für ein BIOS zur Verfügung stand und das TOOL zum
Updaten des BIOS wanderte direkt auf den Flashspeicher und konnte somit gebootet werden.
Wie auch hier der Flashspeicher vor Schreibzugriffen geschützt wurde, ist unklar, aber hier wäre zumindest die Möglichkeit gegeben, dass das integrierte Tool die upzudatende Datei erst einmal anhand einer Signatur mithilfe von Kryptografiemethoden prüft. Ob das tatsächlich genutzt wurde, ist mir nicht bekannt.
Beim DOS & Windows Tool dürfte das aber umgehbar sein, weil wenn überhaupt nur das Tool die Signatur prüft und ein anderes Schreibprogramm tut das nicht.Tja und heute sind wir bei UEFI, ein halbes OS mit großem Flashspeicher auf dem Mainboard und wie wird da sichergestellt, dass dieser manipuliert wird?
Ich persönlich würde mir ja die Zeiten mit Jumper als Hardwareschreibschutz zurückwünschen, aber die Industrie will das nicht, weil der administrative Aufwand für Unternehmen wohl zu hoch ist.
-
-
Update:
Für modernere Mainboardchipsätze gibt es sogar BIOS Viren die das BIOS manipulieren, sofern es ein Award BIOS ist:
http://www.heise.de/security/meldung/Die-Rueckkehr-des-BIOS-Trojaners-1341262.html
Da ist also schon der Worst Case Fall eingetreten.
-
Hier hat das ganze Problem jemand schön zusammengefasst:
-
Mit Sicherheit überschrie schrieb:
Wie wird denn eigentlich die UEFI Firmware davor geschützt, dass sie mit Schadecode überschrieben oder manipuliert wird?
SecureBoot...
-
dot schrieb:
Mit Sicherheit überschrie schrieb:
Wie wird denn eigentlich die UEFI Firmware davor geschützt, dass sie mit Schadecode überschrieben oder manipuliert wird?
SecureBoot...
Hm, in der Wikipedia steht das so, als hätte SecureBoot nur Nachteile, aber keine Vorteile.
http://de.wikipedia.org/wiki/Secure_Boot#Unified_EFI_.28UEFI.29
-
aha, na dann kann man wohl nix machen...
-
dot schrieb:
Mit Sicherheit überschrie schrieb:
Wie wird denn eigentlich die UEFI Firmware davor geschützt, dass sie mit Schadecode überschrieben oder manipuliert wird?
SecureBoot...
Und inwiefern schützte SecureBoot eigentlich die Notebooks von Samsung deren UEFI mit kaum speziell präparierter Software sowohl unter Linux als auch Windows manipuliert werden konnte?
Die Linux Kernel Entwickler haben genau das ja durch Zufall herausgefunden.Wo war da der SecureBoot Schutz?
War auf diesen Samsung Rechnern Secure Boot immer abgeschaltet oder gar nicht vorhanden?
-
dot schrieb:
aha, na dann kann man wohl nix machen...
Naja, das ist durchaus ein Problem und ein Fehler der Wikipedia.
Denn die User werden denken, SecureBoot bringt nichts, hat für sie nur Nachteile und dann werden sie es abschalten und das System ist offen* für Schadcode.
Man sollte den Wikipedia Artikel also ändern, um schlimmeres zu verhindern.
Man sollte dem Nutzer klar machen, das und wofür SecureBoot gut und auch notwendig ist. Vorausgesetzt natürlich, es erfüllt den Zweck, den du mir hier auf meine Frage zu glauben denken möchtest.* Jetzt mal unabhängig von der Frage bezüglich des Samsung Fall.
-
Was genau meinst du mit dem Samsung Fall? Das wo Linux Booten den Laptop unbrauchbar macht? Laut dem erstem Hit bei google war das ein Samsung Bug und hatte nix mit SecureBoot zu tun...
-
dot schrieb:
Was genau meinst du mit dem Samsung Fall? Das wo Linux Booten den Laptop unbrauchbar macht?
Das ist nicht der Fehler von Linux.
Laut dem erstem Hit bei google war das ein Samsung Bug und hatte nix mit SecureBoot zu tun...
Ja, es ist ein Bug seitens Samsung, allerdings darf der nicht auftreten wenn SecureBoot den Schreibzugriff auf UEFI verhindern soll.
Das ganze UEFI konnte dadurch kaputtgefrickelt werden und natürlich standen dazu Schreibzugriffe auf den Flashspeicher statt.
Wo war hier SecureBoot um einzugreifen?
