4 ms·
From what I understood this could attack systems using the MBR, non UEFI systems or using an hybrid approach, which is not encrypted nor protected, thus the pro
by escanda 15y ago
From what I understood this could attack systems using the MBR, non UEFI systems or using an hybrid approach, which is not encrypted nor protected, thus the program can rewrite it and it fits within its boundaries. As it is run before control is passed to the OS, the OS can't do anything at all. If the attacker has physical access and can write the MBR or if there's a privilege escalation good enough to grant itself access to the MBR, you're powned. But I couldn't tell if UEFI protects its partition table in some way.
- mjg59 15y agoUEFI doesn't execute anything from the partition table. The firmware reads files from the filesystem and executes them. If it implements secure boot, it validates a signature on the binary first - failing to validate means it won't execute the binary. So there's no protection of the partition table, but the only thing you can do by attacking it is to render the machine unbootable. Attacking secure boot involves elevating your privileges within the UEFI environment.
- mattmanser 15y agoI came across this while trying to understand the significance: http://simonhunt.wordpress.com/2009/08/04/truecrypt-vs-peter-kleissner-or-stoned-bootkit-revisited/ http://simonhunt.wordpress.com/2009/08/04/truecrypt-vs-peter... So if it's doing the same thing and needs administrator access in the first place is the problem for secure boot that it can't recover itself as it's supposed to be able to? As truecrypt were dismissing this as insignificant on earlier versions of windows. Is it different for win 8?
- mjg59 15y agoIt's no different. If it's still an MBR-based attack then it's completely irrelevant to UEFI-based Windows installs.