Windows 10 Secure Boot and the System Management Mode (SMM) BIOS vulnerability

cybersecurity CSC Blogs

One of the core features for Windows 10 Enterprise that many businesses are wanting to deploy is Secure Boot. Secure Boot was available in Windows 8 and 8.1, but as many organisations decided to skip those versions, it’s only with Windows 10 that it’s being widely implemented.

Secure Boot is, as its name suggests, enables devices to boot in a known secure way. It’s dependent upon a change in the interface between the device firmware and the operating system. I’m not intending to fully explain this interface and the various things that it does (that would take a number of posts, and the descriptions on Wikipedia are good enough), but it is worth having some basic understanding.

For decades the interface between firmware and operating system has been provided by the Basic Input/Output System (BIOS). That interface has a number of limitations and is susceptible to a number of security vulnerabilities, including kernel mode malware and bootkits. A bootkit targets an operating system before it’s even loaded.

Newer PCs are shipped with a different interface, Unified Extensible Firmware Interface (UEFI), and it’s the full utilisation of UEFI that enables Secure Boot. Most devices are currently configured to use a BIOS compatibility mode because their operating system doesn’t support the use of UEFI.

Boot SequenceSecure Boot works by verifying that the boot loader (the code that starts the operating system) is what it says by checking certificates that are locked away in the device firmware. Anything tampering with the boot loader will stop the operating systems from starting.

That’s how the theory goes. Unfortunately, where there’s code, there’s a vulnerability.

Recently an “independent researcher” known as Dmytro Oleksiuk posted code on GitHub highlighting a privilege escalation vulnerability in UEFI:

“Running of arbitrary System Management Mode code allows attacker to disable flash write protection and infect platform firmware, disable Secure Boot, bypass Virtual Secure Mode (Credential Guard, etc.) on Windows 10 Enterprise and do others evil things.”

The documentation on GitHub initially identified the vulnerability in Lenovo laptop devices. Lenovo has acknowledged that the vulnerable code is in its devices, and is investigating, but the company also pointed out that the code came from a supplier to them used by other vendors. Later updates on GitHub have highlighted that the vulnerable code is a copy-and-paste of Intel reference code, so the problem is likely to affect other device vendors. Other vendors haven’t acknowledged that the vulnerable code it present in their devices.

At present there is no fix for this vulnerability, nor anything that exploits it other than the demonstration code provided by Dmytro.

The emergence of this vulnerability highlights a number of things:

  • Never rely on a single security measure: If you only rely on one method of security control, any vulnerability in that measure exposes you to the full impact of that vulnerability. Whilst multiple methods of control may not fully mitigate a vulnerability they significantly reduce the risk.
  • Patch management is key: A fix for this vulnerability will be published, but organisations will only be protected when that update has been distributed to all of the affected devices. This isn’t going to change, and organisations should put in place processes that make patch management a continuous process.
  • Vulnerability monitoring is a must: You can only fix what you know about, and monitoring a number of different industry sources will keep most organisations aware of the risks that they face.
  • Tier the response based on the risk: Some vulnerabilities create greater risks than others and the response needs to be appropriate. This response needs to include an appropriate level of testing, but it’s no longer appropriate to delay high risk patches for protracted periods of testing.

For more detailed information see: Secure BootDevice Guard and Credential Guard.

Graham ChastneyGraham Chastney is a Technologist in CSC’s Global Infrastructure Services. He has worked in the arena of workplace technology for over 25 years, starting as a sysprog supporting IBM DISOSS and DEC All-in-1. Latterly Graham has been working with CSC’s customers to help them understand how they exploit the changing world of workplace technology. Graham lives with his family in the United Kingdom.

Twitter: @grahamchastney


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: