Linux Group Files Complaint With EU Over SecureBoot

[nomadewolf]

How do you use the Linux Foundation bootloader to boot malware without the user's knowledge?

Meet my new distro 'nomadewolf's' Hacker Linux, which allows you to get access to your friends computer's and put pranks on them...
Done.
You know that's how viruses spread in ANY environment


EDIT: Also, secure boot, only 'secures' boot. After you boot, Windows only checks for Kernel and drivers integrity. If keys lists can be updated, so can any malware change boot settings and install itself.
You can only enforce security, if you secure the whole OS, and everything u use.
What performance you think your PC would have with 20 to 100GB+ encrypted stuff?

EDIT 2: (almost forgot)
Secure Boot is not secure!!!
Secure Boot is not secure!!!
Secure Boot is not secure!!!

[mjg59]

Meet my new distro 'nomadewolf's' Hacker Linux, which allows you to get access to your friends computer's and put pranks on them...
Done.
You know that's how viruses spread in ANY environment

And then your grub hash gets blacklisted and it stops working.

EDIT: Also, secure boot, only 'secures' boot. After you boot, Windows only checks for Kernel and drivers integrity. If keys lists can be updated, so can any malware change boot settings and install itself.

Key lists can only be updated if the update is signed. It's not possible for malware to automatically install itself.

[nomadewolf]

And then your grub hash gets blacklisted and it stops working.

It's the Linux Foundations' grub hash. They'll need to get another, and it all starts again. Meanwhile Linux stops working on many machines... (unless the Distro disables UEFI on first boot)

Key lists can only be updated if the update is signed. It's not possible for malware to automatically install itself.

Yes.
But...
If i'm not mistaken, it's possible, according to the UEFI specification to disable UEFI from the OS. All that malware has to do is THAT. And then the boot process is unchecked, and anything can boot.

Secure Boot is not secure!!!
Secure Boot is not secure!!!
Secure Boot is not secure!!!

[mjg59]

It's the Linux Foundations' grub hash.

The Linux Foundation don't have a grub hash.

They'll need to get another, and it all starts again. Meanwhile Linux stops working on many machines... (unless the Distro disables UEFI on first boot)

Nope. The only thing that stops working is your code. But, again, this isn't a case of malware being installed without the user's knowledge - the user has explicitly chosen to install a new OS. It can't be done automatically without the user engaging in a series of explicit acts.

If i'm not mistaken, it's possible, according to the UEFI specification to disable UEFI from the OS. All that malware has to do is THAT. And then the boot process is unchecked, and anything can boot.

You're mistaken

[nomadewolf]

The Linux Foundation don't have a grub hash.



Nope. The only thing that stops working is your code. But, again, this isn't a case of malware being installed without the user's knowledge - the user has explicitly chosen to install a new OS. It can't be done automatically without the user engaging in a series of explicit acts.



You're mistaken

You sure?
I think i read somewhere (probably in Phoronix.com) that the Linux Foundations' Grub is just so you can be able to boot your CD/USB installation of your favourite distro, which in turn will ask to deactivate UEFI and provide an easy way (like: one click) to deactivate it. And then Linux can be booted and installed normally.

Also, i haven't read the bible that is the UEFI (EDIT: specification), so i want to make it very clear that what i'm going to say next is what seems more logical to me and what i perceive from the information i am sure about. That said, i think it's much easier to black list the key that was used to boot malware, than the hash of the said malware. Furthermore, i don't know if there are memory requirements, or what those are, storing and updating every single hash string of malicious code... how much space would that take after a year? and after 10?

In another hand, assuming you are right, and that in fact what is backlisted, is the hash of the malware, i don't even have to update my Grub and wait for Linux Foundation to get and share a new key, all i have to do is change one line of code, and my hash will be different. I would be able to create 'new' hashes MUCH faster than M$ would be able to blacklist, and push the updates into the machines.

If anything, M$ only managed to create a new way to hack your PC, and to guarantee that malware will be trusted. All in the name of keeping Linux away from your PC, that you payed for...


Secure Boot is not secure!!!
Secure Boot is not secure!!!
Secure Boot is not secure!!!

[mjg59]

You sure?

Yes. You don't know what you're talking about.

I think i read somewhere (probably in Phoronix.com) that the Linux Foundations' Grub is just so you can be able to boot your CD/USB installation of your favourite distro, which in turn will ask to deactivate UEFI and provide an easy way (like: one click) to deactivate it. And then Linux can be booted and installed normally.

No, that's not how it works.

Also, i haven't read the bible that is the UEFI (EDIT: specification), so i want to make it very clear that what i'm going to say next is what seems more logical to me and what i perceive from the information i am sure about. That said, i think it's much easier to black list the key that was used to boot malware, than the hash of the said malware.

No, it's much easier to blacklist the hash - 256 bits against 2048.

Furthermore, i don't know if there are memory requirements, or what those are, storing and updating every single hash string of malicious code... how much space would that take after a year? and after 10?

How many signed pieces of malware are there going to be?

In another hand, assuming you are right, and that in fact what is backlisted, is the hash of the malware, i don't even have to update my Grub and wait for Linux Foundation to get and share a new key, all i have to do is change one line of code, and my hash will be different. I would be able to create 'new' hashes MUCH faster than M$ would be able to blacklist, and push the updates into the machines.

