MS entfernt SecureBoot-Signaturen aus UEFI per Windows Update

[Marco Moock]

Hallo zusammen,
bei heise gibt es einen Artikel hinter Paywall, in dem beschrieben
wird, dass MS per Windows Update bestimmte Signaturen für SecureBoot
aus dem UEFI entfernt hat und daher bestimmte Bootloader nicht mehr
laden konnten.
https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgezogen-Microsoft-bootet-Linux-aus-7250544.html

Hat wer von euch das erlebt?
Hier wird Ubuntu 20.04 genannt, das bringt GRUB2 mit.
Kennt wer den Grund, warum MS das getan hat?
Waren die Schlüssel zum Signieren kompromittiert oder war das mal
wieder was aus der Kategorie "User schikanieren"?

Erfreulicherweise habe ich keine Windows-Rechner und ich könnte zur Not
auch SecureBoot abstellen.

--
Gruß
Marco

[Volker Neurath]

Am Fri, 2 Sep 2022 20:20:22 +0200
schrieb Marco Moock <mo...@posteo.de>:

> Kennt wer den Grund, warum MS das getan hat?
> Waren die Schlüssel zum Signieren kompromittiert oder war das mal
> wieder was aus der Kategorie "User schikanieren"?

Letzteres. solch ein Schritt war schon lange zu erwarten und auch wenn
MS jetzt wieder zurückrudern sollte - das ist erst der Anfang.

Machen wir uns nichts vor: MS kann jederzeit den Stecker auch
dauerhaft ziehen; dann gucken alle mit einem MS nicht genehmen OS,
deren Signierschlüssel von dort stammen, in die Röhre -- und das
dürften derzeit die meisten sein.

[Marco Moock]

Am Freitag, 02. September 2022, um 21:31:10 Uhr schrieb Volker Neurath:

> dann gucken alle mit einem MS nicht genehmen OS,
> deren Signierschlüssel von dort stammen, in die Röhre -- und das
> dürften derzeit die meisten sein.

Bei den meisten Rechner ist das Abschalten von SecureBoot bzw. das
Hinzufügen von Schlüsseln möglich, aber natürlich eine weitere Hürde
für den Benutzer.
Und irgendwie habe ich im Hinterkopf, dass es vor kurzer Zeit von MS ne
Aussage gab, dass SecureBoot nicht abgestellt werden darf bei
bestimmten Systemen. Ich finde aber den Beitrag aktuell nicht mehr.

[Enrik Berkhan]

Marco Moock <mo...@posteo.de> wrote:
> Hat wer von euch das erlebt?
> Hier wird Ubuntu 20.04 genannt, das bringt GRUB2 mit.
> Kennt wer den Grund, warum MS das getan hat?
> Waren die Schlüssel zum Signieren kompromittiert oder war das mal
> wieder was aus der Kategorie "User schikanieren"?

Laut Artikel handelt es sich um ältere Versionen von grub2 mit Bugs, die
die Umgehung von secure boot erlauben. Insofern ist die Sperrung der
Signaturen richtig. Genau dafür sind diese Mechanismen schließlich da.

Falsch ist, dass das ganze erst publik wird, nachdem die entsprechenden
Updates ausgerollt wurden.

Falsch ist auch, wie im Artikel m.E. richtig dargestellt, dass die
"Macht" hier bei MS liegt und nicht bei einer herstellerunabhängigen
Organisation.

Gruß,
Enrik

[Marco Moock]

Am Freitag, 02. September 2022, um 19:32:24 Uhr schrieb Enrik Berkhan:

> Marco Moock <mo...@posteo.de> wrote:
> > Hat wer von euch das erlebt?
> > Hier wird Ubuntu 20.04 genannt, das bringt GRUB2 mit.
> > Kennt wer den Grund, warum MS das getan hat?
> > Waren die Schlüssel zum Signieren kompromittiert oder war das mal
> > wieder was aus der Kategorie "User schikanieren"?
>
> Laut Artikel handelt es sich um ältere Versionen von grub2 mit Bugs,
> die die Umgehung von secure boot erlauben. Insofern ist die Sperrung
> der Signaturen richtig. Genau dafür sind diese Mechanismen
> schließlich da.

