UEFI + SecureBoot : a bless or a disaster?

If it doesn't relate to Debian, but you still want to share it, please do it here

UEFI + SecureBoot : a bless or a disaster?

Postby LE_746F6D617A7A69 » 2020-08-02 18:49

Following the HOAS suggestion from Debian 10.5 point release I'm moving here to answer some posts, to avoid de-railing of the original topic.

Head_on_a_Stick wrote:
Bloom wrote:The main reason for SecureBoot was not to increase security (at least not what we understand as "security"): the intention was to ensure that computers would not boot Linux anymore.

Then why are Microsoft happy to provide their signing keys to Linux distributions? There is a fee but it's set to $99 so they're not really making any money from it.

Secure Boot was introduced in an attempt to compensate for the massive added attack surface provided by the UEFI standard.

Any discussion about Secure Boot is off-topic for this thread so please open a new one to discuss the issues further. Thanks.

1. I don't think that MS is *happy* - I think that probably they were shocked that their plan to block Linux on desktop showed up to be so easy to mitigate - only $99 was needed :lol:
2. SecureBoot does not fix or compensate anything - modified bootloaders can also be signed - of course, this requires root privileges - but how it is different from writing to MBR in the BIOS era?.

p.H wrote:
LE_746F6D617A7A69 wrote:I wonder when (if ever) we'll see an update for broken UEFI specs - what a moron have released a standard which breaks booting from RAID arrays?

I guess you mean software Linux RAID ? AFAICS GRUB is the culprit, not UEFI.

Nope, it's not a problem with GRUB - the UEFI GRUB has to be loaded from EFI partition first, so unless the RAID driver is build into UEFI itself, You can't boot *any* of RAID-based systems directly.
This obviously breaks *ALL* the software raids, f.e. based on md, lvm or btrfs, but also it causes problems with some HW Raid controllers due to notorious bugs in UEFI firmware.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 345
Joined: 2020-05-03 14:16

Re: UEFI + SecureBoot : a bless or a disaster?

Postby Head_on_a_Stick » 2020-08-02 19:05

LE_746F6D617A7A69 wrote:SecureBoot does not fix or compensate anything - modified bootloaders can also be signed - of course, this requires root privileges - but how it is different from writing to MBR in the BIOS era?

I create my own keys, enrol them and sign the kernel myself. Encrypted systems can use custom keys in combination with a TPM to create a verified boot chain, which is useful.

Don't get me wrong — Secure Boot is far from perfect but it's better than nothing and it does provide a layer of protection against rootkits and the like.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12495
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: UEFI + SecureBoot : a bless or a disaster?

Postby neuraleskimo » 2020-08-02 19:28

Going off topic a bit (but still slightly related) which seems OK here..

I can't find the (better) article I read originally, but here is something from Wired. https://www.wired.com/story/dark-metal- ... e-malware/

I agree with HOAS that SecureBoot is a step in the right direction, but the exploit above is just one example of how computer security is still a f***ing mess (even at this low level).
Black Lives Matter
User avatar
neuraleskimo
 
Posts: 193
Joined: 2019-03-12 23:26
Location: Bloomington, Indiana, USA

Re: UEFI + SecureBoot : a bless or a disaster?

Postby p.H » 2020-08-02 19:54

LE_746F6D617A7A69 wrote:Nope, it's not a problem with GRUB - the UEFI GRUB has to be loaded from EFI partition first, so unless the RAID driver is build into UEFI itself, You can't boot *any* of RAID-based systems directly.

What do you mean by "boot directly" ?

You can create an EFI partition on each disk and install a copy of the bootloader in each of them. This is enough to ensure boot redundancy.

On the other hand, AFAIK GRUB setup tool (grub-install) expects that the (one) EFI partition is mounted on /boot/efi and does not support multiple EFI partitions natively. Also, Debian signed GRUB does not support creating extra boot entries with different names because the name "debian" is hardcoded into the signed core image.
p.H
 
Posts: 1438
Joined: 2017-09-17 07:12

Re: UEFI + SecureBoot : a bless or a disaster?

Postby LE_746F6D617A7A69 » 2020-08-03 06:48

p.H wrote:
LE_746F6D617A7A69 wrote:Nope, it's not a problem with GRUB - the UEFI GRUB has to be loaded from EFI partition first, so unless the RAID driver is build into UEFI itself, You can't boot *any* of RAID-based systems directly.

What do you mean by "boot directly" ?

You can create an EFI partition on each disk and install a copy of the bootloader in each of them. This is enough to ensure boot redundancy.

On the other hand, AFAIK GRUB setup tool (grub-install) expects that the (one) EFI partition is mounted on /boot/efi and does not support multiple EFI partitions natively. Also, Debian signed GRUB does not support creating extra boot entries with different names because the name "debian" is hardcoded into the signed core image.

