How many operating systems are running on your Intel machines? Probably more than you might think. There’s the BIOS/UEFI system used to boot most systems, for starters, which is essentially an operating system. And then, of course, there’s the main operating system most users are familiar with including Windows or Linux.
At this point, the ME issue affects the 6th, 7th, and 8th Generation Intel Core family; the Xeon Processor E3-1200 v5 and v6 family; the Xeon Processor Scalable family; the Xeon Processor W family; the Atom C3000 Processor family; the Apollo Lake Intel Atom Processor E3900 series; the Apollo Lake Intel Pentium series; and the Celeron N and J series.
Intel has provided a detection tool for Windows and Linux that will indicate whether a chip has the identified issues. Fixes have been released by Intel through a number of vendors whose BIOS/UEFI updates address the problem. There is also an undocumented process for disabling ME.
Flaws in firmware or software are not uncommon, but ME has been an issue because it is essentially hidden. It’s actually a version of the MINIX operating system plus applications for managing the chips services. Researchers had warned about problems with ME, as well as Intel’s approach to using it in chips, for a number of years.
ME is not the only security platform at issue for Intel. Its Active Management Technology (AMT), found on the Pro version of chips, provides remote management support that bypasses any running operating system. There are flaws in that as well. Firmware updates can address many of these issues, but, like the ME issues, users must identify the problems and install the appropriate firmware updates. This is usually impossible from the operating systems they directly utilize.
Using an internal operating system is nothing new. Arm’s TrustZone has its own firmware and AMD’s latest x86 processors include the Platform Security Processor (PSP). PSP is actually an ARM core with TrustZone support. Like ME, its workings are hidden from normal users and developers, and can have security issues that would be hard to identify and hard to update (assuming that’s even possible).
Embedded developers are not immune to these problems. Correcting problems can be a challenge, especially since many applications have certifications or approvals that would be affected by making updates. Disabling services like ME may be a desirable alternative for many embedded applications, but the implications on stability and services can be a major issue. Of course, security breaches will be an issue as well.
Unfortunately, these kinds of security issues are on par with the ability to hide viruses on disk drives by changing the firmware. The attack vectors for this and platforms like Intel’s ME-based solutions may not be easy, but like root kits, security breaches of this type are very hard, if not impossible, to detect once they are installed.
There are few good alternatives at this point. Given the size of much of the security code, it is surprising that more rigorous methods were not use in the development. Using tools like Ada and SPARK along with more formal methods like DO-178 for avionics would be more inline with platforms that affect almost all new PCs on the planet.