Danke für die Klarstellung.

> Falsch ist, dass das ganze erst publik wird, nachdem die
> entsprechenden Updates ausgerollt wurden.

Vor allem frage ich mich, warum sowas über Windows Update passiert. Was
machen User mit einem andern OS?
Die Keys manuell löschen und neue eintrage?

> Falsch ist auch, wie im Artikel m.E. richtig dargestellt, dass die
> "Macht" hier bei MS liegt und nicht bei einer herstellerunabhängigen
> Organisation.

Wie ist das eigentlich historisch so gewachsen?

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Vor allem frage ich mich, warum sowas über Windows Update passiert.

Wie denn sonst? Firmwareupdates macht Oma Druse nicht so häufig.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marco Moock]

Am Samstag, 03. September 2022, um 10:43:27 Uhr schrieb Marc Haber:

> Wie denn sonst? Firmwareupdates macht Oma Druse nicht so häufig.

Neuere Systeme bieten an, so ein Update über das Internet zu machen.
Könnte man z.B. 1x im Monat vor dem Boot prüfen und dann einspielen.
Dann kommt das direkt vom Hersteller des Mainboard und nicht von MS.
HP unterstützt sowas.

[Andreas Kohlbach]

On Fri, 2 Sep 2022 20:20:22 +0200, Marco Moock wrote:
>
> bei heise gibt es einen Artikel hinter Paywall, in dem beschrieben
> wird, dass MS per Windows Update bestimmte Signaturen für SecureBoot
> aus dem UEFI entfernt hat und daher bestimmte Bootloader nicht mehr
> laden konnten.
> https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgezogen-Microsoft-bootet-Linux-aus-7250544.html

<https://www.heise.de/news/UEFI-Secure-Boot-Microsoft-sperrt-unsichere-Bootloader-per-Windows-Update-7220634.html>
hat keine Zahlschranke. Kann ich sogar im lynx Text-Browser lesen.

Ich habe allerdings ein grundsätzliches Verständnisproblem: Warum
"sperrt" MS das Booten mit "unsicheren Loadern"? Besitzt MS alle BIOSe
(oder nun "UEFI" wohl), dass das auch das Booten von Linux verhindern
könnte? Oder hat MS zumindest so viel Einfluss auf die
"Schlüsseldatenbank DBX" (aus dem Artikel oben)?

Beides wäre IMO sehr schlimm: Ein Softwarehersteller mit Quasi-Monopol
hat das Sagen auf Hardware, die nicht von ihm stammt.
--
Andreas

[Marco Moock]

Am Samstag, 03. September 2022, um 14:24:17 Uhr schrieb Andreas
Kohlbach:

> Ich habe allerdings ein grundsätzliches Verständnisproblem: Warum
> "sperrt" MS das Booten mit "unsicheren Loadern"? Besitzt MS alle BIOSe
> (oder nun "UEFI" wohl), dass das auch das Booten von Linux verhindern
> könnte? Oder hat MS zumindest so viel Einfluss auf die
> "Schlüsseldatenbank DBX" (aus dem Artikel oben)?

So wie ich das verstehe, hat MS Einfluss auf die Hersteller, die das
UEFI (nur da ist es relevant) implementieren und natürlich auf die
Hardware über Updates, wie es jedes OS hat.

[Arno Welzel]

Marco Moock, 2022-09-02 21:50:

Windows 11 setzt in der Regel SecureBoot voraus.


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Andreas Kohlbach, 2022-09-03 20:24:

> On Fri, 2 Sep 2022 20:20:22 +0200, Marco Moock wrote:
>>
>> bei heise gibt es einen Artikel hinter Paywall, in dem beschrieben
>> wird, dass MS per Windows Update bestimmte Signaturen für SecureBoot
>> aus dem UEFI entfernt hat und daher bestimmte Bootloader nicht mehr
>> laden konnten.
>> https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgezogen-Microsoft-bootet-Linux-aus-7250544.html
>
> <https://www.heise.de/news/UEFI-Secure-Boot-Microsoft-sperrt-unsichere-Bootloader-per-Windows-Update-7220634.html>
> hat keine Zahlschranke. Kann ich sogar im lynx Text-Browser lesen.
>
> Ich habe allerdings ein grundsätzliches Verständnisproblem: Warum
> "sperrt" MS das Booten mit "unsicheren Loadern"? Besitzt MS alle BIOSe
> (oder nun "UEFI" wohl), dass das auch das Booten von Linux verhindern
> könnte? Oder hat MS zumindest so viel Einfluss auf die
> "Schlüsseldatenbank DBX" (aus dem Artikel oben)?