Indeed, the term "directly" is a little bit unfortunate - but it looks like You already know what I mean ;)

grub-install has a partial support for the above "workaround" - it has the "--efi-directory=" option, so it's possible to update all the EFI partitions from a script, but still, it's just a workaround for an obvious bug in the UEFI specs.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 345
Joined: 2020-05-03 14:16

Re: UEFI + SecureBoot : a bless or a disaster?

Postby Deb-fan » 2020-08-03 11:11

Been pointlessly griping secureboot is mostly useless since it came out. Would have to +1 Head_on, guess its another layer of security only I dont see how its one worth much to anyone. The never ending game of security, counter-sec continues as always. Mal-coders, software pirates and others were sure to find exploits and ways to use or counter it quickly, no matter what. Did think it'd be a bigger barrier to gnu/linux users though. Due to antitrust, anti-monopoly, consumer protection laws etc, it was only a matter of time before open source was provided ways around. Was somewhat surprised and pleased how quickly it happened though. Corporations like Redhat, Intel/Amd, Google etc etc (clear fact that the gnu/linux platform dominates enterprise-production areas of tech) ensured it was bound to happen.

A lot of big interests, with big money, quickly paved the way for self signed keys, disabling secureboot etc. Thought MS was going to put up a much longer-protracted legal fight over it. Screaming about having security reasons to a bitter end in some high court and leaving pc users who wanted windows alternatives struggling to much greater extent. At this point just glad it played out like it has. Blessing or curse ? Think its just another thing. My approach for dealing with secureboot, after going through a bunch of time n aggravation researching wth it is/does, has always been to just disable the stupid thing. Still mostly write secureboot off as a failed MS campaign aimed at consumer lock-in and/or counter piracy effort. Theres many parts of the bigger picture we'll never see. So might be an overall successful campaign for MS. The numbers never lie and we'll never see the accurate numbers involved.

Biggest threat to pc-security are the users/admin. That's unlikely to ever change. :) Also been pointlessly whining forever about how pointless much of this is, when we're all relying on closed source firmware and drivers and proprietary components regardless.
Most powerful FREE tech-support tool on the planet * HERE. *
Deb-fan
 
Posts: 895
Joined: 2012-08-14 12:27

Re: UEFI + SecureBoot : a bless or a disaster?

Postby Deb-fan » 2020-08-03 12:02

Building on that above, secureboot is likely a leap forward in security, helping secure and consolidate MS's position or interests, not so much of benefit to the endusers of their products though. Also sort of related, looked up this grub2 exploit thing and keep reading boothole as butthole, is this happening to anyone else? :P
Most powerful FREE tech-support tool on the planet * HERE. *
Deb-fan
 
Posts: 895
Joined: 2012-08-14 12:27

Re: UEFI + SecureBoot : a bless or a disaster?

Postby LE_746F6D617A7A69 » 2020-08-03 12:28

Deb-fan wrote:Also sort of related, looked up this grub2 exploit thing and keep reading boothole as butthole, is this happening to anyone else? :P
Me too :mrgreen:
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 345
Joined: 2020-05-03 14:16

Re: UEFI + SecureBoot : a bless or a disaster?

Postby Deb-fan » 2020-08-03 12:52

^ Thank goodness, was starting to worry. Brain reads boothole, automatically translates it as butthole, weird. Do have to wonder about their choice in naming this, in Europe isnt boot = butt many places? Like the trunk(backend-rearend) of a car, called the boot?
Most powerful FREE tech-support tool on the planet * HERE. *
Deb-fan
 
Posts: 895
Joined: 2012-08-14 12:27

Re: UEFI + SecureBoot : a bless or a disaster?

Postby LE_746F6D617A7A69 » 2020-08-03 13:04

Deb-fan wrote:Brain reads boothole, automatically translates it as butthole, weird.
Very weird, indeed... :roll: :D
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 345
Joined: 2020-05-03 14:16

Re: UEFI + SecureBoot : a bless or a disaster?

Postby Deb-fan » 2020-08-03 13:51

In the news today, problems were discovered with the Linux bootloader, there are security concerns about the boothole in it? Errrr, not exactly flattering. :/

:D
Most powerful FREE tech-support tool on the planet * HERE. *
Deb-fan
 
Posts: 895
Joined: 2012-08-14 12:27

Re: UEFI + SecureBoot : a bless or a disaster?

Postby neuraleskimo » 2020-08-03 14:37

Just started reading this month's (August 2020) issue of IEEE Computing Edge. It is focused on security and has articles on trusted execution environments, fortifying formal verification, etc. Might be an interesting read for anyone reading this thread.
Black Lives Matter
User avatar
neuraleskimo
 
Posts: 193
Joined: 2019-03-12 23:26
Location: Bloomington, Indiana, USA

Re: UEFI + SecureBoot : a bless or a disaster?

