some interesting quotes

[ron minnich]

you may or may not have seen them

http://eecue.com/log_archive/eecue-log-724-Black_Hat_2007___Day_2___John_Hea...

"There are many ways to get code into the EFI environment. An attacker
can modify the bootlader directly, modify bootloader varibles in
NVRAM, modify and reflash firmware or exploit an implementation flaw
in the driver. Once the attacher is in, they can shim a boot service,
modify an ACPI table like in the tradition BIOS attack, load an SMM
driver, or hook interrup handlers. Modifying the boot loader is
actually quite simple in Mac OSX as the bootloader binary is located
in user disk space: /System/Library/CoreSerbvice.boot.efi. This isn't
very stealthy as you are modifying a file on disk which could easily
be detected by verifying checksums with an application like tripwire."

now we've been trying to get this message across for eitght years now
and it's good to see people are independently figuring it out.

Here's another part:

"The bottom line is that with the added functionality, EFI offers an
attacker many more options than BIOS for exploitation. The EFI
specification is not very clear with regards to security which will
result in various vendors implementing insecure versions of EFI. In
the future look out for nasty rootkits based on EFI."

thanks

ron

[Segher Boessenkool]

> "There are many ways to get code into the EFI environment. An attacker
> can modify the bootlader directly, modify bootloader varibles in
> NVRAM, modify and reflash firmware or exploit an implementation flaw
> in the driver.

Nothing specific to EFI here, as far as I can see.  All of this is
true as well for traditional BIOS, Open Firmware, and even coreboot.

Segher

[ron minnich]

On Wed, Jul 30, 2008 at 4:23 PM, Segher Boessenkool
 wrote:
> Nothing specific to EFI here, as far as I can see.  All of this is
> true as well for traditional BIOS, Open Firmware, and even coreboot.

well, I agree with you mostly. EFI, uniquely, is capable of fetching
and loading a new copy of itself autonomously, as well as installing
it with no user intervention -- which I've seen happen on a Mac.
Scares me to death.

Most importantly, while there is the possibility of providing a
verifiable supply chain with coreboot and other open source BIOSes, no
such possibilty exitsts with EFI, as it is a proprietary operating
system. It will never be possible, barring a huge change on the part
of the EFI community, to build such an open BIOS.

ron

[Stefan Reinauer]

ron minnich wrote:
> you may or may not have seen them
>
> http://eecue.com/log_archive/eecue-log-724-Black_Hat_2007___Day_2___John_Hea...
>
> "There are many ways to get code into the EFI environment. An attacker
> can modify the bootlader directly, modify bootloader varibles in
> NVRAM, modify and reflash firmware or exploit an implementation flaw
> in the driver. Once the attacher is in, they can shim a boot service,
> modify an ACPI table like in the tradition BIOS attack, load an SMM
> driver, or hook interrup handlers. Modifying the boot loader is
> actually quite simple in Mac OSX as the bootloader binary is located
> in user disk space: /System/Library/CoreSerbvice.boot.efi. This isn't
> very stealthy as you are modifying a file on disk which could easily
> be detected by verifying checksums with an application like tripwire."

Our goal, too, is not being stealthy.

Which is why I was quite surprised that not using the locked away memory
areas for my SMM handler was considered a knock-out criterionfor that
approach.
> now we've been trying to get this message across for eitght years now
> and it's good to see people are independently figuring it out.

The one thing that transports our message best, in my opinion, is ports
to new chipsets and ports to new boards.

Stefan