There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Zorsith ,
@Zorsith@lemmy.blahaj.zone avatar

Select models of:

Acer

Dell

Gigabyte

Intel

Supermicro

aopen

formelife

You’re welcome.

Vilian ,

o7

harsh3466 ,

Doing the lord’s work here!

Buffalox ,

Secure Boot is a broken concept by design.

cheese_greater ,

Can you explain more (don’t doubt you)

ilinamorato ,

Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.

The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.

And it’s not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.

But OP might have other reasons in mind, I dunno.

cmnybo ,

To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.

homesweethomeMrL ,

To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.

You dare question a monopoly corporation and the spymasters of this country??

(/s)

dan ,
@dan@upvote.au avatar

lol at the DO NOT TRUST keys.

I’ve learnt over the years that you have to make the example code fail to compile or print out huge user-visible warnings or something like that, otherwise people can and will use it as-is in production, hard-coded keys and all.

Even if you make it print out a huge message, some manufacturers will just comment that out while keeping all the other dummy example data.

I’ve seen several production OAuth/OpenID servers that accepted an app ID and secret from a “how to set up an OAuth server” tutorial, and in one case the company was using that app ID for all their production services.

adarza ,

i like how the manufacturers who responded to the author’s queries basically said ‘tough shit, that product is out of support’

fubarx ,

The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text.

It’s like installing a top-of-the-line alarm system for your house with camera, motion detector, alarm, and immobilizing gas, then leaving the unlock password on a PostIt under the welcome mat.

TimeSquirrel ,
@TimeSquirrel@kbin.melroy.org avatar

immobilizing gas

BRB, setting up a new automation in Homeassistant...

cheese_greater ,

This needs to be a thing

TimeSquirrel ,
@TimeSquirrel@kbin.melroy.org avatar

ESP32 running ESPHome connected to a MOSFET and relay, which operates a solenoid valve on the canister of gas. Don't let dreams be dreams.

cheese_greater ,

As long as there’s some left for the dr. A little delphic courage

homesweethomeMrL ,

It’s totally a thing, bro. Here take a hit off this immobilizing gas bubble pipe

cheese_greater ,

CrystalLit

DarkPassenger ,
@DarkPassenger@lemmy.world avatar

Send yaml

tal , (edited )
@tal@lemmy.today avatar

“It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”

I mean, I don’t really have much interest in requiring that my BIOS code be signed, but I have a hard time believing that this Martin Smolár guy is correct. Just entirely disable firmware updates in the BIOS, and re-enable just for the one boot where you update your BIOS while booting off a trusted USB key. You’d never put your OS in a position of being able to push an update to the BIOS.

EDIT: Actually, if current BIOSes can update without booting to an OS at all, just selecting a file on a filesystem that they can understand – IIRC my last Asus motherboard could do that – you never need to enable it for even that.

SzethFriendOfNimi ,

I think Secure boot is intended to check that the boot loader itself is signed.

This is a way to mitigate viruses and malware that infects the boot loader so it can reinstall itself if it’s removed by AV, or something else.

If you can create a boot loader that is signed in such a way that secure boot can’t tell it’s invalid then you can do some nasty stuff.

Closest analogy I can think of is verisigns private key being leaked and there’s no fast and easy way to revoke and replace it without wreaking havoc on currently installed OS’s machines.

j4k3 ,
@j4k3@lemmy.world avatar

K-rapy garboge!:

There’s little that users of an affected device can do other than install a patch if one becomes available from the manufacturer.

Gentoo gives extensive instructions:

Arch:

NIST (US government guides cover POSIX/Windows with a layperson explanation and guide):

The technical documentation about Secure Boot says that SB is not a mechanisms to steal ownership of your device. It is a spurious claim because the design specification is only a reference and not a requirement. Gentoo has further documentation that can be found describing KeyTool, a package that enables booting directly into UEFI to change the keys manually if your implemented UEFI bootloader lacks the functional implementation required to sign your own keys. I’ve never tried it personally. I merely know of its existence.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •