[HN Gopher] Another Crack in the Chain of Trust: Uncovering (Yet...
       ___________________________________________________________________
        
       Another Crack in the Chain of Trust: Uncovering (Yet Another)
       Secure Boot Bypass
        
       Author : vitplister
       Score  : 36 points
       Date   : 2025-06-10 19:55 UTC (3 hours ago)
        
 (HTM) web link (www.binarly.io)
 (TXT) w3m dump (www.binarly.io)
        
       | db48x wrote:
       | > The root cause of this bug, once again, lies in the unsafe
       | handling of NVRAM variables.
       | 
       | Sheer incompetence, in other words.
        
         | candiddevmike wrote:
         | This is all too common with any kind of user infantilizing
         | security feature. Trust us bro, it's secure.
        
         | OjotCewIo wrote:
         | 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.
        
           | gmueckl wrote:
           | Security is competing with all other requirements that a
           | product has. That's all there is to it.
        
           | EPWN3D wrote:
           | They're not. They're ravaged by probably the same quality or
           | slightly higher than average. The cost of mistakes is just
           | way higher.
        
           | db48x wrote:
           | It's something about hardware companies writing software. The
           | motherboard itself may be excellent, but the BIOS/UEFI/ACPI
           | tables will be horrible.
           | 
           | Meanwhile you look at a company like Oxide that is a software
           | company at heart, and their equivalents are so much better.
           | Like someone actually designed it so that when humans write
           | the software it will still be secure.
        
       | baxtr wrote:
       | _> 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.
        
       | fsflover wrote:
       | Fortunately there's a FLOSS alternative: TPM with Heads,
       | https://osresearch.net/. Works for me.
        
         | 1oooqooq wrote:
         | why not secure boot with your own keys?
         | 
         | ... granted, effectively removing Microsoft keys is a pain on
         | some consumer devices, but still easier than this
        
       | jerhewet wrote:
       | Please ... just give me back my BIOS.
        
         | gruez wrote:
         | BIOS isn't magically secure either. It has no secureboot so it
         | just runs whatever.
        
       ___________________________________________________________________
       (page generated 2025-06-10 23:00 UTC)