flaphoschi schrieb:
Sollte man eigene Zertifikate einspielen können - was bei Secure Boot nicht garantiert ist - fällt man ebenso.
Wenn der Plattformschlüssel in den aktiven Variablen vorhanden ist (User Mode), müssen neue Zertifikate prinzipiell von einem der bereits hinterlegten Owner stammen. Unbekannte bleiben also draußen. Das gilt wohlgemerkt zur Laufzeit aus einem laufenden System heraus.
Deswegen ist es bspw. in diesem Szenario unter Linux mit
efi-updatevar nur schwer bis gar nicht möglich, fremde Zertifikate in die aktiven Variablen reinzuladen.
Aus dem UEFI heraus kann man bei im Grunde allen Boards auf dem DIY-Markt neue Zertifikate einspielen, unabhängig von den dort hinterlegten Zertifikats-Ownern und dazu braucht der Angreifer physischen Zugriff.
Aber wenn der Angreifer physischen Zugriff auf die Maschine hat, hat man sowieso ganz andere Probleme möchte ich meinen.
Und für den Fall dass sich der Hersteller die Mühe gespart hat, eine voll funktionsfähige Schlüsselverwaltung ins UEFI zu integrieren (Notebooks haben hier meist das nachsehen), dann kann man aber dort zumindest das System in den Setup Mode versetzen, also alle aktiven Variablen löschen. Dann lassen sich auch zur Laufzeit wieder mit
efi-updatevar oder
sbctl Schlüssel und Hashes dort reinladen. Aber selbst dafür brauchts ja physischen Zugriff. Und sobald der Plattformschlüssel dort drin ist, geht das System wieder in den User Mode und begrenzt hart, welche Schlüssel zur Laufzeit dort rein dürfen.
Klar, wenn die Quelle (Microsoft) übernommen wurde, dann schaut man in die Röhre und der Angreifer kann über Windows Update die neuen schädlichen Zertifikate ausliefern. Aber dafür gibt's ein Gegenmittel und nennt sich: Clear CMOS.
Hilft halt nur nicht, wenn die dann in den kumulativen Updates drin sind.
Blöd isses nur, wenn die Quelle MSI, ASUS, Asrock und Co. heißen und diese ein UEFI-Update mit den schädlichen Schlüsseln ausliefern. Dann sitzen die im System drin und MÜSSEN über die dbx revoked werden.