Das ist die Folge des Updates - *manche* Bootloader sind danach
"gesperrt", weil sie von UEFI mit aktivem SecureBoot nicht mehr
gestartet werden.

Nein, das bedeutet nicht, dass Linux generell nicht mehr funktioniert,
sondern nur bestimmte Distributionen.

> Beides wäre IMO sehr schlimm: Ein Softwarehersteller mit Quasi-Monopol
> hat das Sagen auf Hardware, die nicht von ihm stammt.

Na ja - "Monopol" vielleicht nicht. Aber das auch Firmware-Updates über
Windows erfolgen, ist bei Microsoft schon länger der Fall. Auch
Microcode-Updates für die CPU werden in der Regel über Windows-Updates
ausgeliefert. Da Windows generell Zugriff auf UEFI hat, kann es
logischerweise auch Keys austauschen oder löschen. Linux kann das ja auch.

[Enrik Berkhan]

Andreas Kohlbach <a...@spamfence.net> wrote:
> Also angenommen ich kaufe ein Bord bei einem Kistenschieber. Ist da was
> gesperrt, oder kann ich ein beliebiges OS aufspielen?

In fabrikneuer Hardware sind entweder keine Zertifikate drin oder (in
vermutlich 99.999% der Fälle) die von Microsoft. Daher lässt sich
Windows bei aktiviertem 'secure boot' einfach so installieren. Andere
Betriebssysteme nicht. Das war der Wunschzustand der Welt von Microsoft.

Damit sie aber nicht wieder so lästige Monopol-Klagen an den Hals
bekommen, haben sie irgendwann angeboten, einen kleinen
'Zwischenbootloader' zu machen ('shim'), der dann wiederum z.B. passend
signierte grub-Versionen lädt, die ihrerseits secure boot tauglich sind.

Gesperrt wäre eh nur was, wenn 'secure boot' sich auf deinem Board vom
Kistenschieber gar nicht deaktivieren ließe. Nur darum geht es die ganze
Zeit: was kann/darf ich booten, wenn 'secure boot' aktiviert ist.

[Marco Moock]

Am Samstag, 03. September 2022, um 21:53:01 Uhr schrieb Arno Welzel:

> Windows 11 setzt in der Regel SecureBoot voraus.

Das sind die offiziellen Anforderungen von MS, aber es geht auch ohne.
Schon bei Windows 8 mussten meines Wissens neue Rechner UEFI und
ggf. auch SecureBoot haben, um mit dem Windows-Logo verkauft werden zu
dürfen.

[Kay Martinen]

Am 03.09.22 um 11:46 schrieb Marco Moock:

Viele Puristen mögen kein Hersteller-eigenes Tool im Autostart haben das
nur einmal im Monat; oder beliebig oft; nach updates von
$SystemsoftwareX bei $HerstellerX nach schaut - oder mutmaßlich auch
nach Hause telefoniert. Findest du das besser? Außerdem: FW-Updates VOR
dem Boot checken und einspielen wird eh nix. Eher runterladen und
neustart auslösen damit es dann eingespielt wird. Noch'n Reboot-trigger.

Und solche "Software-Update-Agents" sind doch wohl die einzig andere
Option - neben dem Windows-update. Oder? Müssen zudem oft mit Erhöhten
Rechten laufen um die FW überhaupt einspielen zu können - oder an die
passende Update-Position zu schieben (IMHO).

N.B. bei einem 'apt upgrade' bekomme ich auch firmware- oder microcode-
updates geliefert wenn welche da sind.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Marco Moock]

Am Samstag, 03. September 2022, um 19:22:39 Uhr schrieb Andreas
Kohlbach:

> Vermutlich wird das Entfernen von Windows aber nicht die
> MS-Zertifikate entfernt?

Nein.

> Dann wäre ein Bord wohl Sperrmüll.

Auch nein. Man könnte SecureBoot abstellen und dann jedes Bootloader
der Wahl installieren und dann die passenden Keys ins UEFI eintragen.
Dazu muss das UEFI das aber zulassen, was man seitens des Herstellers
unterbinden könnte.

[Kay Martinen]

Am 03.09.22 um 23:31 schrieb Enrik Berkhan:

> Andreas Kohlbach <a...@spamfence.net> wrote:
>> Also angenommen ich kaufe ein Bord bei einem Kistenschieber. Ist da was
>> gesperrt, oder kann ich ein beliebiges OS aufspielen?
>

> Windows bei aktiviertem 'secure boot' einfach so installieren. Andere
> Betriebssysteme nicht. Das war der Wunschzustand der Welt von Microsoft.

Spielen wir eine neue Runde "World Domination"? :-)

https://youtu.be/vUc4GkMN1qs

> 'Zwischenbootloader' zu machen ('shim'), der dann wiederum z.B. passend
> signierte grub-Versionen lädt, die ihrerseits secure boot tauglich sind.

Und die Zurückgezogenen Signaturen betreffen diesen Zwischenbootloader?
Dann sollte es unter Linux möglicherweise ein update für diesen 'shim'
geben.

> Gesperrt wäre eh nur was, wenn 'secure boot' sich auf deinem Board vom
> Kistenschieber gar nicht deaktivieren ließe. Nur darum geht es die ganze
> Zeit: was kann/darf ich booten, wenn 'secure boot' aktiviert ist.

Hmm. Was ich jetzt noch nicht erkennen kann:

Ich habe einen älteren Samsung Laptop (IMHO core i5) auf dessen
originärer SSD Windows 10 installiert ist. AFAIR mit SecureBoot.

Und auf einer zweiten SSD die ich ggf. mal gegeneinander austausche ist
ein Linux (Debian oder Ubuntu) drauf. Soweit ich erinnere auch im
SecureBoot installiert und laufend. Hab ich früher schon mehrfach
getauscht und von der Uhrzeit abgesehen keine Probleme gehabt.

Muß ich da jetzt damit rechnen das ein Update-lauf unter Win10 im UEFI
was entfernt und beim nächsten Wechsel auf die Linux SSD dieses nicht
mehr hoch kommt - weil M$ die Sig. zerschossen haben könnte?

Ich weiß jetzt grad nicht ob ein solches Linux dann problemlos starten
würde wenn ich nur das Secureboot ausschalte. In dem Fall könnte es ja
immerhin möglich sein durch ein update o.a. Linux-tools den
Zerschossenen UEFI-Start wieder grade zu biegen.

Vermutlich würde es auf die Fresse fallen, was ich als von M$ billigend
in kauf nehmend ansehe. Ist der OS-War immer noch nicht vorbei? :-/

[Enrik Berkhan]

Kay Martinen <use...@martinen.de> wrote:
> Am 03.09.22 um 23:31 schrieb Enrik Berkhan:

>> 'Zwischenbootloader' zu machen ('shim'), der dann wiederum z.B. passend
>> signierte grub-Versionen lädt, die ihrerseits secure boot tauglich sind.
>
> Und die Zurückgezogenen Signaturen betreffen diesen Zwischenbootloader?
> Dann sollte es unter Linux möglicherweise ein update für diesen 'shim'
> geben.

Wenn ich mir den Inhalt des Artikels richtig gemerkt habe, dann haben
sie gezielt Signaturen von kaputten grubs gesperrt.

>> Gesperrt wäre eh nur was, wenn 'secure boot' sich auf deinem Board vom
>> Kistenschieber gar nicht deaktivieren ließe. Nur darum geht es die ganze
>> Zeit: was kann/darf ich booten, wenn 'secure boot' aktiviert ist.
>
> Hmm. Was ich jetzt noch nicht erkennen kann:
>
> Ich habe einen älteren Samsung Laptop (IMHO core i5) auf dessen
> originärer SSD Windows 10 installiert ist. AFAIR mit SecureBoot.
>
> Und auf einer zweiten SSD die ich ggf. mal gegeneinander austausche ist
> ein Linux (Debian oder Ubuntu) drauf. Soweit ich erinnere auch im
> SecureBoot installiert und laufend. Hab ich früher schon mehrfach
> getauscht und von der Uhrzeit abgesehen keine Probleme gehabt.
>
> Muß ich da jetzt damit rechnen das ein Update-lauf unter Win10 im UEFI
> was entfernt und beim nächsten Wechsel auf die Linux SSD dieses nicht
> mehr hoch kommt - weil M$ die Sig. zerschossen haben könnte?

