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

Groups > linux.debian.user > #261962 > 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 11:50 +0200
    Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-09-29 05:50 +0200
      Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-09-30 16:00 +0200
        Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-10-02 18:50 +0200
          Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-10-02 20:40 +0200
            Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-10-04 17:20 +0200
              Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-10-04 23:10 +0200
                Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-10-05 17:30 +0200
              Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-10-11 03:50 +0200
                Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-10-11 04:20 +0200
                  Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-10-11 17:10 +0200

#261962 — Re: Debian live boot corrupting secure boot

On Thu, 28 Sep 2023 10:08:27 +0700 Max Nikulin wrote:

> 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.

Yes, but couldn't it add news keys without blacklisting old ones?
Remember we are talking about a live environment, not an installed one. 
This is breaking something I was sure about.
I always considered loading a live environment a safe action. I've 
always expected to find the machine as it was before, now I cannot 
expect it anymore.

Furthermore, here we are talking about a new live that prevented another 
live from booting. But it could happen that I load a live and break 
loading of resident OS. Bad result.

> 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.

It would be a better choice.

>     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".

Do you mean load new EFI files in old Clonezilla?

> 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.

Windows works with or without secure boot, but I'd like to leave it on.
So far, no Windows update did such thing. I also tried update from 
Windows 10 to Windows 11, and nothing happened.

Neither latest BIOS update from Asus (released at start of this month) 
prevented anything to boot. Perhaps hardware manufacturers choose not to 
blacklist anything, and only new grubs blacklist old ones?

[toc] | [next] | [standalone]

#261969

On 28/09/2023 16:45, Valerio Vanni wrote:
> On Thu, 28 Sep 2023 10:08:27 +0700 Max Nikulin wrote:
> 
>> 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.
> 
> Yes, but couldn't it add news keys without blacklisting old ones?

It is beyond my knowledge of UEFI and secure boot: specs, requirements 
from Microsoft, and state of affairs with bugs in implementations. That 
is why I am suggesting to check for discussions related to shim & grub 
and to ask people involved into their development.

>> 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".
> 
> Do you mean load new EFI files in old Clonezilla?

Yes, I do. My idea is to build custom image of old Clonezilla with EFI 
files signed by you own keys. The downside is that you need  to install 
your keys to every box where you are going to boot your images.

By the way, perhaps tools for management of secure boot keys allow to 
replace entries causing issues in your case without full reflash of 
BIOS. I have heard that some people wipes Microsoft keys completely to 
have full control what images can be booted on their machines.

>> 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.
> 
> Windows works with or without secure boot, but I'd like to leave it on.
> So far, no Windows update did such thing. I also tried update from 
> Windows 10 to Windows 11, and nothing happened.

Notice, it is still just a hypothesis that your issues are caused by new 
keys and it has to be confirmed by comparison key lists before and after.

If latest installation, repair, etc. images from Microsoft do not cause 
the issue then chances that shim+grub may behave in a similar way is higher.

If booting grub built by Fedora or some other distribution unrelated to 
Debian, does not cause the issue then it may be Debian specific bug. Am 
I right that Clonezilla is based on Ubuntu, so may use same patches?

I do not know what is your threat model, so I am unsure why you consider 
that secure book with revoked keys still provides enough degree of 
protection. My impression is that not so much efforts are required to 
inspect latest CVEs and to trick some signed EFI file to force booting 
of a malicious EFI file. It is a reason why I suggest to disable secure 
boot.

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

#262007

Il 29/09/2023 05:39, Max Nikulin ha scritto:

>> Yes, but couldn't it add news keys without blacklisting old ones?
> 
> It is beyond my knowledge of UEFI and secure boot: specs, requirements 
> from Microsoft, and state of affairs with bugs in implementations. That 
> is why I am suggesting to check for discussions related to shim & grub 
> and to ask people involved into their development.

I'll try. I don't feel confortable at the idea that a live environment 
could do such a change. I think that a live should not modify the 
system. Yes, *you* could do something when it's loaded, but an automatic 
(and silent) modification at grub page seems very bad.

At least a warning "I'm going to blacklist something, do you want to 
continue?".

It's like you call a technician to fix something in your house (wall 
paintings, shower, taps etc), the technician thinks that main door is 
not secure and (also without telling you) alter the door lock and you 
cannot pass anymore. Or cannot use all your keys but only some.

