Tag Archives: Secure Boot

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Posted on by

Die Schlagzeile hat was, oder?  😀

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Der Releasetermin für Fedora 33 wackelt, da kurzfristig einer neuer Blocker dazu bekommen ist. Ubuntu hat offensichtlich etwas voreilig eine aktuelle Revocationliste für Bootloader ins EFI-Bios verteilt und damit Fedora 33 Beta unbrauchbar gemacht. Um dem Bug zu begegnen, muß man natürlich erst einmal Ubuntu installiert oder laufen gehabt haben und dann Fedora booten wollen.

5. shim https://bugzilla.redhat.com/show_bug.cgi?id=1883609 NEW
Secure Boot fails to boot F33 Beta image

It appears that Ubuntu has pushed a Secure Boot revocation list early, so people who have previously installed Ubtunu will not be able to boot Fedora. This is accepted as a FESCo blocker.

Nachlesen kann man das auf Bugzilla.

Nicht ganz unüblich dürfte das bei Menschen sein, die sich gerade durch diverse Livedisks durchtesten, auf der Suche nach Ihrem zukünftigen Lieblingsbetriebssystems.

Da es auch mein Problem mit dem Bootvorgang auf dem Tablet betrifft, habe ich da natürlich Hoffnungen. Was mir gerade so einfällt: Wo ist eigentlich der Sinn von Secure-Boot, wenn man das im Bios einfach abschalten kann?

In anderen Fedora News

DoT oder DNS-over-TLS kommt wohl doch erst mit Fedora 34. Nicht aufgegriffen wurden auch die anhaltenden pcscd & RDP Probleme mit Gnome, oder der Umstand, daß man mit Fedora keine Screencasts in Videokonferenzen machen kann 🙁  Kommt alles ein bisschen spät für die Deadline, schon klar, war aber mit Sicherheit schon so, als F33 intern das erste mal durchkompilierte.

Von der Geary Front, vorgestellt im letzten BS-LUG Meeting, gibt es auch eine neue Entwicklung: Ein bereits vor Monaten eingereichter Bugreport über einen Formatierungsfehler bei in Antworten erzeugten Daten wie „ER/SIE schrieb am …. um .. das folgende…“ sind allesamt falsch lokalisiert. Als Zeitzone kommt UTC+0 und als Format „english“ zum Einsatz, was bei einer rein Deutschen Konversation per Email mit dem Satz endete: „Das hast Du doch nie vor 2 Stunden geschrieben!“ 🙂 Da ist jetzt neue Bewegung rein gekommen, da der Hauptmaintainer langsam versteht, daß es sich nicht um ein Übersetzungsproblem handelt, sondern um ein Lokalisierungsproblem. Solche Jobs übernehmen Betriebssystembibliotheken normalerweise für einen, aber man muß die natürlich richtig füttern 😉

 

Boothole – Ja, und?

Posted on by

Ähm.. ich fühle mich geradezu .. ähm.. genötigt.. auch was zum Grubproblem zu schreiben:

Ja, und?

Als ich bei Heise das erstmal davon gelesen hatte, ging mir nur das Satzfragment „ja,und?“ durch den Kopf? Was bitte ist an einer Lücke mit der einen PC „übernehmen“ kann, für die man aber schon Root sein muß, besonders? Naja, nichts. Wenn ich schon durch einen Hack Root wurde, dann brauche ich diese Lücke nicht mehr, weil ich schon drin bin. Wenn man diese Lücke von außen per physischem Zugriff ausnutzen kann, dann brauche ich das auch nicht mehr, denn dann hatte ich schon den Zugriff auf den PC mit allem was drauf ist, denn die meisten haben keine Festplattenvollverschlüsselung. Ich kann als Angreifer also nicht nur den Bootbereich, sondern alles ändern, wenn ich das wollte.

Es bleibt also nur die eine Kombination übrig, für die das ein Problem ist: Systeme mit Verschlüsselung + physikalischem Zugriff  und hier auch nur die, wo /Boot unverschlüsselt ist.

Jetzt ist das mit dem physischem Zugriff so eine Sache, denn was bitte hindert mich daran, einen Bootloader auf die Platte zu bannen und dem Bios des Pcs zusagen, es soll Legacy booten, ergo der Secureboot ist nicht mehr im Spiel? Ein BIOS-Passwort vielleicht? Nicht wirklich, weil physischer Zugriff meint halt auf alles, ich könnte als Angreifer also auch mit genug Zeit, das Mainboard austauschen und so das Biospasswort umgehen, oder ich resette das einfach.

Antwort von Euch: „Dann schließ das Gehäuse halt ab.“ .. ja, das ist so.. ich war mal bei den deutschen Meisterschaften im Schlösserknacken dabei ( Zuseher ) und naja, so sicher wie man glaubt,  sind Schlösser gar nicht. Türschlösser z.b. sind in unter 3 Sekunden geöffnet. Es gibt sogar einen Sportverein der sich ganz der Schlossknackkunst verschrieben hat. Wenn uns das eins lehrt: Schlösser sind kein Hindernis für Profis und die (baulich)einfachen Schlösser von PC Gehäusen oder ausm Baumark schon gar nicht.

Merke.. wer physischen Zugriff auf Euren PC hatte, stellt IMMER ein unkalkulierbares Risiko da. Daher kann einen diese Lücke nicht wirklich schrecken. Spannender wird die Frage, wie M$ das nötige Secure-Bootupdate für die Sperre alter Grub Shims verteilen möchte, weil ohne das, ist der Fix oder nicht Fix komplett unwichtig 😀

Microsoft verliert Schlüssel für Secure Boot Hintertür!

Posted on by

„It’s True — There is no such backdoor that only its creator can access.“

Meint, es gibt keine Hintertür in Produkten, die nur der Hersteller nutzen kann.

Die Firma Microsoft hat irrtümlich die Schlüssel für eine Hintertür zum UEFI Secure-Boot veröffentlicht.M$ hatte für Entwickler eine Funktion im UEFI Boot zum Debuggen signiert, die ganz am Anfang läuft. Diese schaltet dann die Signaturchecks für das OS ab, was dazu führt, daß nun Jeder auf jedem Rechner alles installieren und starten kann. Also genau das, was Secure Boot eigentlich verhindern sollte.

Der Gag: Microsoft kann es nicht mehr beheben.

Linux Distributionen nutzen bislang einen eigens von Microsoft signierten Key zum Starten, wenn Sie unter Secure Boot funktionieren sollen. Dies dürfte damit überflüssig geworden sein 😀

Quelle: thehackernews.com

Update:

Zur Klarstellung: Einen „Schlüssel“ im Sinne eines RSA-Schlüssels gibt es nicht. Es gibt signierte Bootmanager für UEFI, die die Abschaltung der anderen Bootmanager erlauben. Das ist der „Schlüssel“ zur Hintertür um Secure Boot zu umgehen.