Published October 20, 2020
Simply put, firmware is low-level software usually stored in a near-silicon form (ROM, EEPROM, or flash memory) that is used during the initial steps of bootstrapping and starting up a computer, printer, or some other kind of electronic device. Alternatively, firmware may serve to drive device-level communications with other components in a computer or other electronic device. Well-known instances of firmware include BIOS, UEFI, codes in audio devices or components, and so forth.
Where there’s firmware, there’s often microcode as well…
According to an ancient (1967) Datamation article firmware also describes a writable control store (a specialized limited set of high-speed memory locations) that contained so-called “microcode” to define and implement a computer’s instruction set. This is what drives instructions that CPUs can execute, and can be reloaded to update, specialize or modify the current instruction set.
Firmware thus sits between hardware (the registers, processing units, busses, and so forth) and binary code (software instructions that have been translated into machine instructions for step-by-step execution). This is often called microcode and basically provides the irreducible elements in a CPU (or other processor) that supports individual machine instructions. Because firmware sits between hardware and software and is neither of those things, it’s long been called firmware.
Because microcode may be updated or modified, it can also be attacked
Over the past 4-5 years, for example, Intel processors have shown themselves susceptible to numerous, colorfully named microcode attacks. Two early instances of such attacks include Meltdown, aka Rogue Data Cache Load, identified as CVE-2017-5754; and Spectre, identified as CVE-2017-5715.
Meltdown, if foisted, can sever the isolation normally maintained between user applications and the OS, allowing programs to ransack all memory on a compromised device. Spectre is similar, but enables attackers to force normally secure, error-free applications into leaking memory contents (secrets) to other applications. Thus, a malicious application could then “sniff” memory from normally secure code without throwing errors or other means of detection.
There are many more such vulnerabilities now known in the wild. As recently as September 1, 2020, Intel published a Microcode update for a broad range of its processors that covered 4 additional microcode vulnerabilities, to wit:
- CVE-2019-11091 – Microarchitectural Data Sampling Uncacheable Memory (MDSUM)
- CVE-2018-12126 – Microarchitectural Store Buffer Data Sampling (MSBDS)?
- CVE-2018-12127 – Microarchitectural Load Port Data Sampling (MLPDS)
- CVE-2018-12130 – Microarchitectural Fill Buffer Data Sampling (MFBDS)
Where the danger in firmware/microcode vulnerabilities lies
Firmware (and microcode) operate at the lowest level within the devices they inhabit. They take up residence before a BIOS or OS starts up, and operate outside their purview and control. If an attacker can foist a firmware or microcode exploit, there’s very little runtime software can do to counter (or even detect) its presence and behaviors. Thus, a successful firmware or microcode exploit usually gives an attacker free rein and unlimited access to a compromised device (though they may also need direct access to that device to foist the exploit, or take advantage of its abilities).
Most experts agree that the only response to such vulnerabilities is to closely monitor security updates from device makers, and install them when available. Such updates are routinely packaged up and distributed as security updates by most major OS providers, too. This includes Microsoft Windows, major Linux distributions, and the MacOS for tablets and desktops, with similar coverage for Android versions and iOS for mobile devices as well. Thus, for example, Microsoft KB4558130 covers the vulnerabilities mentioned above and includes the Microsoft Update Catalog entries for corresponding microcode patches for PCs with affected CPUs.
Companies that follow cybersecurity news and/or threat intelligence feeds will normally get routine notification when firmware-related vulnerabilities are discovered, either in the wild (most dangerous) or by security researchers (still dangerous, but not necessarily an immediate threat). They should then start watching for news of related patches and fixes, which will usually originate from the device makers themselves (for example, Intel and its CPUs) and then propagate out to the OSes that use or run on such devices (as was the case with Micrsosoft’s KB4558130 update cited earlier).
What’s the net-net?
Keep an eye on cybersecurity news and track firmware vulnerabilities relevant to your devices. Monitor device and OS maker’s updates and security announcements to learn when patches and fixes get released. Once available, it’s important to apply such patches and fixes as soon as maintenance and update schedules permit.
Would you like to know more about building secure applications? Get in touch with our Kiuwan team! We love to talk about security.