The technician is live key.
And coming back from houses to IT, it's related because technician often 
use live boots to diag and fix.

I see that Clonezilla and Partclone mantainers are working on the 
matter. It's not simple, since the issue happens only on some hardware.

But let's say they'll fix in some month. I'll still be worried about 
live linux environments.

>> Do you mean load new EFI files in old Clonezilla?
> 
> Yes, I do. My idea is to build custom image of old Clonezilla with EFI 
> files signed by you own keys. The downside is that you need  to install 
> your keys to every box where you are going to boot your images.

Doesn't seem practical. I am the mantainer of that disk image: I keep it 
updated, I keep it tested after updates and after modifications I get 
from applications' mantainers.
Then I distribute the image to other technician to deploy new machine 
(or reimage old ones).

I don't have all the machines in my hands. I install only some at the 
customer by myself. Others go from reseller to other technicians and are 
cloned by them with my image.
I should consider compatibility between me and them.

Consider also that these machines' life is with Windows 10. They are 
booted with Clonezilla only before the first install and if the machine 
has to be reimaged because OS is scrambled, disk is dead and replaced etc.

I understand the idea "if some key is blacklisted, it's good that this 
blacklist is enrolled to machines".
But neither Asus (bios from start of September) nor Microsoft (Windows 
11) do that blacklisting. If, say, I don't load Clonezilla at all, 
neither old nor new one, there is no blacklist and the security level is 
the same. Basically, I load new Clonezilla and get old one blacklisted.

Is that extra security level needed?

>> Windows works with or without secure boot, but I'd like to leave it on.
>> So far, no Windows update did such thing. I also tried update from 
>> Windows 10 to Windows 11, and nothing happened.
> 
> Notice, it is still just a hypothesis that your issues are caused by new 
> keys and it has to be confirmed by comparison key lists before and after.

I'll try with
efibootmgr -v
when I have here another machine

I don't know if Clonezilla has this package installed, if not I'll try 
to carry one or more *.debs on my USB key. It's not easy to install 
thing in that environment, because it's not based on a stable version 
but on Sid.

So when you read Clonezilla changelogs you don't read "Debian 10,11 
etc", instead you find "based on Sid of a particular date".

It took many tries to carry partclone*.deb I had downloaded from deb-src 
and then recompiled with modified source to test a flag. Many tries to 
find right Debian version.

> If latest installation, repair, etc. images from Microsoft do not cause 
> the issue then chances that shim+grub may behave in a similar way is 
> higher.
> 
> If booting grub built by Fedora or some other distribution unrelated to 
> Debian, does not cause the issue then it may be Debian specific bug. Am 
> I right that Clonezilla is based on Ubuntu, so may use same patches?

Clonezilla come in many flavours, the main line is based on Debian 
(stable - testing) and the alternate one is based on Ubuntu (alternate 
stable - alternate testign).

I'll try also with a non related distribution, as you suggest.

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

#262104

On 30/09/2023 20:53, Valerio Vanni wrote:
> Il 29/09/2023 05:39, Max Nikulin ha scritto:
> 
>> That is why I am suggesting to check for discussions related to shim & 
>> grub and to ask people involved into their development.
> 
> I'll try. I don't feel confortable at the idea that a live environment 
> could do such a change.

In general I agree with you, but some restrictions may exist.

> At least a warning "I'm going to blacklist something, do you want to 
> continue?".

It is just speculation. To show a warning you need to execute some code. 
However .efi file is considered unsafe due to unknown signature. I have 
no idea concerning origin of code that injects newer keys. It should be 
some special case for secure boot.

>> Yes, I do. My idea is to build custom image of old Clonezilla with EFI 
>> files signed by you own keys. The downside is that you need  to 
>> install your keys to every box where you are going to boot your images.
> 
> Doesn't seem practical. I am the mantainer of that disk image: I keep it 
> updated, I keep it tested after updates and after modifications I get 
> from applications' mantainers.

You may ask Clonezilla developers to make an image with old version and 
new grub-signed and shim-signed. I think, you even could do it yourself. 
Take an old image, put EFI, grub directories and kernel files from a new 
image. Perhaps adjust some config files if they include Clonezilla 
version. This way allows to avoid dealing with custom secure boot keys.

