Re:AMI-Bios Sourcecode and UEFI Signing Key leaked?
by aortega on Friday April 05, 2013 @01:10PM
(#5499639)
>I'd assume once you're in OS, all bets are off in terms of who can do what to the hardware.
A common misconception. Even if you are running as ring-0, there are things that you cannot do, and only BIOS can. For example, executing code in SMM mode, mapping/hiding portions of memory, or changing some PCI configuration options that get "locked" after BIOS.
Re:AMI-Bios Sourcecode and UEFI Signing Key leaked?
by zdw on Friday April 05, 2013 @03:30PM
(#5500506)
Sounds like a chicken/egg scenario if you're able to reflash the BIOS arbitrarily.
Re:AMI-Bios Sourcecode and UEFI Signing Key leaked?
by qb45 on Friday April 05, 2013 @12:28PM
(#5499386)
I'm talking about really secure systems, although I'm not sure if such exist in real world.
If we take BIOS security seriously, access to BIOS flash must be restricted to BIOS setup application, for example by programming some non-resettable "write protect" bit before booting the OS.
Re:AMI-Bios Sourcecode and UEFI Signing Key leaked?
by mentat on Friday April 05, 2013 @12:54PM
(#5499555)
Corporate espionage rarely rises to this standard, which was the author's concern.
Re:AMI-Bios Sourcecode and UEFI Signing Key leaked?
by pacaro on Friday April 05, 2013 @04:48PM
(#5500963)
Dumpster diving seems to be the high point, if Larry[1] is anything to go by.
At least this is what people have be caught doing!
[1] http://www.time.com/time/magazine/article/0,9171,49039,00.ht...
On an infrequent basis I've used Flashrom (http://www.flashrom.org) to burn new system BIOS's into flash on a running Linux system. Much easier than fiddling with DOS boot disks, etc. Thus, anyone who can exploit to root could theoretically reflash the BIOS in a system with code that would be persistent through OS reinstallations. Personally, I'd focus on the PXE ROM if asked to compromise systems in this way.
Some older systems have jumpers on board that can write protect the BIOS, but frequently they either default to being in the writable state. I haven't noticed these jumpers on modern PC hardware for a while.
This isn't unique to UEFI Secure Boot systems - I'd assume once you're in OS, all bets are off in terms of who can do what to the hardware.