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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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...

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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"?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Sony Alpha 7S im Test: Vollformater sieht auch bei Dunkelheit nicht schwarz
Sony Alpha 7S im Test
Vollformater sieht auch bei Dunkelheit nicht schwarz
  1. FPS 1000 Kamera soll 18.500 Frames pro Sekunde aufnehmen
  2. Bericht Sony will 4K-Superzoom-Kamera entwickeln
  3. Minikamera Ai-Ball Die WLAN-Kamera aus dem Überraschungsei

IT-Gipfel 2014: De Maizière nennt De-Mail "nicht ganz zufriedenstellend"
IT-Gipfel 2014
De Maizière nennt De-Mail "nicht ganz zufriedenstellend"
  1. Digitale Verwaltung 2020 E-Mail soll Briefe und Amtsbesuche ersetzen
  2. Digitale Agenda Ein Papier, das alle enttäuscht
  3. Webmail Web.de kritisiert langsame De-Mail-Einführung der Regierung

Retro-Netzwerk: Der Tilde.Club erstellt Webseiten wie in den Neunzigern
Retro-Netzwerk
Der Tilde.Club erstellt Webseiten wie in den Neunzigern

  1. Pangu 1.0.1: Jailbreak für iOS 8.1
    Pangu 1.0.1
    Jailbreak für iOS 8.1

    Für iOS 8.1 soll es mit Pangu 1.0.1 einen Jailbreak geben, der aus China stammt. Er nutzt eine Lücke aus, die es ermöglicht, iPhones, iPads und den iPod touch zu entsperren, um Software installieren zu können, die nicht von Apple abgesegnet wurde.

  2. Gratiseinwilligung für Google: Verlage knicken beim Leistungsschutzrecht ein
    Gratiseinwilligung für Google
    Verlage knicken beim Leistungsschutzrecht ein

    Es war kaum anders zu erwarten: Die meisten in der VG Media organisierten Verlage wollen keine verkürzte Darstellung ihrer Links bei Google hinnehmen. Der Konzern lehnte zuvor eine Bitte um "Waffenruhe" ab.

  3. John Riccitiello: Ex-EA-Chef ist neuer Boss von Unity Technologies
    John Riccitiello
    Ex-EA-Chef ist neuer Boss von Unity Technologies

    Der Engine-Hersteller Unity Technologies steht unter neuer Führung: Gleichzeitig mit dem Rücktritt von Mitgründer David Helgason als CEO gibt das Unternehmen die Berufung von John Riccitiello als Nachfolger bekannt, dem ehemaligen Chef von Electronic Arts.


  1. 00:45

  2. 20:52

  3. 19:50

  4. 19:46

  5. 19:09

  6. 18:36

  7. 18:22

  8. 17:11