Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
1–10 of 142 posts
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#2[dead]
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#3> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables.
Sheer incompetence, in other words.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#4[deleted]
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#5> Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses.
Excellent.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#6> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.
This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#7> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.
UEFI variables or not: who in their right mind serializes raw pointer values to any kind of storage (network, disk, nvram, ...)?
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#8Fortunately there's a FLOSS alternative: TPM with Heads, https://osresearch.net/. Works for me.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#9> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.
UEFI variables or not: who in their right mind serializes raw pointer values to any kind of storage (network, disk, nvram, ...)? Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
Security is competing with all other requirements that a product has. That's all there is to it.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#10Please ... just give me back my BIOS.