|
Authored by: reiisi on Tuesday, July 09 2013 @ 09:30 PM EDT |
Point by point, not taking the time to do it pretty:
First, about signed, compromised code --
If you enable a key and someone gives you compromised code signed by that key,
UEFI, by definition, can't do anything about it.
Result: Boot.
Hoping otherwise is pipe dreaming.
With that understood, you must re-read the next question.
Sure, if UEFI worked as advertised, it would provide an additional layer of
protection against various exploits digging down into your bios, etc.
It doesn't, and I've just told you one of the reasons why.
So a carefuly maintained OS booted through a UEFI-enabled BIOS does not actually
end up providing any more protection than a carefully administered running
without UEFI.
In particular, "Someone with network access" succeeding in a
man-in-the-middle attack on my machine succeeds whether I've used UEFI
code-signing or not.
If that attack drops a compromised BIOS, and the compromised BIOS is not signed
by a key I have enabled, then and only then does UEFI have a prayer of doing
something about it -- on the next boot.
Plenty of time before then next boot to carefully examine the BIOS, determine
which keys are enabled, and, if there is an enabled key that the attacker has
access to, UEFI is clueless on re-boot, too.
Keys have already been compromised. We have reports of that. We have no reason
to trust that Microsoft can keep their keys uncompromised, and the time lag from
the compromise to the report is a window open to attack, and the time lag from
getting the report to actually re-signing your BIOS with a valid key is yet
another open window.
The only way to close this window is to use only locally generated keys when
using a BIOS that checks keys and signatures. That means you have to sign the
BIOS yourself. Not Microsoft. Not Intel. Not Dell.
Not even Google.
Not even the Debian project team (or Fedora/RedHat/Ubuntu/etc.)
If a manufacturer were to do this half right, they would sign the BIOS and any
provided OS from the factory, with a published read key that would change at
least every month. You would check the signature when you opened the package and
then sign it yourself with your own key.
But you're still trusting the factory.
You can't do that if you want to be sure you know what is going on in you
machine.
(Although we can generally trust the open source project teams a bit more than
any closed corporate team.)
Physical access?
Yeah, resetting the key storage is one potential way on some Motherboards. It
isn't the only way to get around UEFI.
If you don't know how to get around UEFI when you have physical access, you
don't know something you should know about, especially if you are going to run
around promoting UEFI.
The ways exist. They depend on the mother board construction, somewhat. In some
cases (precious few) disabling UEFI non-destructively is a little beyond the
average attacker with a soldering iron. But not beyond one with a scope and
certain other tools that are not hard to get.
UEFI is simply one more speed bump. It will slow some attackers down, so it may
be useful to some people who don't have reason to believe a reasonably skilled
attacker will target them.
But a security blanket is not what people who understand the problem want.
By the way, you mention "rescue OS", I assume you mean a signed live
CD/DVD/USB/SD or whatever. The existence of such a rescue OS inherently weakens
all arguments for UEFI.
[ Reply to This | Parent | # ]
|
|
|
|
|