1 |
On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gregkh@g.o> wrote: |
2 |
> Huh? No, why would a user need to resign the UEFI drivers? Those |
3 |
> "live" in the BIOS and are only used to get the machine up and running |
4 |
> in UEFI space, before UEFI hands the control off to the bootloader it |
5 |
> has verified is signed with a correct key. |
6 |
|
7 |
Is that always the case? E.g., kernel's efifb module uses the EFI |
8 |
console driver, similarly to legacy BIOS's VESA interface. It is |
9 |
possible that in the future more OS-usable EFI drivers will become |
10 |
commonplace, especially for non-performance-critical periphery |
11 |
interaction (sensors, etc.). Architecture-independent EFI bytecode |
12 |
drivers apparently don't have OS interface now, but this could change |
13 |
as well. |
14 |
|
15 |
>> If the user does not perform this procedure (due to its |
16 |
>> complexity and/or lack of tools automating the process), is it |
17 |
>> possible for an externally connected device to compromise the system |
18 |
>> by supplying a Microsoft-signed blob directly to the UEFI firmware, |
19 |
>> circumventing the (Linux) OS? |
20 |
> |
21 |
> Again, what? Please explain. |
22 |
|
23 |
I am thinking about a possibility where a “rogue” device can upload |
24 |
its driver directly to the UEFI firmware. I don't see something like |
25 |
that in the UEFI spec, but perhaps the firmware can support such |
26 |
behavior outside the spec. E.g., many 3G network tokens support |
27 |
presenting themselves as network devices or as storage media on the |
28 |
USB bus (sys-apps/usb_modeswitch deals with that). The reason they do |
29 |
that is for the OS to install the network driver from the storage |
30 |
media “representation”. Now, imagine that the OS defers handling of |
31 |
unfamiliar network devices to the UEFI network driver (as it might do |
32 |
with unfamiliar video cards and UEFI GOP). It makes sense that UEFI |
33 |
firmware vendors would support a similar mechanism of loading |
34 |
(possibly EBC) UEFI drivers from the network device. Why not — the |
35 |
drivers will be signed, and UEFI can verify the signatures. |
36 |
|
37 |
So it seems to me that UEFI, because of its complexity and multitude |
38 |
of features, may provide an OS-circumventing attack vector, which can |
39 |
only be dealt with by revoking (probably Microsoft) keys in UEFI |
40 |
firmware, and re-signing only the necessary drivers with a custom key. |
41 |
Compromising major player's certificates is a real possibility — e.g., |
42 |
see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft. |
43 |
|
44 |
> What API? The signing tool is public, and no, it doesn't add keys, |
45 |
> that's up to the BIOS to do, not the userspace tool. |
46 |
|
47 |
So the re-signing mentioned above must be done in a tedious manual |
48 |
process? Or can some automatic tool be developed (not necessary |
49 |
userspace, it can be an EFI app)? |
50 |
|
51 |
-- |
52 |
Maxim Kammerer |
53 |
Liberté Linux: http://dee.su/liberte |