Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #261958 > unrolled thread

Re: Debian live boot corrupting secure boot

Back to article view | Back to linux.debian.user

Contents

  Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-09-28 01:00 +0200
    Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-09-28 05:10 +0200
      Re: Debian live boot corrupting secure boot Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-28 16:20 +0200
        Re: Debian live boot corrupting secure boot Steve McIntyre <steve@einval.com> - 2023-09-29 12:00 +0200
          On the uses of secure boot [was: Debian live boot corrupting secure  boot] <tomas@tuxteam.de> - 2023-09-29 12:20 +0200
            Re: On the uses of secure boot [was: Debian live boot corrupting  secure boot] Max Nikulin <manikulin@gmail.com> - 2023-09-29 12:30 +0200
            Re: On the uses of secure boot [was: Debian live boot corrupting  secure boot] Curt <curty@free.fr> - 2023-09-29 18:50 +0200
              Re: On the uses of secure boot [was: Debian live boot corrupting  secure boot] <tomas@tuxteam.de> - 2023-09-30 09:30 +0200
    Re: Debian live boot corrupting secure boot Steve McIntyre <steve@einval.com> - 2023-09-29 13:00 +0200
    Re: Debian live boot corrupting secure boot Jeffrey Walton <noloader@gmail.com> - 2023-10-03 04:10 +0200
      Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-10-03 12:20 +0200
        Re: Debian live boot corrupting secure boot Jeffrey Walton <noloader@gmail.com> - 2023-10-04 19:20 +0200

#261958 — Re: Debian live boot corrupting secure boot

On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <manikulin@gmail.com> wrote:
>     I found the issue on latest versions of Clonezilla, but then I tried 
> 
>                        ^^^^^^
> 
>     with plain Debian live and the behavior is the same.
> 
> 
> Does it mean that you can not boot your *old* Clonezilla live after booting a latest Clonezilla? If so, it is better to discuss the issue with shim or grub developers.

Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot 
anymore 2.8.1-12.

> 
>     1) Machine brand new: secure boot is active, Windows 10 shows it active, I can boot an old Clonezilla live (2.8.1-12) as many times as I want. 
> 
> An old image may be signed by a key later added to certificate revocation lists. If so, secure boot just works as it is supposed to do.

I didn't consider that... But it makes sense.

>     2) I boot from USB drive Debian Live 12
>     https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso
> 
> 
> If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora image then it is not a Debian issue. If it is specific to namely Debian (I am unsure concerning Ubuntu, Debian derivatives) then it is better to file a bug providing more details.

As I said, the image that is not loaded anymore is older Clonezilla.
The image that alters secure boot is newer Clonezilla, and then I found 
that newer Debian does the same.
I still haven't found an old version of Debian that cannot boot after 
newer one (but I only tried 10 live, so far).

>     4) I reflash BIOS, same version, and go to point 1.
> 
> 
> How old is your BIOS? Maybe you just restore obsolete list signing of keys.

Perhaps... I have no option during reflash.

BIOS has 9 month. One month ago a new version has been released: some 
day ago I installed it but it behaves just like the previous.

> I suggest to compare
> 
>     efibootmgr -v
> 
> output in the state when Clonezilla may be booted and when it fails. In addition public keys and certificate revocation list should be compared (unsure concerning commands).

I'll try as soon as I have another identical machine.

> My opinion is that just loading boot images without installing OS should not modify firmware state. In this sense it may be a bug.

Not only I didn't install any OS, I didn't boot any image. It's enough 
to reach first page (grub entries) and the damage is done.

> On the other hand, forgot old images if you have secure boot enabled.

Or forget the new ones ;-)

[toc] | [next] | [standalone]

#261960

On 28/09/2023 05:35, Valerio Vanni wrote:
> On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin wrote:
>> My opinion is that just loading boot images without installing OS 
>> should not modify firmware state. In this sense it may be a bug.
> 
> Not only I didn't install any OS, I didn't boot any image. It's enough 
> to reach first page (grub entries) and the damage is done.

Thinking more, I have realized that updating secure boot keys in 
firmware may be the only way for grub to boot. You may try to search for 
docs and discussions to confirm such guess.

After a vulnerability found in shim or grub (that allows to boot 
malicious code having no proper signature) old keys used by Linux 
distributions are revoked, new ones are generated. New images signed by 
new keys are published.

Consider booting of a new image on a box having outdated set of keys 
(old BIOS). The machine is unaware of new keys, so unless keys are 
updated, it prohibits booting of new images as insecure ones. With up to 
day keys, certificate revocation list is loaded as well making booting 
of older (and thus vulnerable) images impossible. That is why just 
loading of an .EFI file may prevent further booting of old images.

Perhaps loading of updated key chain might be made transient affecting 
current boot only. I have no idea what are the obstacles: it is not 
allowed by secure boot policy, it is not supported by firmware, it is 
unreliable due to bugs in firmware, or it is just not implemented in 
shim or grub.

>> On the other hand, forgot old images if you have secure boot enabled.
> 
> Or forget the new ones ;-)