> But neither Asus (bios from start of September) nor Microsoft (Windows 
> 11) do that blacklisting.

Do you mean Windows install on hard drive or Windows install image?

>> Notice, it is still just a hypothesis that your issues are caused by 
>> new keys and it has to be confirmed by comparison key lists before and 
>> after.
> 
> I'll try with
> efibootmgr -v
> when I have here another machine

This particular command lists boot entries (location of .efi file to 
boot), not secure boot keys. I mentioned it because I had an issue 
namely with boot entries. In your case they may be unaffected.

If firmware has the "EFI shell" option then you may try "bcfg boot dump 
-v". Unsure if it is possible to redirect output to a file.

> I don't know if Clonezilla has this package installed,

Then you may try any other live image. Perhaps some of Debian live, 
grml, system rescue have necessary tools installed.

> Clonezilla come in many flavours, the main line is based on Debian 
> (stable - testing) and the alternate one is based on Ubuntu (alternate 
> stable - alternate testign).
> 
> I'll try also with a non related distribution, as you suggest.

I mean an image from Fedora, not Clonezilla based on Fedora.

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

#262105

Il 02/10/2023 18:45, Max Nikulin ha scritto:

>> At least a warning "I'm going to blacklist something, do you want to 
>> continue?".
> 
> It is just speculation. To show a warning you need to execute some code. 

Yes, but I would trust a code that asks before doing some potentially 
disruptive change.
I don't want to consider a live environment like a virus. I'd like to 
considere it the opposite, a "safe thing" that leaves thing untouched.

>>> Yes, I do. My idea is to build custom image of old Clonezilla with 
>>> EFI files signed by you own keys. The downside is that you need  to 
>>> install your keys to every box where you are going to boot your images.
>>
>> Doesn't seem practical. I am the mantainer of that disk image: I keep 
>> it updated, I keep it tested after updates and after modifications I 
>> get from applications' mantainers.
> 
> You may ask Clonezilla developers to make an image with old version and 
> new grub-signed and shim-signed. I think, you even could do it yourself.

For now, it seems more practical to use old Clonezilla. I don't have 
such control on the deploying chain (i.e. what version other technician 
use), so I have to point towards compatibility.

For security: if Asus and Microsoft (usual "house owners") are happy 
with a certain blacklist, I don't feel myself culprit of "making the 
machine less secure" if i *don't load* a Linux version that blacklists 
older ones.

Don't forget that the only times I break secure boot is when I test news 
Clonezilla versions.

Now 2.8.1-12 works. It's fast, it loads without issues on the machines 
where I need it. In few words, it does its job. Perhaps it's also 
forward compatible (I didn't test with an image taken from the latest, 
for some version it was compatibile).

I still hope that performance issue is fixed in future releases, it's 
not wise taking for sure that 2.8.1-12 will work forever, on other 
machines etc. It could be that in 2 years a chipset not supported come out.

But during last week I changed my plan. Before was "start to use new 
Clonezilla as soon as it is fixed".
Now it's "Good when it's fixed, but I'll use 2.8 as long as it works".

>> But neither Asus (bios from start of September) nor Microsoft (Windows 
>> 11) do that blacklisting.
> 
> Do you mean Windows install on hard drive or Windows install image?

Machine comes with Windows 10 pre installed, and then it's updated from 
Windows update. Then I installed Windows 11 with upgrade assistant.
So far, no blacklist of old Clonezilla.

Do you mean that installing Windows 10 or 11 from scratch could behave 
differently?

>>> Notice, it is still just a hypothesis that your issues are caused by 
>>> new keys and it has to be confirmed by comparison key lists before 
>>> and after.
>>
>> I'll try with
>> efibootmgr -v
>> when I have here another machine
> 
> This particular command lists boot entries (location of .efi file to 
> boot), not secure boot keys. I mentioned it because I had an issue 
> namely with boot entries. In your case they may be unaffected.
> 
> If firmware has the "EFI shell" option then you may try "bcfg boot dump 
> -v". Unsure if it is possible to redirect output to a file.

I'll try. Is there nothing inside Linux efi tools?

