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