Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › UEFI Secure Boot: Eigene Schlüssel…

Secure Boot = null Sicherheitsgewinn?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Secure Boot = null Sicherheitsgewinn?

    Autor: Schnarchnase 08.10.12 - 17:55

    Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die beliebige andere Loader starten können? Warum können nicht gleich alle ihre Signaturen einreichen?

    Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

  2. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: kazhar 08.10.12 - 18:22

    Was mir bei der ganzen Geschichte nicht klar ist...

    MUSS der Bootloader einen signierten Kernel nachladen? Gibt es eine Hardware/Firmware Funktion, die das das verhindert?

    Ansonsten könnte z.b. ein bösartiges Rootkit einen signierten Bootloader verwenden, um einen unsignierten - weil gepatchten - Kernel nachzuladen.
    Wie "schwer" es ist, an eine Signatur zu kommen liest man ja ab und zu...

  3. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: nautsch 08.10.12 - 18:52

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die
    > beliebige andere Loader starten können? Warum können nicht gleich alle ihre
    > Signaturen einreichen?
    >
    > Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

    Das ganze basiert auf Vertrauen. Du musst demjenigen, der den Bootloader signiert vertrauen, dass er nur bootloader signiert, die nur signierte Kernel laden. Das heißt, wenn du dein BIOS/UEFI so konfigurierst, dass es nur von MS/Fedora signierte Bootloader lädt (indem du den MS/Fedora Key in deinem BIOS hinterlegst/nicht löschst), vertraust du MS/Fedora, dass sie sicherstellen, dass der Bootloader in Ordnung ist. Das gleiche gilt für Bootloader, die von irgendwem anders signiert sind.

    MS/Fedora darf eigentlich keinen Bootloader signieren, der die die Kette nicht aufrechterhält. Der Bootloader prüft also deinen Kernel und der Kernel jeden Treiber, den du lädst. Wenn ein Teil in der Kette einen Fehler hat, ist die Sicherheit futsch. Wenn jemand zu freigiebig mit Signaturen ist, ist die Sicherheit futsch. Wenn du dem Signierer nicht vertraust, war nie Sicherheit gegeben.



    2 mal bearbeitet, zuletzt am 08.10.12 18:55 durch nautsch.

  4. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 08.10.12 - 19:16

    Selbst wenn Du die Kette aufrecht erhalten würdest, was verfassungswidrig ist und gegen das Grundrecht auf Integrität datenverarbeitender Systeme verstößt, so würde das keinen Sicherheitsgewinn bringen, da alle Angriffe die Du sonst machen könntest, physikalischen Zugriff erfordern. So bald zu physikalischen Zugriff hast, kannst Du alles machen.

    Secure Boot dient ausschließlich dazu das Starten von nicht Windows auf Windows ARM-Geräten zu verhindern. Es hat keinerlei Sicherheitsgewinn.

  5. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: chrulri 08.10.12 - 19:32

    Verfassungswidrig?! Ihr habt ja nicht einmal eine Verfassung... Grundrecht auf Integrität datenverarbeitender Systeme.. Grundrecht ?! ... Ich glaub ein Schwein pfeift die 32. Beethoven Sonate.

  6. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Schnarchnase 08.10.12 - 20:24

    chrulri schrieb:
    --------------------------------------------------------------------------------
    > Verfassungswidrig?! Ihr habt ja nicht einmal eine Verfassung...

    Das Grundgesetz ist eine Verfassung.

    > Grundrecht auf Integrität datenverarbeitender Systeme.. Grundrecht ?!

    Ein solches Grundrecht gibt es in der Tat:
    [de.wikipedia.org]

    Ich bin mir allerdings nicht sicher inwiefern das hier anwendbar ist.

  7. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 08.10.12 - 21:03

    Naja, durch die Codesignierung kann ich nicht mehr darüber bestimmen, welche Programme auf meinem Rechner laufen. Ich kann somit nicht davon ausgehen, dass mein Rechner das macht was ich will.

    Zwangsweise Codesignierung nimmt einem nunmal die Kontrolle über seien eigenen Rechner.

  8. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: F4yt 08.10.12 - 23:00

    Das ganze erinnert mich halt an den "Wirbel" um DNT. Ist beides mehr Placebo, als dass es wirklich was bringt.

    Zumindest war es in den vergangenen Jahren verdächtig ruhig um das Thema "Kernel spioniert Benutzer aus".

    Oder gibt's einen anderen Grund für SecureBoot abgesehen von "Ich starte nurnoch Windows"?

  9. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 07:22

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die
    > beliebige andere Loader starten können? Warum können nicht gleich alle ihre
    > Signaturen einreichen?
    >
    > Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

    Ich glaube der Sicherheitsgewinn ist, dass ein rootkit sich nicht unbemerkt vorbei schleichen kann. Denn wenn eines installiert wird, dann fragt shim nach ob der neue Key hinzugefügt werden soll. Aber da sehr viele Menschen bei alles ja sagen wird es nur Menschen schützen, die etwas nachdenken. Und die sind im Computer bereich immer seltener (sieht man ja an den leuten die alle möglichen Android Maleware installieren und das obwohl genau die rechte angezeigt werden und man software installationen außerhalb des Markets erlauben muss)
    Für den Privat Nutzer bedeutet es halt einen weiteren Schritt bei der Installation und für "Advance" Nutzer, die auch Bootloader / kernel selber compilieren kommt halt noch hinzu, dass sie Schlüssel erzeugen müssen und damit alles signieren.
    Interessant sieht es natürlich bei Firmen aus, die alles mittels Netzwerk boot installieren, wie bekommen die den Key rein, muss da zu jedem Computer einer hinlaufen und den Key bestätigen?

  10. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 09.10.12 - 07:34

    Wozu dann ein Rootkit benutzen? Wenn Du ein Rootkit drin hast, so kommt das erst nach Secure Boot, sprich Du was etwas das danach kommt, schon ausgehebelt.

    Secure Boot schützt nur den Bootprozess, und wenn Du in den eingreifen kannst, kannst Du auch zusätzliche Hardwareeinbauen, oder andere Software auf dem Service Controller starten. Du könntest sogar das komplett Mainboard austauschen, oder unauffällig einen kleinen HDMI-Sender installieren und den Bildschirminhalt abgreifen... etc.

    Secure Boot wurde nur dazu geschaffen, um das Starten von nicht-Windows Betriebssystemen zu erschweren, bzw. zu verhindern.

  11. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 07:41

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Wozu dann ein Rootkit benutzen? Wenn Du ein Rootkit drin hast, so kommt das
    > erst nach Secure Boot, sprich Du was etwas das danach kommt, schon
    > ausgehebelt.
    >
    ja sobald es installiert ist, kann es alles machen, es ist halt eine zusätzliche ebene die verhindert, dass es installiert wird. Da die Kette ja ist bei Linux UEFI -> SHIM -> Grub -> Kernel bzw. UEFI -> Windows Bootloader -> Windows Kernel und wenn alles signiert ist, kann sich das Rootkit da schwer einschleichen. Denn im Idealfall kommt das Rootkit sehr früh, so dass es sich auch gut verstecken kann (wenn das Rootkit vor Grub bzw. dem Windows Blootloader kommt währe es sehr schwer zu verstecken)

    > Secure Boot schützt nur den Bootprozess, und wenn Du in den eingreifen
    > kannst, kannst Du auch zusätzliche Hardwareeinbauen, oder andere Software
    > auf dem Service Controller starten. Du könntest sogar das komplett
    > Mainboard austauschen, oder unauffällig einen kleinen HDMI-Sender
    > installieren und den Bildschirminhalt abgreifen... etc.
    >
    > Secure Boot wurde nur dazu geschaffen, um das Starten von nicht-Windows
    > Betriebssystemen zu erschweren, bzw. zu verhindern.

    Tut es in der jetzigen ausführung nicht. Es ist abschaltbar (bei x86er Systemen sogar Pflicht) und offensichtlich wird es mit Shim relativ leicht auch Linux systeme zu starten. Wobei ich ehrlich dachte der Hauptgrund war zu verhindern, dass sich systeme über ein Modifizierten Grub als OEM Systeme ausgeben, die keine Aktivierung brauchen und so eine kopierte Windows Installation erlauben

  12. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 09.10.12 - 08:01

    OK, nehmen wir mal einen üblichen Angriff:
    Der Virenscanner hat eine Sicherheitslücke, und führt mit Systemrechten Code aus, der sich im Autostart installiert. Was genau bringt es da, wenn der Kernel signiert ist?
    Und selbst wenn Du irgendwie magisch das Ausführen von unsignierten Code verhindern könntest, worauf basiert Deine Annahme, dass die Malwarefirmen ihren Code nicht auch signiert kriegen? (Ist in der Vergangenheit schon passiert!)

    Mit dem ganzen Geld das man da jetzt in Secure Boot reinsteckt, könnte man die echte Sicherheit wirklich weiter bringen. Man könnte beispielsweise typsichere Sprachen und Hardware bauen, auf der zum Beispiel einfach ausgeschlossen ist, dass eine Ganzzahl die mit "Privat darf nicht durch die Netzwerkkarte gehen" gekennzeichnet ist, durch die Netzwerkkarte geht. Das geht halt nicht mit x86 und C.

  13. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 08:07

    Wirklich effektiv verstecken kann sich ein echtes Rootkit nur wenn es vor dem Kernel gestartet wird (und im schlimmsten fall sogar das Windows Virtualisiert). Ja es gibt sicherlich auch malware die vieles mit Systemrechten anrichten könnte (man sieht es sogar bei android dort reichen ja schon nutzer rechte, das dort malware teure sms verschickt)
    Aber die Signierung läuft doch so. UEFI erkennt nur das Microsoft zertifikat, Shim erkennt nur das Fedora zertifikat. Also besteht nur gefahr wenn eines der 2 Zertifikate abhanden kommt. In jedem anderen fall forder Shim den Benutzer auf das Zertifikat hinzuzufügen und das wird ein Rootkit nicht verhindern können.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. über Robert Half Technology, Wuppertal
  2. über JobLeads GmbH, Wuppertal
  3. über Robert Half Technology, Großraum Düsseldorf
  4. agorum® Software GmbH, Stuttgart, Ostfildern

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. The Revenant, Zoomania, The Hateful 8)
  2. 43,99€
  3. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Swift Playgrounds im Test: Apple infiziert Kinder mit Programmiertalent