>> I don't know if Clonezilla has this package installed,
> 
> Then you may try any other live image. Perhaps some of Debian live, 
> grml, system rescue have necessary tools installed.

No, I want to see the condition without loading newer Linux versions.
Otherwise, I'd see the condition generated by that live.

Unless I find a "live as I like it" (meaning that doesn't alter secure 
boot).

>> Clonezilla come in many flavours, the main line is based on Debian 
>> (stable - testing) and the alternate one is based on Ubuntu (alternate 
>> stable - alternate testign).
>>
>> I'll try also with a non related distribution, as you suggest.
> 
> I mean an image from Fedora, not Clonezilla based on Fedora.

Yes, it was clear.

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

#262163

On 03/10/2023 01:34, Valerio Vanni wrote:
> Il 02/10/2023 18:45, Max Nikulin ha scritto:

>>> But neither Asus (bios from start of September) nor Microsoft 
>>> (Windows 11) do that blacklisting.
>>
>> Do you mean Windows install on hard drive or Windows install image?
should be "installed"---------^
> 
> Machine comes with Windows 10 pre installed, and then it's updated from 
> Windows update. Then I installed Windows 11 with upgrade assistant.
> So far, no blacklist of old Clonezilla.
> 
> Do you mean that installing Windows 10 or 11 from scratch could behave 
> differently?

I am curious if just booting a recent media published by Microsoft (not 
install, just booting till first dialog) may change secure boot keys. If 
I have got you right, Windows with all updates installed still allows to 
boot old Clonezilla.

I just have spotted in the news
https://security-tracker.debian.org/tracker/CVE-2023-4692
"Crafted file system images can cause heap-based buffer overflow and may 
allow arbitrary code execution and secure boot bypass"

and a related link

https://github.com/rhboot/shim/blob/main/SBAT.md
Secure Boot Advanced Targeting

>> If firmware has the "EFI shell" option then you may try "bcfg boot 
>> dump -v". Unsure if it is possible to redirect output to a file.
> 
> I'll try. Is there nothing inside Linux efi tools?

Sorry, your question is unclear for me. I was trying to suggest a way to 
inspect UEFI boot variables without disturbing its state. If Linux 
images may do something with secure boot keys then I see the following 
alternatives:
- Firmware may have EFI shell boot option included
- Perhaps there are some tools for Windows

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

#262167

Il 04/10/2023 17:11, Max Nikulin ha scritto:

>>>> But neither Asus (bios from start of September) nor Microsoft 
>>>> (Windows 11) do that blacklisting.
>>>
>>> Do you mean Windows install on hard drive or Windows install image?
> should be "installed"---------^

Ok, "installed".

> I am curious if just booting a recent media published by Microsoft (not 
> install, just booting till first dialog) may change secure boot keys. If 
> I have got you right, Windows with all updates installed still allows to 
> boot old Clonezilla.

I'll try. Now I don't have the machine.

>>> If firmware has the "EFI shell" option then you may try "bcfg boot 
>>> dump -v". Unsure if it is possible to redirect output to a file.
>>
>> I'll try. Is there nothing inside Linux efi tools?
> 
> Sorry, your question is unclear for me. I was trying to suggest a way to 
> inspect UEFI boot variables without disturbing its state. If Linux 
> images may do something with secure boot keys then I see the following 
> alternatives:
> - Firmware may have EFI shell boot option included
> - Perhaps there are some tools for Windows

I don't know if there is an EFI shell.

For Linux, I found this (there's no version for Debian):
https://github.com/rhboot/dbxtool

But it says it was replaced by this:
https://github.com/fwupd/fwupd

I'll try.

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

#262181

On 05/10/2023 04:06, Valerio Vanni wrote:
> 
> I don't know if there is an EFI shell.

I am not sure, but some motherboards may have it preinstalled. Check 
files on EFI system partition. It may be available in boot menu invoked 
by some F* key (not grub menu), it may be necessary to enable it in 
Firmware (BIOS) settings. On a screenshot of AMI bios some related 
option is present in "Exit" menu in advanced mode.

Some commands and links:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#UEFI_Shell

> For Linux, I found this (there's no version for Debian):
> https://github.com/rhboot/dbxtool
> 
> But it says it was replaced by this:
> https://github.com/fwupd/fwupd

My impression is that fwupd may install updates if they are provided by 
hardware vendors.

Concerning secure boot keys, I would start from mokutil, but since I 
never debugged similar issues, I am not sure.

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

#262297

Il 04/10/2023 17:11, Max Nikulin ha scritto:

>> from Windows update. Then I installed Windows 11 with upgrade assistant.
>> So far, no blacklist of old Clonezilla.
>>
>> Do you mean that installing Windows 10 or 11 from scratch could behave 
>> differently?
> 
> I am curious if just booting a recent media published by Microsoft (not 
> install, just booting till first dialog) may change secure boot keys. If 
> I have got you right, Windows with all updates installed still allows to 
> boot old Clonezilla.

Just booting had no effect. Even a Windows 11 complete install from 
scratch (on empty disk) does not block old Clonezilla boot.

Tried also with "get latest updates as soon as they are available" option.

I did it to exclude something not standard in OEM installation.

>>> If firmware has the "EFI shell" option then you may try "bcfg boot 
>>> dump -v". Unsure if it is possible to redirect output to a file.
>>
>> I'll try. Is there nothing inside Linux efi tools?
> 
> Sorry, your question is unclear for me. I was trying to suggest a way to 
> inspect UEFI boot variables without disturbing its state. If Linux 
> images may do something with secure boot keys then I see the following 
> alternatives:
> - Firmware may have EFI shell boot option included
> - Perhaps there are some tools for Windows

Now I have a machine again. No, there is only the entry for "EFI shell", 
but no one is included in firmware.
It wants it on a usb key, and says that you have to disable secure boot 
to make it work.

So it doesn't seem to be a good diagnostic platform for secure boot.

My idea is to load tools on old Clonezilla, to compare the condition 
between before and after new Clonezilla boot.
I cannot use a new Linux, because I would see a just changed condition.

EDIT:
Now I've tried Fedora live: it doesn't act like Debian. After it, I can 
still boot old Clonezilla. Not only at grub page: I can also load live 
environment.
This is what I expect from a live.
So I can use it to dig into secure boot keys.

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

#262298

On 11/10/2023 08:46, Valerio Vanni wrote:
> Now I've tried Fedora live: it doesn't act like Debian. After it, I can 
> still boot old Clonezilla. Not only at grub page: I can also load live 
> environment.

If the Fedora image is fresh enough then there are some patches either 
in Fedora or in Debian. Perhaps the following one

https://sources.debian.org/src/shim/15.7-1/debian/patches/block-grub-sbat3-debian.patch/

You may check changelog, closed debian bugs, messages in developer 
mailing lists for the shim package (shim-signed and shim-unsigned) and 
may try to discuss the issue with shim maintainers.

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

#262303

Il 11/10/2023 04:13, Max Nikulin ha scritto:
> On 11/10/2023 08:46, Valerio Vanni wrote:
>> Now I've tried Fedora live: it doesn't act like Debian. After it,
>> I can still boot old Clonezilla. Not only at grub page: I can also 
>> load live environment.
> 
> If the Fedora image is fresh enough

Yes, it's version 38.
I add that I tried to make it resident (install on internal disk), and 
neither this way it changes anything.

It satisfies Secure Boot requirements, but it doesn't blacklist anything.
So it doesn't seem true what whas said (don't remember by who) at the 
start of this thread, that if a system supports SB blacklists older 
images for sure.

It seems a choice. A bad choice for a live environment.

> then there are some patches either in Fedora or in Debian. Perhaps
> the following one
> 
> https://sources.debian.org/src/shim/15.7-1/debian/patches/block-grub-sbat3-debian.patch/
>
 > You may check changelog, closed debian bugs, messages in developer
> mailing lists for the shim package (shim-signed and shim-unsigned) 
> and may try to discuss the issue with shim maintainers.

With Fedora Live I could see the difference, using
# mokutil --list-sbat-revocations.

When the system is in one of these states:
-new
-reflashed
-after old clonezilla (grub entries) load
-after Fedora live load or Fedora install

This list is
sbat,1,202103218

After load of grub page of a new Clonezilla (or live Debian) the list 
becomes:

sbat,1,2022052400
grub,2

[toc] | [prev] | [standalone]

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

csiph-web