bk99.de entertain the web since 1997

bk99.de
Matthew Garrett · Firmware securityCurated

Secure Boot in practice: How firmware bugs undermine the protection

Summary

Matthew Garrett summarises MITRE’s research from SyScan 2014: on many computers, Secure Boot can be bypassed from within the running operating system. The cause is not the cryptography but wrongly stored policies and missing lock bits in the chipset. Garrett still considers Secure Boot a real security gain whose obvious flaws will only disappear over several hardware generations.

Ideas

  • Some manufacturers store parts of the Secure Boot policy in UEFI variables that are writable at runtime.
  • Attackers then change the policy instead of visibly switching off Secure Boot.
  • Afterwards, the firmware no longer checks signatures on built-in drives.
  • UEFI variables live in flash memory behind the chipset’s SPI controller.
  • Write attempts to the flash are supposed to trigger a System Management Interrupt and be rejected.
  • Intel chipsets allow all SMI sources to be switched off unless a lock bit prevents it.
  • Without the lock bit set, malicious code can overwrite any variable, including the one that enables Secure Boot.

Insights

  • A chain of trust is only as strong as its worst configured link.
  • Cryptographically correct methods often fail because of manufacturers’ default settings.
  • Industries without a security tradition need several product generations before protections become effective.

Quotes

  • Security tends to be an iterative process. – Matthew Garrett

Facts

  • According to MITRE, only around 0.03 % of the computers examined completely blocked flash writes outside System Management Mode.
  • Around 40 % of the computers tested did not set the lock bit against switching off the SMI sources.
  • Boot-time variables are inaccessible to the operating system after ExitBootServices() has been called.
  • Corey Kallenberg presented the research at SyScan 2014 under the title “Setup for Failure: Defeating SecureBoot”.

References

Critique

  • The article relies on someone else’s study and names neither the sample size nor the device models.
  • Affected manufacturers and firmware versions remain open, which makes your own risk assessment harder.

Remarks

  • By Garrett’s own account, Garrett had already expected in 2012 that the first Secure Boot generations would be flawed.
  • Hardware-based methods such as Intel Boot Guard check the firmware itself before Secure Boot takes effect.

Recommendations

  • Keep BIOS and UEFI firmware as up to date as the operating system and kernel.
  • Check flash write protection and lock bits with CHIPSEC on representative hardware.
  • Treat Secure Boot as one layer of protection and complement it with TPM measurements and integrity monitoring.

Read the original article on mjg59

Search the Web Archive

Matthew Garrett · 2011

UEFI Secure Boot: Why signed firmware could lock out Linux

Shortly before Windows 8, Matthew Garrett explains the key model of UEFI Secure Boot and warns that computers with only OEM and Microsoft keys will no longer boot a generic Linux. According to Garrett’s analysis, signed Linux versions fail because of GPL bootloaders, self-built kernels and the lack of a central signing authority. The assessment: it is too early to panic, but not too early to be concerned.

hß · 2014

TR-069 remote maintenance hole in DSL routers: German internet providers call their networks secure

After Shahar Tal’s DEF CON talk about holes in TR-069 remote maintenance servers, heise asked German providers in 2014 how they were protected. Telekom, Vodafone, 1&1 and others considered their networks secure because their routers reject self-signed certificates or only contact preset servers. Tal had shown that a hijacked Auto Configuration Server can redirect or read out thousands of routers.

hß · 2013

More secure temporary files for Linux

In 2013 Linux 3.11 allowed temporary files that are not visible in the file system at all. For this purpose the open() and openat() system calls received the O_TMPFILE flag. This removes the basis for attacks in which attackers gain higher privileges via predictable names of temporary files, for example using symlinks.