wanna learn how computers work? learn to code at lowlevel.academy

Jokes on you my motherboard is so old it predates this problem

Ok i guess i will just carve a new rock myself and hope no one will hack it

TempleOS affected :(

> Makes UEFI to solve security exploits in BIOS > Look inside > Exactly the same exploits BIOS has, but more flexible what did they mean by this?

Since I am 73 years old I have seen a lot of computer history. We know that over the years computers have become a lot more powerful, and have a lot more features, a lot more memory and a lot more storage. This has resulted in software of all types becoming a lot larger and a lot more complex. The result is that now nearly all software has unknown and undiscovered vulnerabilities. It is now impossible to eliminate all vulnerabilities. All that can be done is a lot of testing to discover the latest vulnerability.

The fact that we keep inventing negative rings is also a problem. Everything old is new again. Hardware from the 80s used to have a hardware inhibit on floppy drives to prevent, at the hardware level, writing to a disk. Some of the early EEprom motherboards you had to move a jumper to allow the hardware to write to it. Perhaps this should be a new feature. I see that in the Pi4 and 5 you can update the "bios" from a linux command. Write protection at a jumper for this would be nice.

Let's call it what it is: a successful NSA supply chain attack.

As soon as TPM was mentioned, I knew this was not a bug or mistake. This is a backdoor.

"Name the vendor of your motherboard's firmware" AMI. I haven't seen a computer sold with Phoenix BIOS as the firmware vendor in like 10 years.

When the title said the vulnerability lasts forever i thought you meant it was a hardware bug. Got me scared for a sec.

Feature not a bug. Say hello to NSA.

As a firmware developer: UEFI needs to go away. All vendors use basically the same stuff under the hood: EDK2 and FSP (Firmware Support Package). Problem is that EDK2's codebase is not only atrocious, people (or companies) usually work on their own forks and don't contribute it to upstream. Vendors like AMI, Phoenix or InsydeH2O use EDK2 versions that are several years out-of-date (last time I checked, from ~2018). That's why you see so many vulnerabilities in UEFI recently. Vendors basing their products on several-years-old releases, adding their own EFI drivers/apps (yes, EDK2 is basically an operating system that starts your operating system) and ship it to OEMs, who then ship it to users. So to fix the vulnerability vendor has to re-base their code on newer release (or patch it by hand), ship frameworks to OEMs, OEMs need to re-base their configuration on new version of frameworks (GPIO etc) and ship it to users, who need to go trough process of updating it (and we know how many people simply... don't). That's why opensource firmware is important, and should be more popular. Such as coreboot, u-boot and so on. As for this exploit, it likely won't "last forever". Most consumer motherboards use fTPM solutions (like Intel's PTT), which gets wiped on CPU swap (assuming the desktop) - same with SMMSTORE (NVRAM) or CMOS. On laptops however it would be a lot more tricky, but vendor can choose to wipe SMMSTORE on update, as well as TPM (though it would anger quite a few users who would need to find bitlocker recovery keys and whatnot).

Isn't it fascinating how all of this newfangled stuff has these ultra super secure "new" features that we later find have convenient oversights on that secure feature that allow someone in the know complete access to a device?

It's possible to write code that's literally proven formally to not have bugs like this, and it's wild to me that manufacturers don't do it. This UEFI code is the perfect candidate for formal verification. No future remediation path for bugs, universally appears in every product your company sells, and the cost doesn't even change much, since you're already hiring the kind of specialist firms that can do formal software verification. A no-brainer decision for motherboard manufacturers.

You forgot the part where it stays forever. It has to persist somewhere, either in the NVRAM or flash, so erasing both of those would remove the compromised code

Never trusted TPM.

The way Ed's face lights up every time he gets to say "low level" is the kind of passion I aspire to have for something

This was predicted when EFI was first rolled out. EFI is way too complex with not enough eyes on it, and EFI (+ TPM) has always looked like a US gov project. It did not actually solve any problems, unless you problem was how to compromise all machines in perpetuity.

No wonder Microsoft was pushing TPMs so hard with W11 /s

That's not a bug, but rather an intentional feature.

its some kind of sick joke that the bug is in their implementation of TPM which was made to increase security. sometimes complexity itself is the weakness in security, but i guess thats another (less talked about imo) part of the human weakness in security,

3:22 the "Lake" is part of the codenames for many Intel CPUs. The oldest name I see in that list is Kaby Lake, which is 7th gen

three letter agencies calls it a feature

I find it kind of humorous that an exploit that enables ring -2 privileges is treated as serious but Intel ME and AMD PSP is fine according to manufacturers.

This is bad, but I still think Intel Management Engine is worse.

I've often wondered about the exposure to UEFI bugs after support ends. (same story for CPU microcode updates, and even wireless keyboards need security updates) Realistically, support must taper off approaching the published date. After support ends, Phoenix or AMI may come up with critical fixes, but licensees (like Lenovo) will be less inclined to release updated firmware for affected older products. The bug fixes are of course rich with information to compromise older products that will never be updated. Seems like a shame to stop using perfectly functional computers.

jokes on you, I don't have TPM

How is it exploited? Do you have to run a code on local computer, or can you do it over a network? Do you need admin rights? How do you check if it affects you? Is there a way to mitigate it if an update is not available?

3:37 i can't get over that split second expression you made oh my god

I always hated the new UEFI BIOS. now I have a valid reason

It does not matter. The whole point of secure boot was not to actually secure your OS, it was to stop you from installing Linux on a Windows PC. They could not do it because of legal reasons. You need to get physical access to it do get this attack to work. It's pretty useless for a hacker who does not want to break into people's houses to get their computer and then steal their data.

TPM was made by Microsoft and made it mandatory for windows 11 as a security measure. That just sounds like one another intentional backdoor by MS and NSA again

At this point I might as well just make my own CPU and MB! Fuck it....

"Secure Boot" being insecure is just too funny

There's this logo which showed on pretty every mobo until recent years, I found out that most of bioses were made by the same company, manufactures just made graphical choices for their brand - why would you code something that low level, with all the catches and problems, use someones better work...but then, you got single point of failure lol

Removing the 'T' from 'TPM'

"911 what's your emergency" "My computer ain't computering"

The idea that a vulnerability in UEFI wouldn't be 90% a backdoor is unthinkable to me

Title is very clickbait, especially given that firmware can be updated and AMD does have a marketshare.

More I see... More I assume that the safest online experience, is never going online at all xD

I understand that KZfaq changed its monetization rules. But, at best (or worst) it’s a phoenix related bug (that might affect you or not)… and it lasts as long as you don’t update your firmware, which nowadays is a peace of cake (compared with what it was prior UEFI). So, yeah, next.

wake up babe new vulnerability xd

That's super neat. Thanks for a good upload, man!

Coreboot and Libreboot need more devs!

The instruction set for the processor and supporting UC's are hard coded. They depend on the boot programming to configure and run the OS. In theory the chips could be compromised and you would never know until a specific call is made by the OS. So it doesn't surprise me that the BIOS or UEFI has been exploited.

Oh, I don't even have TPM lmao And I have an AMD processor And I have an AMI BIOS

Isn't this kind the point of Coreboot/Libreboot to avoid vendor abandonment of UEFI updates and to give open source scrutiny to the boot process (binary blob aside)? Also would be interested in your opinion of the root of trust silicon opentitan earl grey chip. Seems like an interesting topic for the channel.

Wait until you hear about the devices connected directly to your memory that also has firmware you can't inspect (HDDs, nvme drives, network cards, etc)

Love when multiple once-in-a-lifetime exploits are found in the same year

Ok i guess i'll go work with agriculture then, gonna get me a few oxes, horses and ploughs and we're done with computers

Your cpu has a log of every pornographic website you have ever seen.

Went the AMD way with my new build a month ago for the first time in 20 years - that decision seems better every day.

this is easily the best cyber security podcast / channel i've seen and i have very high expectations as someone who takes this job very seriously and wants to learn as much about hacking / offsec as possible. No nonsense just straight facts and interesting information presented in a well understandable manner. Great work.

You only mentioned Intel-CPUs. Are AMD-CPUs also affected?

as someone currently working at a major computer part manufacturer Fuck

oh look they found the goverment backdoor

Yes. Super Low Level 1. UEFI is an Operating System, Minix, an assembly language version of Unix. UEFI has its own network stack, communicating without your knowledge. (SeaBIOS). 2. TPM (Hardware Hash Storage and Verification module), DOES NOT verify all of the code, ex. BIOS hash is not stored on the TPM by design. Any code not verified by the TPM could be modified by an attacker, and the system will not alert you to the change.

Uhhm, time to check the status of CoreBoot again

Thank you very much. Very informative.

System76 uses coreboot ...but not only that...they provide the code for the E.C. microcontroller in case even that needs an update...it would be great if you can interview their engineers

1:55 UEFI is not a new version of BIOS, it's entirely unrelated and comes from the EFI firmware used to boot Itanium-systems

Love your videos, keep it up! I've learned lots

does an attacker need physical access to the pc ?

My approach: Security by Legacy 🤪

Couldn't this be dealt with simply by re-flashing the UEFI? BIOS malware before was relatively easy to just flash over. I mean of course to remove the hacker's access. Not to remove the vulnerability itself.

NSA defeated again

thats it, im switching to papyrus.

Every time I watch a video on this channel I am exponentially more paranoid for like 2 days 😂

Not a bug but a backdoor

Incredible video as always

"As far back as 12th gen" Oh good, my my 1st gen Thinkpad is fine.

So AMD platforms not affected?

Running an I7-4790 here from 2014. It's a Dell 9020 machine and the last generation that would let you run in legacy mode. (Bios). So my Linux runs without UEFI.

time to move to a shack in the middle of nowhere with no internet connection

You don't need runtime checks to zero-out cursor offset, goddamit. Open source and let users to compile it so they could fix those issues or expect people would be angry at you because you're the only actor who knows how to fix this.

0:26 totally wrong. It can be restored. UEFI flash back, which most motherboards have.

Dude great video as always ,i would like to share a tip:it would be alot better if you would have mentioned that the getvariable function according to the UEFI specification would update datasize to the size of the variable. Assume that the viewer is unaware about such seemingly well defined functions. I personally was confused at first as i didn't consider the possibility of getvariable being a part of the standard specification.

I love the "but what about Rust" part

BIOS code injection has been around forever. And it doesnt give the hacker access forever, simply updating bios or if you have flashback run that.

0:35 its not forever, I can rewrite the nvflash

It's frightening to think how pervasive and deeply rooted such vulnerabilities can be, especially in an area as key to our digital infrastructure as UEFI firmware.

I was thinking about this the other day.... eerie

There are rings below 0?

Is this vulnerability similar to the LogoFAIL one?

Thanks hardware makers!

Please do content on the Blacklotus Bootkit. Sounds fascinating.

Who would've thought, shocker

Microsoft: you need tpm for security. tpm:

Man I love unsafe code!

Oh wow, this made me want to see another Tavis Ormandy cooks...

How many of these "vulnerabilities" are just built in back doors that are found by regular people?

UEFI applications written in Rust using the UEFI crate are definitely bounds-checked at compile time as I've witnessed firsthand attempting to use it that way. As for the firmware itself, that remains to be seen; in assembly, it's definitely easy to go wrong.

"lasts forever" but you can update the mobo

but how the bug can be exploited? like is that bad that downloading pirate software, a virus can get in my UEFI with the highest privileges? or is like the NSA have to install a chip in your PC to exploit it?

black lotus has actually been open sources a while ago.

Thanks for reminding me, I had totally forgot to update my BIOS and ME, did it now. Even though it's safer these days to update your BIOS (with the ability to roll back and such) versus the old days, it still made me panicky. So I sat like 0_0 until everything completed xD

Most modern motherboards have UEFI flash update that's basically plug and play (install) Also AMD (with its AMI bios) is completely unaffected by this

oh wow TPM has a backdoor? That's the entire purpose of TPM. It literally serves up your drive encryption keys plaintext.

you can go even lower than that, at the power supply level, now thats low level