Das ist nicht ausgeschlossen. Wenn auf der länger nicht benutzten Linux
SSD ein betroffener grub drauf ist, wird der bei aktiviertem secure boot
wohl nicht mehr starten. Wenn das Linux noch supported ist und immer
schön up-to-date gehalten wurde, sollte so ein betroffener grub
eigentlich nicht mehr drauf sein. Da hilft nur nachgucken und/oder
ausprobieren.

> Ich weiß jetzt grad nicht ob ein solches Linux dann problemlos starten
> würde wenn ich nur das Secureboot ausschalte. In dem Fall könnte es ja
> immerhin möglich sein durch ein update o.a. Linux-tools den
> Zerschossenen UEFI-Start wieder grade zu biegen.

Das müsste funktionieren. Die Gefahr dabei ist, wenn ich mir den Inhalt
des Artikels richtig gemerkt habe, dass das Windows nach aus-/anschalten
des secure boot nicht mehr funktioniert. Ich weiß nicht warum, aber
möglich ist das, wenn Ausschalten des secure boot z.B. auch ein TPM
zurücksetzt etc.

> Vermutlich würde es auf die Fresse fallen, was ich als von M$ billigend
> in kauf nehmend ansehe. Ist der OS-War immer noch nicht vorbei? :-/

Das alles wäre auch passiert, wenn jemand anders als MS solche
Zertifikate und/oder Key-Sperren verteilen würde. Möglicherweise wäre es
anders/besser kommuniziert worden.

Gruß,
Enrik

[Arno Welzel]

Marco Moock, 2022-09-04 09:58:

> Am Samstag, 03. September 2022, um 21:53:01 Uhr schrieb Arno Welzel:
>
>> Windows 11 setzt in der Regel SecureBoot voraus.
>
> Das sind die offiziellen Anforderungen von MS, aber es geht auch ohne.

Nur weil man irgendwas per Hack umgehen kann, bedeutet nicht, dass
Windows 11 langfristig auch ohne SecureBoot nutzbar sein wird.

> Schon bei Windows 8 mussten meines Wissens neue Rechner UEFI und
> ggf. auch SecureBoot haben, um mit dem Windows-Logo verkauft werden zu
> dürfen.

Ich rede nicht von "Windows-Logo", was sich ein Hersteller dann auf's
Gerät pappen kann, sondern davon, dass das Installationsprogramm von
Windows 11 sich aktiv weigert, wenn das System weder TPM 2.0 noch
Securebot hat. Die diversen Registry-Hacks, um das zu umgehen, mögen
aktuell noch nutzbar sein, aber die kann Microsoft jederzeit abschaffen.

[Arno Welzel]

Andreas Kohlbach, 2022-09-04 01:22:

> On Sat, 3 Sep 2022 21:31:56 -0000 (UTC), Enrik Berkhan wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> Also angenommen ich kaufe ein Bord bei einem Kistenschieber. Ist da was
>>> gesperrt, oder kann ich ein beliebiges OS aufspielen?
>>
>> In fabrikneuer Hardware sind entweder keine Zertifikate drin oder (in
>> vermutlich 99.999% der Fälle) die von Microsoft. Daher lässt sich
>> Windows bei aktiviertem 'secure boot' einfach so installieren. Andere
>> Betriebssysteme nicht. Das war der Wunschzustand der Welt von Microsoft.
>

> Also fummelt ein installiertes Windows da herum. Immerhin.
>
> Also haben User, die Linux installieren wollen nur ein mögliches Problem,
> wenn Windows bereits installiert ist?

Ja.

> Vermutlich wird das Entfernen von Windows aber nicht die MS-Zertifikate

> entfernt? Dann wäre ein Bord wohl Sperrmüll.

Nein, dann kann man Secureboot im UEFI auch einfach ausschalten.