Postby LE_746F6D617A7A69 » 2020-08-05 10:25

If someone claims that his program does not have any bugs, then it only means that he didn't tested the program thoroughly ;)

The probability that the program has a bug grows exponentially with the number of lines of code.
The probability that there's a security hole, grows exponentially with the number of bugs.
The above holds for 100% of software created by humanity so far.

This also explains why after tens of years of development of security systems still we have hundreds of CVEs each year.
I dare to claim that adding countless layers of security is the main factor responsible for countless security holes.

KISS = Keep It Simple, Stupid!

neuraleskimo wrote:Going off topic a bit (but still slightly related) which seems OK here..

I can't find the (better) article I read originally, but here is something from Wired. https://www.wired.com/story/dark-metal- ... e-malware/

I agree with HOAS that SecureBoot is a step in the right direction, but the exploit above is just one example of how computer security is still a f***ing mess (even at this low level).

You know what's funny with this "security hole"? -> this is not a security hole -> such attacks are possible because having root/admin/owner privileges You have the *right* to update the firmware.

But, the above case also shows why SecureBoot is useless: if an attacker can gain root privileges, he can just *anything* no matter if SecureBoot is enabled or not -> f.e. he can change the bootloader with a signed virus code - funny isn't it? So much work was put into development of SecureBoot, and it's worth nothing :LOL:

And even more funny is, that having root privileges You don't have to care about SecureBoot - You're a root - so that unchanged and digitally signed kernel will obey to all your commands!

Simply speaking SecureBoot just adds yet another layer of security, which gives completely nothing besides a false sense of security.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
LE_746F6D617A7A69
 
Posts: 345
Joined: 2020-05-03 14:16

Re: UEFI + SecureBoot : a bless or a disaster?

Postby sunrat » 2020-08-05 11:19

LE_746F6D617A7A69 wrote:If someone claims that his program does not have any bugs, then it only means that he didn't tested the program thoroughly ;)

The probability that the program has a bug grows exponentially with the number of lines of code.
The probability that there's a security hole, grows exponentially with the number of bugs.
The above holds for 100% of software created by humanity so far.


I'd say approaching 100%, not quite there. I recall 2 programs which worked exactly as they were designed from my ancient Windows days - NaDa which did exactly what its name implies, and Dr. Windows which popped up notifications at intervals which told you your computer was protected among other things. :mrgreen:
https://www.donationcoder.com/software/ ... dr-windows
Image
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!
User avatar
sunrat
 
Posts: 3193
Joined: 2006-08-29 09:12
Location: Melbourne, Australia

Re: UEFI + SecureBoot : a bless or a disaster?

Postby neuraleskimo » 2020-08-05 13:08

LE_746F6D617A7A69 wrote:
neuraleskimo wrote:Going off topic a bit (but still slightly related) which seems OK here..

I can't find the (better) article I read originally, but here is something from Wired. https://www.wired.com/story/dark-metal- ... e-malware/

I agree with HOAS that SecureBoot is a step in the right direction, but the exploit above is just one example of how computer security is still a f***ing mess (even at this low level).

You know what's funny with this "security hole"? -> this is not a security hole -> such attacks are possible because having root/admin/owner privileges You have the *right* to update the firmware.

But, the above case also shows why SecureBoot is useless: if an attacker can gain root privileges, he can just *anything* no matter if SecureBoot is enabled or not -> f.e. he can change the bootloader with a signed virus code - funny isn't it? So much work was put into development of SecureBoot, and it's worth nothing :LOL:

And even more funny is, that having root privileges You don't have to care about SecureBoot - You're a root - so that unchanged and digitally signed kernel will obey to all your commands!

Simply speaking SecureBoot just adds yet another layer of security, which gives completely nothing besides a false sense of security.


I would not call it a security hole and the issue isn't root access. What the researchers did here was to exploit the fact that the cloud provider (IBM in this instance) did not return the server to it's original state.

The reason I posted this was not to say that SecureBoot is a waste of effort. The reason I posted that article was to encourage a broader discussion on trust (the point the researchers were trying make). Proper operation of secure boot requires that the hardware and software on which it runs is trustworthy. Trust in the hardware and software, in turn, requires trust in the software that built said hardware and software. It is an important point and worthy of thought and discussion (because it is a huge, complicated mess).

SecureBoot does (sort of) what it is supposed to do: make certain types of attacks more difficult. However, it is only one part of a larger line of defense against attacks (what I want to encourage people to think about when discussing computer security). The point isn't perfection. The point is to reduce the probability of a successful attack.

I agree that a false sense of security is a problem which is why I shared the link.
Black Lives Matter
User avatar
neuraleskimo
 
Posts: 193
Joined: 2019-03-12 23:26
Location: Bloomington, Indiana, USA

Next

Return to Offtopic

Who is online

Users browsing this forum: No registered users and 11 guests

fashionable