I have never tried it, but perhaps you may enroll your own keys and 
rebuild old images to put EFI files signed by you. See "master owner keys".

With outdated keys secure boot does not protect you. Is it Windows that 
prevents you from just turning secure boot off? I would not be surprised 
if during some update of Windows, certificate revocation list will be 
updated as well, so you would not be able to boot your old Clonezilla 
any more.

Why you avoiding up to date Clonezilla? Does it have backward 
compatibility issues making old backup useless?

[toc] | [prev] | [next] | [standalone]

#261964

> With outdated keys secure boot does not protect you.

Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
(and is not designed to protect you either).


        Stefan

[toc] | [prev] | [next] | [standalone]

#261970

Stefan wrote:
>> With outdated keys secure boot does not protect you.
>
>Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
>(and is not designed to protect you either).

Sigh. Lose the misinformation crap, please. It's getting tedious.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

[toc] | [prev] | [next] | [standalone]

#261971 — On the uses of secure boot [was: Debian live boot corrupting secure boot]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 29, 2023 at 10:50:37AM +0100, Steve McIntyre wrote:
> Stefan wrote:
> >> With outdated keys secure boot does not protect you.
> >
> >Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
> >(and is not designed to protect you either).
> 
> Sigh. Lose the misinformation crap, please. It's getting tedious.

He-said-she-said.

JFTR. I don't know about the exact number, but I tend to agree with
Stefan here. But since we aren't exchanging arguments but just ready
made conclusions, the discussion doesn't lead anywhere.

One thing we can agree, though, may be that secure boot gives more
control of the platform to the hardware maker (who, after all is
the one choosing the TPM and the firmware going in and around there).

Whether the hardware maker is your ally, Microsoft's ally or Google's
ally (or Netflix or who-the-devil-knows) is another long and winding
discussion. I tend to think that Microsoft is higher up that list
than you & me.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#261972 — Re: On the uses of secure boot [was: Debian live boot corrupting secure boot]

On 29/09/2023 17:16, tomas@tuxteam.de wrote:
> He-said-she-said.

Warning! Flammable!

Let's wait till Valerio's issue will be solved.

E.g. nobody has posted commands to get list of secure boot keys so far.

[toc] | [prev] | [next] | [standalone]

#261975 — Re: On the uses of secure boot [was: Debian live boot corrupting secure boot]

On 2023-09-29, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
>
> On Fri, Sep 29, 2023 at 10:50:37AM +0100, Steve McIntyre wrote:
>> Stefan wrote:
>> >> With outdated keys secure boot does not protect you.
>> >
>> >Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
>> >(and is not designed to protect you either).

>> Sigh. Lose the misinformation crap, please. It's getting tedious.

> He-said-she-said.
>

https://wiki.debian.org/SteveMcIntyre

 Steve McIntyre 

 Steve has been a DD since October 1996 and was Debian Project Leader from
 April 2008 to April 2010.
 He maintains quite a few packages, but is normally most active doing DebianCd
 or DebianInstaller or UEFI work. He's also an admin for this wiki!

https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot.3F

 What is UEFI Secure Boot NOT?

 UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC
 market here; SB is a security measure to protect against malware during early
 system boot. Microsoft act as a Certification Authority (CA) for SB, and they
 will sign programs on behalf of other trusted organisations so that their
 programs will also run. There are certain identification requirements that
 organisations have to meet here, and code has to be audited for safety. But
 these are not too difficult to achieve.

 SB is also not meant to lock users out of controlling their own systems. Users
 can enroll extra keys into the system, allowing them to sign programs for their
 own systems. Many SB-enabled systems also allow users to remove the
 platform-provided keys altogether, forcing the firmware to only trust
 user-signed binaries. 

Get a life (or change those wikis to reflect *your* truth)!

[toc] | [prev] | [next] | [standalone]

#261997 — Re: On the uses of secure boot [was: Debian live boot corrupting secure boot]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 29, 2023 at 04:40:18PM -0000, Curt wrote:
> On 2023-09-29, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:

[...]

> >> Sigh. Lose the misinformation crap, please. It's getting tedious.
> 
> > He-said-she-said.
> >
> 
> https://wiki.debian.org/SteveMcIntyre
> 
>  Steve McIntyre 
[...]

C'mon, Curt. You can better. Nearly everyone around here knows who Steve
is. I sure do, and I respect him a lot, but I don't have to agree with
him every time.


>  UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC
>  market here;

This part is just a statement of opinion (and as such not really veryfiable),
with which I disagree strongly. The rest...

>  SB is a security measure to protect [...]

is a technical description, which is veryfiable and makes sense. Microsoft
is (as are all bigger corporations) an opportunistic entity. Google, for
example is a search engine, but at the same time a device to gather data
about you and to sell targeted ads. Why should they be mutually exclusive?

> Get a life (or change those wikis to reflect *your* truth)!

I'm not willing to discuss with you on this terms. I'm done. Go have your
last word.

bye
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#261973

valerio.vanni@inwind.it wrote:
>On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <manikulin@gmail.com> wrote:
>>     I found the issue on latest versions of Clonezilla, but then I tried 
>> 
>>                        ^^^^^^
>> 
>>     with plain Debian live and the behavior is the same.
>> 
>> 
>> Does it mean that you can not boot your *old* Clonezilla live after booting a latest
>Clonezilla? If so, it is better to discuss the issue with shim or grub developers.
>
>Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot 
>anymore 2.8.1-12.
>
>> 
>>     1) Machine brand new: secure boot is active, Windows 10 shows it active, I can boot an
>old Clonezilla live (2.8.1-12) as many times as I want. 
>> 
>> An old image may be signed by a key later added to certificate revocation lists. If so,
>secure boot just works as it is supposed to do.
>
>I didn't consider that... But it makes sense.
>
>>     2) I boot from USB drive Debian Live 12
>>    
>https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso
>> 
>> 
>> If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora image then it is not
>a Debian issue. If it is specific to namely Debian (I am unsure concerning Ubuntu, Debian
>derivatives) then it is better to file a bug providing more details.
>
>As I said, the image that is not loaded anymore is older Clonezilla.
>The image that alters secure boot is newer Clonezilla, and then I found 
>that newer Debian does the same.
>I still haven't found an old version of Debian that cannot boot after 
>newer one (but I only tried 10 live, so far).

The newer images might be causing firmware key revocation updates to
be applied. This is part of the Secure Boot story - if you want to
stay secure, systems will need to be updated to stop older software
with known holes from being run.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

[toc] | [prev] | [next] | [standalone]

#262109

On Thu, Sep 28, 2023 at 12:10 AM Valerio Vanni <valerio.vanni@inwind.it> wrote:
>
> On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <manikulin@gmail.com> wrote:
> >     I found the issue on latest versions of Clonezilla, but then I tried
> >
> >                        ^^^^^^
> >     with plain Debian live and the behavior is the same.
> >
> > Does it mean that you can not boot your *old* Clonezilla live after booting a latest Clonezilla? If so, it is better to discuss the issue with shim or grub developers.
>
> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
> anymore 2.8.1-12.

I would probably bet if you booted to Windows, the OS would check the
Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
required.

So you are probably going to have to deal with this sooner rather than
later. Both OSes are going to try to update the database with
signatures of the bad grub programs. Or I would not bet against it.

Jeff

[0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15

[toc] | [prev] | [next] | [standalone]

#262117

Il 03/10/2023 04:01, Jeffrey Walton ha scritto:

>>> Does it mean that you can not boot your *old* Clonezilla live after booting a latest Clonezilla? If so, it is better to discuss the issue with shim or grub developers.
>>
>> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
>> anymore 2.8.1-12.
> 
> I would probably bet if you booted to Windows, the OS would check the
> Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
> required.

No, it hasn't happen. If you read entire discussion, it hasn't happen 
nieither with Windows 10 nor Windows 11.
The only action that breaks secure boot of Clonezilla 2.8.1-12 is 
reaching the page of Grub entries in recent Clonezilla and Debian live.

> So you are probably going to have to deal with this sooner rather than
> later. Both OSes are going to try to update the database with
> signatures of the bad grub programs. Or I would not bet against it.
> 
> Jeff
> 
> [0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15

Yes, no one can tell... but this update has more than six months.
So far it seems that Linux has a larger revocation database.

And, even if Windows would adobt this larger database, I keep on 
considering it bad in a live environment. Be it Live Windows or Live Linux.

[toc] | [prev] | [next] | [standalone]

#262164

On Tue, Oct 3, 2023 at 11:44 AM Valerio Vanni <valerio.vanni@inwind.it> wrote:
>
> Il 03/10/2023 04:01, Jeffrey Walton ha scritto:
>
> >>> Does it mean that you can not boot your *old* Clonezilla live after booting a latest Clonezilla? If so, it is better to discuss the issue with shim or grub developers.
> >>
> >> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
> >> anymore 2.8.1-12.
> >
> > I would probably bet if you booted to Windows, the OS would check the
> > Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
> > required.
>
> No, it hasn't happened. If you read the entire discussion, it hasn't
> happened neither with Windows 10 nor Windows 11.
> The only action that breaks secure boot of Clonezilla 2.8.1-12 is
> reaching the page of Grub entries in recent Clonezilla and Debian live.
>
> > So you are probably going to have to deal with this sooner rather than
> > later. Both OSes are going to try to update the database with
> > signatures of the bad grub programs. Or I would not bet against it.
> >
> > [0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15
>
> Yes, no one can tell... but this update has more than six months.
> So far it seems that Linux has a larger revocation database.
>
> And, even if Windows would adopt this larger database, I keep on
> considering it bad in a live environment. Be it Live Windows or Live Linux.

Did you see new grub vulnerabilities were just announced? [1] I would
not be surprised if both Linux and Windows updated the Forbidden
Signature/Secure Boot DBX.

You're going to have to deal with it eventually. Restoring UEFI
firmware to run an old Clonezilla is not a long term solution.

[1] https://www.openwall.com/lists/oss-security/2023/10/04/5

Jeff

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web