And what would be the point? You're still going to have to socially engineer people into wanting to install your OS, which I think you're going to have trouble with.

[dee.]

Ok, so where are the grub hashes stored and where do blacklist updates to grub hashes come from? Are they stored and updated the same way as the UEFI keys, or are they just stored in the bootloader itself, and blacklisting the grub hash requires updating the bootloader itself?

Also, self-modifying code. Polymorphic viruses. Malware whose hash never stays the same...

Also also: at least according to what I read on the LKML, Matthew Garret himself - the main UEFI proponent in the Linux camp - seems to be worried that malware authors could abuse Linux bootloaders (or Linux itself) which would cause MS to revoke the UEFI key.

https://lkml.org/lkml/2013/2/25/228

> Seriously, folks, can we go back one step and discuss what problem you
> are trying to solve? Is it about allowing third-party kernel modules
> in an environment which does not allow unsigned ring 0 code execution?

The problem I'm trying to solve is "Don't permit Linux to be used as a
bootloader for backdoored versions of other operating systems". Any
other security benefit is a happy side effect.

This, to me, is pure idiocy. Linux is all about user control. Linux doesn't need any "trusted computing" features that disallows the user from using their software in whatever way we please. It's not the kernel's job to prevent the kernel from being used maliciously, just to satisfy some kind of microsoft trust model that is malicious to Linux in the first place. Thankfully, Linus seems to agree with me.

https://lkml.org/lkml/2013/2/21/228

If Red Hat wants to deep-throat Microsoft, that's *your* issue. That
has nothing what-so-ever to do with the kernel I maintain.

[mjg59]

Ok, so where are the grub hashes stored

In a secure variable that can't be accessed from outside the firmware.

and where do blacklist updates to grub hashes come from?

Whoever has a key that your machine has in KEK. For most machines, that means Microsoft.

Are they stored and updated the same way as the UEFI keys

Yes.

or are they just stored in the bootloader itself, and blacklisting the grub hash requires updating the bootloader itself?

No.

Also, self-modifying code. Polymorphic viruses. Malware whose hash never stays the same...

And so doesn't match the whitelist hash that the LF loader has installed for you, so still doesn't boot.

Also also: at least according to what I read on the LKML, Matthew Garret himself

ie, me.

- the main UEFI proponent in the Linux camp - seems to be worried that malware authors could abuse Linux bootloaders (or Linux itself) which would cause MS to revoke the UEFI key.

There's no such thing as "The UEFI key", and you've misunderstood that conversation.

This, to me, is pure idiocy. Linux is all about user control. Linux doesn't need any "trusted computing" features that disallows the user from using their software in whatever way we please. It's not the kernel's job to prevent the kernel from being used maliciously, just to satisfy some kind of microsoft trust model that is malicious to Linux in the first place. Thankfully, Linus seems to agree with me.

You and Linus don't have to take responsibility for ensuring that distributions remain installable.

[nomadewolf]

Yes. You don't know what you're talking about.

No, that's not how it works.

Already admited that i don't know, and won't dispute.
Also, 2 lazy to find out...

No, it's much easier to blacklist the hash - 256 bits against 2048.

In a simplistic perspective: blacklisting 256 bits is easier than blacklisting 2048
But...
Those 2048 would already be in memory. With just 1 extra bit, we could control if it's good or bad. Whilst adding the 256 bits of the malware, would be 255 extra bits.
Also, since the process of creating a new key, and distributing it is slower and more complex, much less would be created. Would it be enough to make a difference? One can only speculate, i admit.

How many signed pieces of malware are there going to be?

This i know for sure.
It's not the malware that is going to be signed. It's the Linux Foundations' bootloader. None of the genuine Linux kernels will be signed. The malware won't have to also.
Writing this i just realized the following:
I thought that it would the the keys that would be blacklisted. But you say that is the malware. I was having trouble understanding how exactly that would work, but now i think i get it.
What you mean that will be blacklisted is the software that is signed, correct? Since what the Linux Foundation will be distributing is a signed bootloader, which in turn can be used to boot whatever software(Linux)/malware you want.
This means that i wouldn't even have to re-write malware, since the bootloader is what would be blacklisted.

Which brings a new problem: even the Linux Foundations' bootloader is not malware, it will be blacklisted and forced to be modified, without any need for it...

YES, this means that Linux won't be taking advantage of the UEFI 'security' features.

And what would be the point? You're still going to have to socially engineer people into wanting to install your OS, which I think you're going to have trouble with.

What is the point with all the malware around? Isn't that how virtually every piece of malware spreads? 'My OS' is just a suggestion of the top of my head.


Bottom line is:
Secure Boot is not secure!!!
Secure Boot is not secure!!!
Secure Boot is not secure!!!

[Gps4l]

Put a post somewhere on an internet forum telling people they can get 5% better graphics performance by loading <xxx> using the bootloader, that they should expect the following warning messages, and that they should ignore them all

lmao, I noticed this to be true, with the tux for Linux on steam.

People weer blindly giving some program 100% acces.