Rechtliche Fragen zu UEFI
-
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?
