@@rocktheworld2k6 my desktop is a 4790k overclocked to 4 6ghz, it is still running strong. Even the EVGA NVIDIA 960 SCC 4GB card is going strong too. Though they are starting to show their age with all the new stuff like raytracing. I moved on to using a laptop because I need to stay mobile, but my little brothers like it and dont need all that much performance for terraria and idle games and browser. also, Elden ring runs just fine on it too.
@@tangentfox4677 TPM itself is the backdoor. Sure, this "bug" is not intended function... but that is more besides the point. Ever since the "debate" on backdoors and "Law Enforcement" having "golden keys" this problem has always existed. How do you create a backdoor that only the good guys can use? Well... you can't. TPM is "literally" in every sense of the idea a "backdoor" to systems. Their entire purpose is to determine if code is "authorized" to run on a system. The bug here is that "unauthorized" code is allowed to run fulfilling the prophecy that once you make a backdoor the bad guys will find a way to get the golden keys... regardless of how they gained them.
@videocommenter235 TPM was designed to be a hardware encryption key generator to make truly random keys along with other things. They found that some TPM versions make weak keys a while back, making it pointless. Also modern x86 CPUs have true random number generators used as seeds to pseudo random generators to give truly random keys anyway. Arguably software solutions have been more secure than TPM for a while, as in over a decade.
It means taking a SIMPLE codebase for posting a PC and complicating the hell out of it doesn't make things more secure. It just pisses Linux users off.
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.
Gonna need a hypervisor virtualizer layer...or rather, another one. I called this garbage over a decade ago. Virtualization is cute for running VMs, but you don't really need VMs except for OS development and such. You need a secure OS and an isolatable user code target platform. But no, we can't be bothered to make our application instances isolated in the raw, that might require fixing your buggy AF OS or app target platform. So we'll sandbox everything, and pretty soon you have a stack of sandboxes. And security problems. Virtualization is not a security solution.
I always wondered how enabling UEFI updates from Windows can be safe. I would prefer a physical DIP switch or a hidden button to enable firmware updates. macOS updates seem to be able to update the UEFI as well. Even CPU microcode can be updated without any physical barriers. Maybe only a major attack on financial infrastructure will lead to physical switches becoming reinstated.
That would be a great solution for write protection. Add a notification window to the update process if the jumper isn't set correctly for an update. This only opens the window for malicious "patches" coming from "somewhere" other than the manufacturer that somehow got trusted by the end user to manually update. And then this will be a problem.
@@ChristianWagner888 A lot of the financial structure (banks) run COBOL. I know I feel safer knowing an essentially dead programming language holds our world together. But don't worry, the bank failures won't be code but once again, user errors.
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.
A paradigm shift is needed, maybe we should go back to Fortran arrays that do bounds checking on hardware, no matter the cost to performance. We keep making the wrong engineering trade-offs. Why are we trading security for performance on critical software. Maybe having pointers and the entirety of the C language was a mistake.
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?
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).
EDK2 is BSD-license thus FOSS, right ? The real problem is probably: money ? Doing firmware updates on old PCs needs additional testing, probably on real hardware, different revisions, etc.
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.
Struggling to follow this logic. If you are able to exploit the bootstrapping elements of a system (period) then you can compromise a system in perpetuity. It doesn't really matter if it is EFI or not at that point. Or are you confident enough to say that if EFI was not adopted, we would all be living in an exploit-free world using standard BIOS?
@@jorper2526 EFI code is always obfuscated and allows for far too large of a bootROM and allows for updating the Firmware outside of Real-Mode, which should never have been allowed without some sort of way to physically lock the ability to write to the Firmware Chip from a hardware level because it makes exploits exponentially more dangerous and allows manufacturers to hide backdoors into products in exchange for what is zero user-benefit for 99.9% of users.
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,
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.
I doubt it would have been NSA either. UEFI bugs are too dangerous. That's just irresponsible. They would use safer ways to attack systems at this level that don't depend on deliberately planting software glitches accessible from user-land that could easily turn into RCE by accident.
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.
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
my guess is a malformed tpm config could do it, so malware drops a bootkit installer in the guise of a uefi update and bam next reboot, update -> exploit i may have gotten some of this wrong but generalise it and correct me where I'm wrong and i believe that's roughly how it would be done
@@mb00001 He can't just drop a bootkit installer because Secure Boot would prevent that from running if it doesnt have a trusted signature and if he could then there would be no point in exploiting this vulnerability because the attacker is already running code
Practical guaranteed removal would require reprogramming the flash chip with an external hardware programmer (and soic clip, or even chip-off programming depending on flash chip type). i.e. impossible for 99.99% of end users.
@@CD-vb9fi That sounds a bit conspiratorial, a TPM is a simple device used to store encryption keys for drives without the user knowing them. The reason that TPMS are disliked is that companies like Microsoft are starting to require their presence and also force their use, even when people don't want to use them.
@@draconic5129 I work in IT and is do actual Certificate management. Do you understand how much power a Certificate has over your system? If I can get a compromised Certificate from Microsoft I can sign code and run it on your device... and guess what will not stop that? The Comodo Compromised proved 2 big things. #1. Commercial CA's can't be taken seriously. The compromised Cert was not handled timely and Comodo just keep signing certs with it anyways... even though they knew. #2. The ecoSystem for PKI/Encryption/Trust is not robust enough or rather... NOT "under their control enough". But the robust part is still true and a great excuse to convince people like you that don't understand how this works. Introducing TPM... a little black box you don't control but the Vendors do control. Sure... they will let you clear the store and manage it somewhate via BIOS and a few other tools. This really does not even scratch the surface. All of this still technically runs on software. Just software on "dedicated or specialized hardware" that can be hacked and compromised just as easy as anything else. Except one thing. It's gets harder and harder for Joe average to do anything about it for themselves... and that is the whole point. They don't care you have been compromised... they care that they can't be the ones taking advantage of you being compromised!
@@draconic5129 YT is blocking my responses again. No, it's more than that. If I get a compromised Cert and use it to sign code your TPM will trust it rendering it useless... 100% useless. This is a way for companies to make money by requiring them to pay for signatures... and the cost of your technology goes up because of it. It makes them money, gives them more control over your system, and you pay for them to compromise you.
@@draconic5129 I still wont trust TPM or any other chip claiming to securely hold my encryption keys for me. I wont be surprised if they have backdoors. Not necessarily by the US, but by the manufacturer.
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.
It's pretty obvious that the UEFI manufacturers / dev team / govt have made these exploits very possible. Sadly most computer users are dumb enough to not even be able to comprehend the severity of this issue, lacking fundamental knowledge in computers in general. #supportopensourcesoftware
@@lorantpal6616 I could also say that most car drivers are stupid enough to accept timing belts in the place of timing chains in spite of their obvious disadvantages (advantages for the manufacturer because maintenance money), but I realise that most people know next to nothing about the internal workings of their cars. What I am trying to say is that the mere fact that someone doesn't understand the dangers inherent to a particular technology does not make them "dumb", just ignorant. Anyway, I agree with your overall sentiment.
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.
I understand that UA-cam 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.
Forgot Osboot, the more secure of the 3... blobs all round, now the excitement is that Spectre and Meltdown are hardware vulnerabilities affecting modern CPUs. Spectre allows malicious code to read sensitive data from other processes. Meltdown allows unauthorized access to kernel memory. Both vulnerabilities require microcode updates to mitigate, Coreboot and Osboot accept these updates, but Libreboot does not, leaving systems vulnerable.
Yes, and there are some excellent videos on how to make home made vacuum tubes so that you can avoid any sneaky addons to things like voltage regulators. 😮 Crazy thing is that vacuum tubes are still superior over semiconductors for certain tasks. Please don't put your fingers near vacuum tube circuits, they run at 300-3000 Volts.
@@CrispyCircuits Indeed. Not sure if a magnetron counts as a vacuum tube but microwave ovens would be the most common use of this old technology. It's far more robust for any high power radio frequency stuff than semiconductors.
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
This is a good solution actually. But I checked their website, and the computers they make are rather expensive. It'd possibly be better to just get a regular PC(AMD instead of Intel too), and put coreboot on it, along with a good Linux distro. For most people this is not an easily accomplished task, while System76 computers are much more expensive for them, instead of something like a ThinkPad for $300. Best bet would be to have a company that offers the critical insight needed for these users to understand the importance of these low-level issues, and this company could provide devs, who would - affordably - offer to replace the users' UEFI with coreboot. On the long run, the business might prove surprisingly successful, if they manage to spread enough awareness to get to regular end-users and even companies, who would be more than happy to deploy these devs to replace their UEFIs.
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
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?
As always; someone has to have full control. As bad as this is, a lot of vulnerabilities (especially at this level) are theoreticals that require an attacker to already have full control of your system. At that point, a lot of damage is already done.
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've been aboard AMD for about 20 years, now. If nothing else, the smaller market share means less investment in attacking, but I generally believe they make better stuff from a hardware engineering standpoint. They were less affected by spectre and meltdown, as well, just because of how they handle speculative execution. Though I am curious if their chipsets will evolve away from arm to a RISC-V deployment - and if they will ultimately end up using risc-v's vector processing and virtualize avx 512/legacy over them. Though that would be an architecture or two in the future.
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
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.
@@mystica-subs UEFI does utilize a tiny operating system. IME, developed by Intel, runs Unix. UEFI, developed by Intel, runs ? Is it difficult to assume code is reused, the UEFI might be using a Unix kernel as well?
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.
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.
"Local hacker" makes this a sorta moot thing. Simply because if the hacker can touch the machine, all bets are off. If this was somehow remote executable I would be worried.
not really, you can create a personal boot stick with password that decrypts the internal disk. If you go away from the house and turn off the computer(and the power, and discharge capacitors, just to be safe) and bring your usb authority key with you there is nothing a hacker could do with local access other than compromise your BIOS to hijack the key ofcourse. Perhaps a solution would be where the authority boot key to hash verify the BIOS before doing anything.
@@ChrisWijtmans they could also plug in a device...you got PCIe slots and USB headers right? You could still get autopwned on next login if you don't check these things after an attacker gained physical access to your logged out encrypted PC.
@@TheRealEtaoinShrdlu What bugs me the most is about social media, the feeling of "hey these platforms they know me!" wheter i'm logged on fb or instagram? The algorythm knows it's me! Here on yt I can get a lot of content! other networks? is like always being ''stuck'' on the experience they ''tailored'' for user y... Untill the user starts breaking his own bubble and pushing for the ''meta game'' of the platform because gamefied networks are also a thing, infinite paradoxes rofl
@@EasyMoney322 so i replied that i got code from biggest open source code hosting website (now owned by Microsoft) and got a warning about hate speech. YT going down to forum filters territory.
Compared to your other videos, this one appears all over the place. Example - 1. "The vulnerability is very simple." That preps my brain to see what it is. But we go down immediately instead of discussing the vulnerability, what is static analysis and dynamic analysis - which my brain is not looking for at the moment (especially since I can sort of guess what is automated binary analysis and am less interested to know about it than the vulnerability itself). 2. "Now you may be asking whether rust would have helped." No. I mean that is a valid question I suppose, but way down the list of questions I'd ask.The first thing I'd like to know is if and how someone can target my PC. Can they do it remotely? Can they do it if they have access to my OS? Do they need root access? Or do they need to install an UEFI bootloader for this? Etc. Before even asking if rust would help, I'd like to know whether the UEFI code is being fixed for new computers. Can it be changed to other languages? And maybe if they are planning to replace c++ (or c, whatever they currently use), with rust. Then what are the pros and cons, including, only at this point, if rust would help given that it protects from these things.
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.
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.
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.
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
UEFI is easy to hack. I have bypassed most security features with relative ease in my quest for more control over exactly what my hardware is doing and for the ability to run UEFI images with my own drivers and features. One such feature is control over gpu voltages in older nvidia rtx laptops
I have a laptop where IME for some reason will fail. Some i*i*t decided that in that case the machine shall run for exactly 30 minutes before a timer shuts it down. Through some random sequence of reboots and resets I can get lucky and make it boot in a working state (me recovery state), but otherwise the machine is useless. (Thinkpad T520.)
Having bios/uefi backups/secondarys in motherboards needs to become more standard so everyone can safely just update it when stuff like this happens. I always keep mine up to date but one of my motherboards did get bricked a few years ago because of a power outage and that board didn't have a backup system for it which sucked, it's fixable but I would have to get a new chip for it and solder it on.
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.
"You need to get physical access to it do get this attack to work." Thanks, I was sitting here scratching my head wondering how someone would get remote access for a firmware update. I know is possible to do it remotely, but I believe it still has to be initiated from the target machine on boot.
"You need to get physical access to it do get this attack to work." - absolutely untrue. Just think for a second. If Windows Update or a ring3/user level "BIOS update utility" can successfully write to lower levels of a computer, a hacker won't be able to? I have several computers, phones and even a router that prove this otherwise, sadly - since 2023 may too. RCE, microcode vulns and privesc are all doable remotely, with a bootkit that starts on ring3 and works its way down to the UEFI level. We need to support and use open-source firmware for this to not be possible, for ex.: coreboot, libreboot, etc.
Been working at kernel level and UEFI level for a while now in order to create cheats for videogames which require at least kernel level but ofc most people go full on UEFI cuz it's way more difficult to detect, i reversed part of my UEFI firmware and i know people who did that too and they found a shit ton of vulnerabilities, last time i was looking at an SMM backdoor that allowed people to execute arbitrary code from USERMODE at ring -2 pretty scary tbh. I wish there were more people able to write/read UEFI code because if the kernel allows you to use a lot of functionalities regarding the pc UEFi allows you to use every functionality of your pc, pretty much freedom as long as you are able to code UEFI firmwares.
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.
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?
It can be easily exploited on MSI motherboard that do live-updating of the firmware from inside the system. I bet other manufacturers can also do that, which is ridiculous. Its so ridiculous that I literally cut the trace from the write pin going to my Winbond flash that stores the NVRAM, so its impossible for the system to be corrupted, also impossible to update the bios without external flashing it.
@@monad_tcpI agree with not allowing UEFI update capsules to initiate from the kernel but in regards to this exploit, did MSI even use Pheonix on a relatively modern consumer board? Everything I've seen has been AMI for a long time. I assume it's mostly OEMs.
I know of 3 companies that make and sell UEFI firmware: AMI, Phoenix Technologies and Insyde software. The InsydeH2O seems to be somewhat common on laptops, AMI is pretty ubiquitous in the retail motherboard scene, unsure where Phoenix seems to be also in many laptops.
It doesn't make much sense to have a backdoor that relies on a vulnerability with how keys are verified. Just use an obfuscated master key baked into a ROM within your NVRAM or something.
I had an ASUS F2A85-M with Coreboot back when socket FM2 and Athlon was "modern".. I think it has merit to look if UEFI was really the right way, especially when you realize that ALL computers have a management console running on their PCs. At all times. Even when the PC is "off". Without their knowledge. At Ring -1 level.
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)
For context, early 2016 the US government was heavily stressing a need to access personal encrypted devices. a year later (2017) KabyLake (the earliest intel code name mentioned) has this uefi vulnerability? Probably coincidence.
Ed from the Ol' Learning channel discusses a serious bug in UEFI, the code that turns on computers, which can give hackers permanent access regardless of OS or CPU changes. The vulnerability, named UEFI Can Has Buffer Overflow, was discovered by the security research firm Eclips. This issue affects UEFI firmware, which is difficult to write and only provided by a few companies, making it a supply chain vulnerability. The flaw, found in Phoenix Technologies' secure code firmware, allows local attackers to escalate privileges and gain code execution within the UEFI firmware during runtime. The speaker suggests upgrading the UEFI firmware as a mitigation but notes the difficulty and potential risks involved. The video also highlights the broader implications of bugs at low levels in the software ecosystem. The vulnerability was discovered using automated binary analysis and stems from a buffer overflow in a variable called tcg2, where the firmware attempts to read the variable but the data size is not checked properly.
Kind of. Negative rings aren't really implemented as separate protection levels (like rings 0-3 are), but rather are just colloquial terms for different states/configurations of the system. For example, the Hypervisor is technically also running in ring 0, but it can emulate stuff for the virtualized OS/kernel by using vmenter/vmexit, so it is oftern called "ring -1". Ring -2 is System Management Mode and ring -3 is the Management Engine (which is a completely separate processor installed on the Motherboard that can temporarily "pause" your primary CPU and do whatever it wants, so ring -3 code isn't even running on the primary CPU). So yeah, the negative rings are actually closer to "weird stuff that your computer can do" rather than conventional protection rings on the CPU.
@@blackmagicprod7039 after losing a computer to a brick attack on my bios via the internet I tend to disagree the same attacker disabled the HDMI Port on my laptop. It took me 10 years to find out who and why.
@@LowLevelTV yep, I'm going to pay special attention on any motherboard that I buy to have external NVRAM so I can flash it, because some motherboards include it on the chipset, that's way harder to flash if they burned the fuses (you have to drill the chip or somethign)
wanna learn how computers work? learn to code at lowlevel.academy
ok
@@LowLevelTV ok
@@LowLevelTV why tf is this dudes voice so annoying?? I can't figure out if it's also the punchable face helping too 😂 😂
@@EStartive ok
@@LowLevelTV yes
Ok i guess i will just carve a new rock myself and hope no one will hack it
rocks get hacked too D:
@@LowLevelTV Just get a hammer and a nail and you can break the rock
You can do that to a computer as well@@mastercrossing
@@mastercrossingAnd that is called "Penetration Testing"
You forgot about the malware/backdoor in your brain that secretly adds a backdoor in everything you create. 😂😅
Jokes on you my motherboard is so old it predates this problem
Same here. I have a SkyLake processor.
*laughs in Haswell 4790k*
For a moment there i though this was a self burn lol
@@rocktheworld2k6 my desktop is a 4790k overclocked to 4 6ghz, it is still running strong. Even the EVGA NVIDIA 960 SCC 4GB card is going strong too. Though they are starting to show their age with all the new stuff like raytracing. I moved on to using a laptop because I need to stay mobile, but my little brothers like it and dont need all that much performance for terraria and idle games and browser. also, Elden ring runs just fine on it too.
Jokes on you, I'm running a Kenbak-1
TempleOS affected :(
Sadge
Time for HolyRust
@@j_stachI am on-board
No. TempleOS specifically has no networking capabilities so that God's temple remains sealed from the heathens outside.
@@j_stach More like EvilRust.
As soon as TPM was mentioned, I knew this was not a bug or mistake. This is a backdoor.
The whole point of TPM is to create a backdoor into your system so it can be compromised without you even being able to find out.
@@CD-vb9fi Stop spamming in every thread. You don't even know what tpm is, and walk spreading bullshit
@@CD-vb9fiI mean yes, but this looks like a bug in that system rather than the intended backdoor. Or maybe it's an exploit in the backdoor?
@@tangentfox4677 TPM itself is the backdoor. Sure, this "bug" is not intended function... but that is more besides the point.
Ever since the "debate" on backdoors and "Law Enforcement" having "golden keys" this problem has always existed. How do you create a backdoor that only the good guys can use?
Well... you can't. TPM is "literally" in every sense of the idea a "backdoor" to systems.
Their entire purpose is to determine if code is "authorized" to run on a system. The bug here is that "unauthorized" code is allowed to run fulfilling the prophecy that once you make a backdoor the bad guys will find a way to get the golden keys... regardless of how they gained them.
@videocommenter235 TPM was designed to be a hardware encryption key generator to make truly random keys along with other things.
They found that some TPM versions make weak keys a while back, making it pointless.
Also modern x86 CPUs have true random number generators used as seeds to pseudo random generators to give truly random keys anyway. Arguably software solutions have been more secure than TPM for a while, as in over a decade.
> 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?
@@TheLinuxGallery-qz2vs this isn't /g/
It's the latest feature brought to us by the NSA
bingo
It means taking a SIMPLE codebase for posting a PC and complicating the hell out of it doesn't make things more secure. It just pisses Linux users off.
/gay/
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.
Gonna need a hypervisor virtualizer layer...or rather, another one.
I called this garbage over a decade ago. Virtualization is cute for running VMs, but you don't really need VMs except for OS development and such. You need a secure OS and an isolatable user code target platform. But no, we can't be bothered to make our application instances isolated in the raw, that might require fixing your buggy AF OS or app target platform. So we'll sandbox everything, and pretty soon you have a stack of sandboxes. And security problems. Virtualization is not a security solution.
@@udasai i bet there are backdoors in VMs to escape the VM anyway, a lot of cpu backdoords transcend VMs anyway.
I always wondered how enabling UEFI updates from Windows can be safe. I would prefer a physical DIP switch or a hidden button to enable firmware updates. macOS updates seem to be able to update the UEFI as well. Even CPU microcode can be updated without any physical barriers. Maybe only a major attack on financial infrastructure will lead to physical switches becoming reinstated.
That would be a great solution for write protection. Add a notification window to the update process if the jumper isn't set correctly for an update. This only opens the window for malicious "patches" coming from "somewhere" other than the manufacturer that somehow got trusted by the end user to manually update. And then this will be a problem.
@@ChristianWagner888 A lot of the financial structure (banks) run COBOL. I know I feel safer knowing an essentially dead programming language holds our world together.
But don't worry, the bank failures won't be code but once again, user errors.
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.
A paradigm shift is needed, maybe we should go back to Fortran arrays that do bounds checking on hardware, no matter the cost to performance.
We keep making the wrong engineering trade-offs. Why are we trading security for performance on critical software.
Maybe having pointers and the entirety of the C language was a mistake.
Cool to see the older generation online!
@@RedstoneMiner18 they invented it...
@@UncleJazzboTheThird some of them, the rest are morons that dont wanna learn how to input a password
@@UncleJazzboTheThird Scrolling through Facebook might make you forget that though
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?
@@Aim54Delta total coincidence
When the title said the vulnerability lasts forever i thought you meant it was a hardware bug. Got me scared for a sec.
JUST WAIT UNTIL THIS WEEKEND
@@LowLevelTV oh no
@@LowLevelTV oh no
@@LowLevelTVoh no.
@@LowLevelTV fuck fuck fuck fuck. nonononono
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).
...oh. My motherboard uses Insyde, should I be worried?
Excellent comment!
Yeah, that TPM wipe isn't gonna happen by a vendor update, FAR to many complaints if they do that one.
EDK2 is BSD-license thus FOSS, right ?
The real problem is probably: money ?
Doing firmware updates on old PCs needs additional testing, probably on real hardware, different revisions, etc.
thats why i buy motherboard with open-source in mind , porting to coreboot has become lot easier nowdays
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.
Struggling to follow this logic. If you are able to exploit the bootstrapping elements of a system (period) then you can compromise a system in perpetuity. It doesn't really matter if it is EFI or not at that point. Or are you confident enough to say that if EFI was not adopted, we would all be living in an exploit-free world using standard BIOS?
I wonder why the EDK2 code base uses it's own custom rolled configuration file syntax.
@@jorper2526 EFI code is always obfuscated and allows for far too large of a bootROM and allows for updating the Firmware outside of Real-Mode, which should never have been allowed without some sort of way to physically lock the ability to write to the Firmware Chip from a hardware level because it makes exploits exponentially more dangerous and allows manufacturers to hide backdoors into products in exchange for what is zero user-benefit for 99.9% of users.
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,
CIA glowies feature
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.
Feature not a bug. Say hello to NSA.
Yeah I was going to say, this sounds like a specification that was paid for rather than a bug
I doubt it would have been NSA either. UEFI bugs are too dangerous. That's just irresponsible. They would use safer ways to attack systems at this level that don't depend on deliberately planting software glitches accessible from user-land that could easily turn into RCE by accident.
@@Ormaaj can you please explain what you mean?
Either untested code or done on purpose. Given that Microsoft required TPM for Windows 11 makes me think it was done on purpose.
Not really, there's a complete IP stack in the tpm for this exact purpose. Or something else.
"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.
we gottem
They mostly supply canned systems these days.
Coreboot
@@Tim_Small how's your thinkpad from 2010 doing?
my PC has the gigabyte mz32-ar0 motherboard, so also AMI firmware.
3:37 i can't get over that split second expression you made oh my god
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.
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
The bug can't even be exploit if the attacker doesn't already have code execution before
my guess is a malformed tpm config could do it, so malware drops a bootkit installer in the guise of a uefi update and bam next reboot, update -> exploit
i may have gotten some of this wrong but generalise it and correct me where I'm wrong and i believe that's roughly how it would be done
@@mb00001 He can't just drop a bootkit installer because Secure Boot would prevent that from running if it doesnt have a trusted signature and if he could then there would be no point in exploiting this vulnerability because the attacker is already running code
Practical guaranteed removal would require reprogramming the flash chip with an external hardware programmer (and soic clip, or even chip-off programming depending on flash chip type). i.e. impossible for 99.99% of end users.
@@Tim_Small Or just unsolder and solder on a new chip.
Never trusted TPM.
Yea, I disable TPM on all my builds. I would not be shocked to find out it still phoning home even while "disabled".
@@CD-vb9fi That sounds a bit conspiratorial, a TPM is a simple device used to store encryption keys for drives without the user knowing them. The reason that TPMS are disliked is that companies like Microsoft are starting to require their presence and also force their use, even when people don't want to use them.
@@draconic5129 I work in IT and is do actual Certificate management. Do you understand how much power a Certificate has over your system?
If I can get a compromised Certificate from Microsoft I can sign code and run it on your device... and guess what will not stop that?
The Comodo Compromised proved 2 big things. #1. Commercial CA's can't be taken seriously. The compromised Cert was not handled timely and Comodo just keep signing certs with it anyways... even though they knew.
#2. The ecoSystem for PKI/Encryption/Trust is not robust enough or rather... NOT "under their control enough". But the robust part is still true and a great excuse to convince people like you that don't understand how this works.
Introducing TPM... a little black box you don't control but the Vendors do control. Sure... they will let you clear the store and manage it somewhate via BIOS and a few other tools.
This really does not even scratch the surface. All of this still technically runs on software. Just software on "dedicated or specialized hardware" that can be hacked and compromised just as easy as anything else.
Except one thing. It's gets harder and harder for Joe average to do anything about it for themselves... and that is the whole point.
They don't care you have been compromised... they care that they can't be the ones taking advantage of you being compromised!
@@draconic5129 YT is blocking my responses again. No, it's more than that. If I get a compromised Cert and use it to sign code your TPM will trust it rendering it useless... 100% useless. This is a way for companies to make money by requiring them to pay for signatures... and the cost of your technology goes up because of it. It makes them money, gives them more control over your system, and you pay for them to compromise you.
@@draconic5129 I still wont trust TPM or any other chip claiming to securely hold my encryption keys for me. I wont be surprised if they have backdoors. Not necessarily by the US, but by the manufacturer.
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.
Literally comment under yours that answers it all. Backdoor. Code so stupid that you might believe it was there unintentionally.
It's "wild" to you?. Edward Snowden says hello... .
It's pretty obvious that the UEFI manufacturers / dev team / govt have made these exploits very possible. Sadly most computer users are dumb enough to not even be able to comprehend the severity of this issue, lacking fundamental knowledge in computers in general. #supportopensourcesoftware
@@lorantpal6616 I could also say that most car drivers are stupid enough to accept timing belts in the place of timing chains in spite of their obvious disadvantages (advantages for the manufacturer because maintenance money), but I realise that most people know next to nothing about the internal workings of their cars. What I am trying to say is that the mere fact that someone doesn't understand the dangers inherent to a particular technology does not make them "dumb", just ignorant.
Anyway, I agree with your overall sentiment.
0:02 "On your computer" *shows an image of my exact setup*
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
ruhroe I have that one
@@LowLevelTV Luckly I have a Haswell
Skylake is 6th gen
I guess, time to find myself a nice 4790K and ditch my 8th gen cpu?
Which is strange, because Kaby Lake is unsupported by Windows 11.
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.
I understand that UA-cam 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.
Title is very clickbait, especially given that firmware can be updated and AMD does have a marketshare.
manufacturers abandon old products, and the vulnerability remains
@@TheAceTroubleshooterUpdate the UEFI firmware? Yes, if an update exists it's not difficult at all.
Bait use to be believable (you not the title since you have issues comprehending).
@@Pewafamath no uw
Not to mention, this only affects Phoenix Technologies boards, which are pretty rare to begin with. AMI has the lion's share of the Intel market.
Coreboot and Libreboot need more devs!
Forgot Osboot, the more secure of the 3... blobs all round, now the excitement is that Spectre and Meltdown are hardware vulnerabilities affecting modern CPUs.
Spectre allows malicious code to read sensitive data from other processes. Meltdown allows unauthorized access to kernel memory.
Both vulnerabilities require microcode updates to mitigate, Coreboot and Osboot accept these updates, but Libreboot does not, leaving systems vulnerable.
At this point I might as well just make my own CPU and MB! Fuck it....
Yes, and there are some excellent videos on how to make home made vacuum tubes so that you can avoid any sneaky addons to things like voltage regulators. 😮
Crazy thing is that vacuum tubes are still superior over semiconductors for certain tasks. Please don't put your fingers near vacuum tube circuits, they run at 300-3000 Volts.
@@CrispyCircuits Indeed. Not sure if a magnetron counts as a vacuum tube but microwave ovens would be the most common use of this old technology. It's far more robust for any high power radio frequency stuff than semiconductors.
@@brandyballoon more of a Magnemite guy myself personally
That's not a bug, but rather an intentional feature.
its a good feature, now we can own back our hardware
@@monad_tcp indeed it is, I guess
this
Thank you for your opinion, Mr Snowden. Now please shut up.
Love when multiple once-in-a-lifetime exploits are found in the same year
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
This is a good solution actually. But I checked their website, and the computers they make are rather expensive. It'd possibly be better to just get a regular PC(AMD instead of Intel too), and put coreboot on it, along with a good Linux distro. For most people this is not an easily accomplished task, while System76 computers are much more expensive for them, instead of something like a ThinkPad for $300. Best bet would be to have a company that offers the critical insight needed for these users to understand the importance of these low-level issues, and this company could provide devs, who would - affordably - offer to replace the users' UEFI with coreboot. On the long run, the business might prove surprisingly successful, if they manage to spread enough awareness to get to regular end-users and even companies, who would be more than happy to deploy these devs to replace their UEFIs.
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
American Megatrends? I remember even some expensive gaming mobos years ago would sometimes not even bother to remove their logo
@@JohnDoeWasntTakenmaybe it's cheaper to have their logo on boot
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?
I really want to know the same, I am honestly afraid right now.
you need local access to the machine
As always; someone has to have full control.
As bad as this is, a lot of vulnerabilities (especially at this level) are theoreticals that require an attacker to already have full control of your system.
At that point, a lot of damage is already done.
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.
That's super neat. Thanks for a good upload, man!
"911 what's your emergency"
"My computer ain't computering"
Went the AMD way with my new build a month ago for the first time in 20 years - that decision seems better every day.
wym?
I've been aboard AMD for about 20 years, now. If nothing else, the smaller market share means less investment in attacking, but I generally believe they make better stuff from a hardware engineering standpoint. They were less affected by spectre and meltdown, as well, just because of how they handle speculative execution.
Though I am curious if their chipsets will evolve away from arm to a RISC-V deployment - and if they will ultimately end up using risc-v's vector processing and virtualize avx 512/legacy over them. Though that would be an architecture or two in the future.
Could interest you in a wonderful wikipedia article: AMD PSP
"A hardware rootkit in every motherboard chipset since 2013."
@@c2n10 Intel management engine, it's not any different.
@@c2n10so NSA compromised all commercial CPUs. Well no surprise here... .
The idea that a vulnerability in UEFI wouldn't be 90% a backdoor is unthinkable to me
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
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.
I think you have the Intel ME running minix confused with UEFI code which can be whatever the hell it wants. Look at the Tianocore source yourself.
@@mystica-subs UEFI does utilize a tiny operating system.
IME, developed by Intel, runs Unix.
UEFI, developed by Intel, runs ?
Is it difficult to assume code is reused, the UEFI might be using a Unix kernel as well?
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.
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.
No wonder Microsoft was pushing TPMs so hard with W11
/s
"Local hacker" makes this a sorta moot thing. Simply because if the hacker can touch the machine, all bets are off. If this was somehow remote executable I would be worried.
not really, you can create a personal boot stick with password that decrypts the internal disk. If you go away from the house and turn off the computer(and the power, and discharge capacitors, just to be safe) and bring your usb authority key with you there is nothing a hacker could do with local access other than compromise your BIOS to hijack the key ofcourse. Perhaps a solution would be where the authority boot key to hash verify the BIOS before doing anything.
so this cant be executed by someone else over the internet?
@@69605 not according to this. I mean, unless you are on a board with IPMI, nothing should be on to connect to anyway.
@@ChrisWijtmans they could also plug in a device...you got PCIe slots and USB headers right? You could still get autopwned on next login if you don't check these things after an attacker gained physical access to your logged out encrypted PC.
@@freedustin not really, you can defend against those things as well.
More I see... More I assume that the safest online experience, is never going online at all xD
It's also muuuuuch safer to never have sex. But being "safe" just seems pointless then...
@@TheRealEtaoinShrdlu What bugs me the most is about social media, the feeling of "hey these platforms they know me!" wheter i'm logged on fb or instagram? The algorythm knows it's me! Here on yt I can get a lot of content! other networks? is like always being ''stuck'' on the experience they ''tailored'' for user y... Untill the user starts breaking his own bubble and pushing for the ''meta game'' of the platform because gamefied networks are also a thing, infinite paradoxes rofl
use templeOS then.
Not an online vulnerability. Requires local access to exploit.
@@blackmagicprod7039 Well that's a tiny bit of good news.
jokes on you, I don't have TPM
Probably the code still exists in your BIOS... euh.. firmware. 🙂
@@autohmae Nah, it's X99 chinese board that only runs windows 10. I flashed firmware myself with clip flasher.
So you just flashed huananzhi backdoor instead?
@@EasyMoney322 no, it's the one from GitHub
@@EasyMoney322 so i replied that i got code from biggest open source code hosting website (now owned by Microsoft) and got a warning about hate speech. YT going down to forum filters territory.
Oh, I don't even have TPM lmao
And I have an AMD processor
And I have an AMI BIOS
What's an Ami bios
@@notaras1985 "American Megatrends", most of modern consumer motherboards have a modified version of AMI BIOS
I always hated the new UEFI BIOS. now I have a valid reason
three letter agencies calls it a feature
Probably adding such features for more than 15 years now... .
@@notaras1985 has been since 2008
NSAKEY says hello
this requires local access - not remote
@@borjonx well don't they love to seize people's computers whenever it's convenient
Compared to your other videos, this one appears all over the place.
Example -
1. "The vulnerability is very simple." That preps my brain to see what it is. But we go down immediately instead of discussing the vulnerability, what is static analysis and dynamic analysis - which my brain is not looking for at the moment (especially since I can sort of guess what is automated binary analysis and am less interested to know about it than the vulnerability itself).
2. "Now you may be asking whether rust would have helped." No. I mean that is a valid question I suppose, but way down the list of questions I'd ask.The first thing I'd like to know is if and how someone can target my PC. Can they do it remotely? Can they do it if they have access to my OS? Do they need root access? Or do they need to install an UEFI bootloader for this? Etc. Before even asking if rust would help, I'd like to know whether the UEFI code is being fixed for new computers. Can it be changed to other languages? And maybe if they are planning to replace c++ (or c, whatever they currently use), with rust. Then what are the pros and cons, including, only at this point, if rust would help given that it protects from these things.
Removing the 'T' from 'TPM'
military police transfer.
No need to worry, I have an old motherboard which uses bios and not uefi
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.
Certified NSA classic
Uhhm, time to check the status of CoreBoot again
Every time I watch a video on this channel I am exponentially more paranoid for like 2 days 😂
as someone currently working at a major computer part manufacturer
Fuck
Well.... fix it first, fuck later.
Throwing 5grand around like its nothing
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
He meant it replaced BIOS.
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.
Let's call it what it is: a successful NSA supply chain attack.
this requires local access - not remote
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.
oh look they found the goverment backdoor
this requires local access - not remote
You only mentioned Intel-CPUs. Are AMD-CPUs also affected?
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
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.
And how would you know you were affected or do you just, flashback for funsies.
UEFI is easy to hack. I have bypassed most security features with relative ease in my quest for more control over exactly what my hardware is doing and for the ability to run UEFI images with my own drivers and features. One such feature is control over gpu voltages in older nvidia rtx laptops
This is bad, but I still think Intel Management Engine is worse.
+1 but always also mention AMD's PSP we shouldn't give either one a pass just because one of them is seen as worse than the other
this is why we need RISC-V more than ever...
on a side note Gentoo on RISC-V (emulated) has been a great experience!
@@rusi6219 now its not just AMD PSP but Microsoft Pluton in your AM5 chip, enjoy.
I have a laptop where IME for some reason will fail. Some i*i*t decided that in that case the machine shall run for exactly 30 minutes before a timer shuts it down.
Through some random sequence of reboots and resets I can get lucky and make it boot in a working state (me recovery state), but otherwise the machine is useless. (Thinkpad T520.)
Having bios/uefi backups/secondarys in motherboards needs to become more standard so everyone can safely just update it when stuff like this happens. I always keep mine up to date but one of my motherboards did get bricked a few years ago because of a power outage and that board didn't have a backup system for it which sucked, it's fixable but I would have to get a new chip for it and solder it on.
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.
"You need to get physical access to it do get this attack to work." Thanks, I was sitting here scratching my head wondering how someone would get remote access for a firmware update. I know is possible to do it remotely, but I believe it still has to be initiated from the target machine on boot.
"You need to get physical access to it do get this attack to work." - absolutely untrue. Just think for a second. If Windows Update or a ring3/user level "BIOS update utility" can successfully write to lower levels of a computer, a hacker won't be able to? I have several computers, phones and even a router that prove this otherwise, sadly - since 2023 may too. RCE, microcode vulns and privesc are all doable remotely, with a bootkit that starts on ring3 and works its way down to the UEFI level. We need to support and use open-source firmware for this to not be possible, for ex.: coreboot, libreboot, etc.
@@lorantpal6616 The OS should not have low level write privileged to the hardware, and especially not from user mode.
I love the "but what about Rust" part
"Secure Boot" being insecure is just too funny
Been working at kernel level and UEFI level for a while now in order to create cheats for videogames which require at least kernel level but ofc most people go full on UEFI cuz it's way more difficult to detect, i reversed part of my UEFI firmware and i know people who did that too and they found a shit ton of vulnerabilities, last time i was looking at an SMM backdoor that allowed people to execute arbitrary code from USERMODE at ring -2 pretty scary tbh. I wish there were more people able to write/read UEFI code because if the kernel allows you to use a lot of functionalities regarding the pc UEFi allows you to use every functionality of your pc, pretty much freedom as long as you are able to code UEFI firmwares.
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.
I'm so glad my BIOS is open-source 😊😊😊
(I can't play video at 20fps because my CPU is from 2006)
Not a bug but a backdoor
Love your videos, keep it up! I've learned lots
Man I love unsafe code!
Please do content on the Blacklotus Bootkit. Sounds fascinating.
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?
It can be easily exploited on MSI motherboard that do live-updating of the firmware from inside the system.
I bet other manufacturers can also do that, which is ridiculous. Its so ridiculous that I literally cut the trace from the write pin going to my Winbond flash that stores the NVRAM, so its impossible for the system to be corrupted, also impossible to update the bios without external flashing it.
@@monad_tcpI agree with not allowing UEFI update capsules to initiate from the kernel but in regards to this exploit, did MSI even use Pheonix on a relatively modern consumer board? Everything I've seen has been AMI for a long time. I assume it's mostly OEMs.
I know of 3 companies that make and sell UEFI firmware: AMI, Phoenix Technologies and Insyde software. The InsydeH2O seems to be somewhat common on laptops, AMI is pretty ubiquitous in the retail motherboard scene, unsure where Phoenix seems to be also in many laptops.
Let call it a "bug" aww lel. I dont think much of them are by chance at all. And like 99.9% is pure intention and by design. Sadly.
It doesn't make much sense to have a backdoor that relies on a vulnerability with how keys are verified. Just use an obfuscated master key baked into a ROM within your NVRAM or something.
@@KopperNeomanthey need plausible deniability so that the sheep don't get too suspicious
I had an ASUS F2A85-M with Coreboot back when socket FM2 and Athlon was "modern".. I think it has merit to look if UEFI was really the right way, especially when you realize that ALL computers have a management console running on their PCs. At all times. Even when the PC is "off". Without their knowledge. At Ring -1 level.
So AMD platforms not affected?
you know any amd mobo with Phoenix firmware? then maybe yes. mine runs AMI - American megatrends
Incredible video as always
wake up babe new vulnerability xd
Kaby Lake is 7th gen, not 12th.
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)
My approach:
Security by Legacy 🤪
NSA defeated again
For context, early 2016 the US government was heavily stressing a need to access personal encrypted devices. a year later (2017) KabyLake (the earliest intel code name mentioned) has this uefi vulnerability? Probably coincidence.
@@ImplicitFlower Totally (/s)
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
Ed from the Ol' Learning channel discusses a serious bug in UEFI, the code that turns on computers, which can give hackers permanent access regardless of OS or CPU changes. The vulnerability, named UEFI Can Has Buffer Overflow, was discovered by the security research firm Eclips. This issue affects UEFI firmware, which is difficult to write and only provided by a few companies, making it a supply chain vulnerability. The flaw, found in Phoenix Technologies' secure code firmware, allows local attackers to escalate privileges and gain code execution within the UEFI firmware during runtime. The speaker suggests upgrading the UEFI firmware as a mitigation but notes the difficulty and potential risks involved. The video also highlights the broader implications of bugs at low levels in the software ecosystem. The vulnerability was discovered using automated binary analysis and stems from a buffer overflow in a variable called tcg2, where the firmware attempts to read the variable but the data size is not checked properly.
There are rings below 0?
Kind of. Negative rings aren't really implemented as separate protection levels (like rings 0-3 are), but rather are just colloquial terms for different states/configurations of the system. For example, the Hypervisor is technically also running in ring 0, but it can emulate stuff for the virtualized OS/kernel by using vmenter/vmexit, so it is oftern called "ring -1". Ring -2 is System Management Mode and ring -3 is the Management Engine (which is a completely separate processor installed on the Motherboard that can temporarily "pause" your primary CPU and do whatever it wants, so ring -3 code isn't even running on the primary CPU). So yeah, the negative rings are actually closer to "weird stuff that your computer can do" rather than conventional protection rings on the CPU.
0:01 dude thanks for the diagram of a computer.
We all knew when tpm was made enforceable for win 11, there was going to be something like this found
AMI here. Uff!! Anyhow it doesn't mean there's not vulnerability going one, it just hasn't been published :P
does an attacker need physical access to the pc ?
@@postiemania Yes they do.
@@blackmagicprod7039 after losing a computer to a brick attack on my bios via the internet I tend to disagree the same attacker disabled the HDMI Port on my laptop. It took me 10 years to find out who and why.
@@postiemania "I don't know" is an acceptable answer.
@postiemania Your comments reek of "I'm 14 and just learned this, heh look at how much I know"
Define encrypted data that "they know"
@@postiemania We are past that. We are discussing your conspiratorial comment.
weird code, the fact that it such a specialized field makes me think this was not a mistake by a beginner but it‘s a backdoor instead
0:35 its not forever, I can rewrite the nvflash
Yeah YOU
@@LowLevelTV yep, I'm going to pay special attention on any motherboard that I buy to have external NVRAM so I can flash it, because some motherboards include it on the chipset, that's way harder to flash if they burned the fuses (you have to drill the chip or somethign)