Abo Login
  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
  1. Business Intelligence (BI) Developer (m/w)
    Mister Spex GmbH, Berlin
  2. Anwendungs- und Softwareberater (m/w) für SAP PLM
    MAHLE International GmbH, Stuttgart
  3. Mitarbeiter Kundendatenmanagement (m/w)
    Hornbach-Baumarkt-AG, Neustadt an der Weinstraße
  4. Betreuer (m/w) SAP HCM Organisationsmanagement
    Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz

 

Detailsuche



Top-Angebote
  1. NUR HEUTE: Saturn Super Sunday
    (alle Angebote versandkostenfrei, u. a. HTC One M8s für 369,00€)
  2. TIPP: 4 Blu-rays für 30 EUR
    (u. a. Terminator 3, Kill the Boss 2, Elysium, Captain Phillips)
  3. TOP-TIPP: Amazon-Gutschein im Wert von 40€ kaufen und 10€ geschenkt bekommen
    (Achtung: Anscheinend sind nicht alle User für die Teilnahme berechtigt)

 

Weitere Angebote



Haben wir etwas übersehen?

E-Mail an news@golem.de


Microsoft: Die Neuerungen von Windows 10
Microsoft
Die Neuerungen von Windows 10
  1. Microsoft Über 14 Millionen sind bereits auf Windows 10 gewechselt
  2. Neuer Windows Store Windows 10 erlaubt deutlich weniger Parallelinstallationen
  3. Microsoft DVD-Player-App für Windows 10 nicht für jeden gratis

SIOD: Wenn die Anzeige auch in der Zeitung blinkt
SIOD
Wenn die Anzeige auch in der Zeitung blinkt
  1. Electric Skin Nanoforscher entwickeln hautähnliches Farbdisplay
  2. Panasonic FZ300 Superzoom-Kamera arbeitet mit f/2,8-Objektiv und 4K-Auflösung
  3. Panasonic Lumix GX8 Systemkamera ermöglicht Scharfstellung nach der Aufnahme

Windows 10 im Tablet-Test: Ein sinnvolles Windows für Tablets
Windows 10 im Tablet-Test
Ein sinnvolles Windows für Tablets
  1. Windows 10 Startmenü macht nach 512 Einträgen schlapp
  2. Windows 10 Erzwungene Updates können Treiberfehler verursachen
  3. Microsoft Pro-Lizenz von Windows 10 kostet 280 Euro

  1. Trampender Roboter: Hitchbot bei seiner Reise durch die USA zerstört
    Trampender Roboter
    Hitchbot bei seiner Reise durch die USA zerstört

    Die Reise des trampenden Roboters Hitchbot durch die USA hat in Philadelphia im US-Bundesstaat Pennsylvania ein jähes Ende gefunden. Ein Foto auf Twitter soll die Überreste des zerstörten Roboters zeigen.

  2. Multimedia-Bibliothek: Der Leiter des FFmpeg-Projekts tritt zurück
    Multimedia-Bibliothek
    Der Leiter des FFmpeg-Projekts tritt zurück

    Michael Niedermayer, seit 11 Jahren Leiter des Projekts FFmpeg, tritt von seinem Posten zurück. Er hoffe, damit die Entwickler aus dem Schwesterprojekt Libav zur Rückkehr zu bewegen.

  3. Demo wegen #Landesverrat: "Come and get us all, motherfuckers"
    Demo wegen #Landesverrat
    "Come and get us all, motherfuckers"

    Mehr als 2.000 Menschen haben am Samstag in Berlin für die Pressefreiheit demonstriert. Die Redner forderten, die Ermittlungen wegen Landesverrats gegen das Blog Netzpolitik.org und dessen Informanten sofort einzustellen.


  1. 19:44

  2. 11:30

  3. 10:46

  4. 12:40

  5. 12:00

  6. 11:22

  7. 10:34

  8. 09:37