Security to Eclipse User Features as Top 2015 Firmware Story

I stepped out on a limb this year and made a prediction. Predictions are notoriously fraught with peril and I am usually off-base or overly optimistic in mine. Nonetheless, as CTO of Insyde Software, I guess its also an unenviable part of my job. So here it goes:

'security' will eclipse 'lost my password', 'can't flash my BIOS' and 'overclocking' as the top firmware story in 2015.

For each of the previous hot firmware topics, the focus was on the user doing something correctly or incorrectly. The assumption was: if you don't do something dumb, your system will be ok.  Now, with security: even if the user doesn't do something dumb, it is possible that the system is not ok.

The OEMs (and firmware vendors) are now find themselves in the hot seat. Recent Black Hat presentations have increasingly focused on the vulnerabilities to be found in open source and closed source firmware implementations. Since firmware occupies such a privileged position in the software stack, successfully compromising it opens up a world of malware possibilities. With UEFI, the firmware has also become more capable and standardized, so more resources are theoretically available

The UEFI Forum has recognized this for a while and responded by creating a flexible OS secure boot and secure firmware update strategy in version 2.4 of the specification. The various software initiatives (including the open source ones) have followed quickly behind to implement these standards. But the security researchers and hackers began picking those apart, looking for and finding corner cases.

So the UEFI Forum responded by creating the USRT (UEFI Security Response Team), headed up by friend and former colleague, Dr. Dick Wilkins. The USRT provides a single point of contact for researchers to report their findings and disseminate those to silicon, software and system vendors.

At the same time, various UEFI Forum members, including Intel and my own company, Insyde Software, are producing domain-specific tools to test for certain well-known classes of vulnerabilities that are specific to our products. Intel has announced support for the CHIPSEC tool which evaluates the register settings in the motherboard chips to see if they are correctly configured to protect the firmware and boot process. Insyde is working on tools which check the various runtime interfaces we provide (and which OEMs extend) for classic API issues including buffer overflow and pointer validation.

Both UEFI's USRT plans and current firmware security tools will be discussed at the upcoming UEFI Plugfest, which is coming to Taipei from 13-17 October.

No one wants their company name featured in a security vulnerability press release. We'll talk again next year and see if my prediction is right.

UEFI Gains New Members, Touts Their New White Paper

Back on September 18th, UEFI Forum posted a press release (found here) talking about how the number of adopting companies had topped 250, including Huawei, the Linux Foundation and Novell. They also mentioned their new white paper "UEFI Secure Boot in Modern Computer Solutions" by Brian Richardson and my former colleague, Dick Wilkins which gives an excellent overview of the state of the industry on this sometimes controversial topic.

The Linux Foundation news plays well with the fact that the UEFI Plug Fest was co-located with LinuxCon in New Orleans this past week. Linux-as-business has generally come to terms with UEFI and its secure boot strategy. Linux-as-religion may never come to terms with it. Every major Linux distribution supports UEFI secure boot, including SUSU Labs, who spoke at the Intel Developer's Forum two weeks ago, describing their infrastructure for extending secure boot from the UEFI hand-off up through loading the kernel.

What does this really mean? UEFI continues to expand the range of platforms and operating systems on which it can create a powerful pre-OS boot environment. And the UEFI specification is making orderly progress in addressing the needs of the people who ship systems and those who produce code that runs on those systems.