Swift Playgrounds im Test
Apple infiziert Kinder mit Programmiertalent
  1. Asus PG248Q im Test 180 Hertz erkannt, 180 Hertz gebannt

MacOS 10.12 im Test: Sierra - Schreck mit System
MacOS 10.12 im Test
Sierra - Schreck mit System
  1. MacOS 10.12 Sierra fungiert als alleiniges Sicherheitsupdate für OS X
  2. MacOS Sierra und iOS 10 Apple schmeißt unsichere Krypto raus
  3. Kaspersky Neue Malware installiert Hintertüren auf Macs

Android 7.0 im Test: Zwei Fenster für mehr Durchblick
Android 7.0 im Test
Zwei Fenster für mehr Durchblick
  1. Android-X86 Desktop-Port von Android 7.0 vorgestellt
  2. Android 7.0 Erste Nougat-Portierung für Nexus 4 verfügbar
  3. Android 7.0 Erste Nougat-Portierungen für Nexus 5 und Nexus 7 verfügbar

  1. XPG SX8000: Adatas erste PCIe-NVMe-SSD nutzt bewährte Komponenten
    XPG SX8000
    Adatas erste PCIe-NVMe-SSD nutzt bewährte Komponenten

    Eine bekannte Kombination: Für die XPG SX8000 setzt Adata auf einen SMI-Controller und offenbar Micron-Flash-Speicher für hohe Datenraten. Interessant ist die Variante mit Kühlkörper.

  2. UBBF2016: Telefónica will 2G-Netz in vielen Ländern abschalten
    UBBF2016
    Telefónica will 2G-Netz in vielen Ländern abschalten

    Die Integration des Netzwerks von E-Plus stellt die Telefónica vor hohe Anforderungen. Das hat ein Manager heute in Frankfurt verraten. Vieles im Netzwerk soll einfacher werden.

  3. Mögliche Übernahme: Qualcomm interessiert sich für NXP Semiconductors
    Mögliche Übernahme
    Qualcomm interessiert sich für NXP Semiconductors

    Das kalifornische Unternehmen Qualcomm interessiert sich für die ehemalige Halbleitersparte von Philips. Die niederländische NXP soll laut ersten Gesprächen für rund 30 Milliarden US-Dollar übernommen werden.


  1. 14:07

  2. 13:45

  3. 13:18

  4. 12:42

  5. 12:06

  6. 12:05

  7. 11:52

  8. 11:30