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.

    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


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

Anzeige
Stellenmarkt
  1. T-Systems International GmbH, verschiedene Standorte
  2. operational services GmbH & Co. KG, Nürnberg
  3. operational services GmbH & Co. KG, Frankfurt, Berlin
  4. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 44,99€
  2. (u. a. Ronaldo Blu-ray 9,97€, Mia san Champions Blu-ray 7,97€)
  3. beim Kauf eines 6- oder 8-Core FX Prozessors


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobilfunk: Eine Woche in Deutschland im Funkloch
Mobilfunk
Eine Woche in Deutschland im Funkloch
  1. Netzwerk Mehrere regionale Mobilfunkausfälle bei Vodafone
  2. Hutchison 3 Google-Mobilfunk Project Fi soll zwanzigmal schneller werden
  3. RWTH Ericsson startet 5G-Machbarkeitsnetz in Aachen

No Man's Sky im Test: Interstellare Emotionen durch schwarze Löcher
No Man's Sky im Test
Interstellare Emotionen durch schwarze Löcher
  1. No Man's Sky für PC Läuft nicht, stottert, nervt
  2. No Man's Sky Onlinedienste wegen Überlastung offline
  3. Hello Games No Man's Sky bekommt Raumstationsbau

Analog in Rio: Die Technik hinter den Olympia-Kulissen
Analog in Rio
Die Technik hinter den Olympia-Kulissen
  1. Technik bei Rio 2016 Per Stromschlag zu Gold
  2. Rio 2016 Twitter soll Nutzerkonto wegen IOC-Beschwerde gelöscht haben
  3. Rio 2016 Keine Gifs und Vines von den Olympischen Spielen

  1. IT-Support: Nasa verzichtet auf tausende Updates durch HP Enterprise
    IT-Support
    Nasa verzichtet auf tausende Updates durch HP Enterprise

    Eigentlich sollte HP Enterprise sämtliche Endnutzergeräte der Nasa verwalten. Der Support ist aber offenbar so schlecht, dass die IT-Chefin der US-Raumfahrtbehörde mit einer beispiellosen Verzweiflungstat reagiert.

  2. BGH-Antrag: Opposition will NSA-Ausschuss zur Ladung Snowdens zwingen
    BGH-Antrag
    Opposition will NSA-Ausschuss zur Ladung Snowdens zwingen

    Die große Koalition spielt bei der Vernehmung Edward Snowdens durch den NSA-Ausschuss immer noch auf Zeit. Mit Hilfe des BGH wollen Linke und Grüne die Regierung unter Druck setzen.

  3. Kollaborationsserver: Nextcloud 10 verbessert Server-Administration
    Kollaborationsserver
    Nextcloud 10 verbessert Server-Administration

    Die aktuelle Version 10 von Nextcloud verbessert die Überwachung des Servers und ermöglicht eine detailliertere Kontrolle über Dateizugriffe. Offizielle Desktop-Clients für Windows, Mac OS X und Linux sollen folgen.


  1. 15:08

  2. 14:26

  3. 13:31

  4. 13:22

  5. 13:00

  6. 12:45

  7. 12:02

  8. 11:57