Summary
CompuLab have not enabled signature checking of firmware updates for the Intense PC product line. This allows anyone in possession of the Phoenix UEFI update program to write a modified UEFI firmware to system flash. DOS/Windows versions of the Phoenix utility are easily obtained online, allowing a local or remote attacker to install a persistent firmware level rootkit to the computer, or to corrupt the system firmware, causing a denial of service.
Installation of a modified firmware can occur entirely in the background, without any user interaction, and once performed is virtually impossible to difficult to detect using operating system utilities. Physical access is not required.
Product description
The CompuLab Intense PC is fanless mini-PC. A model pre-installed with Linux Mint is also marketed under the name MintBox 2. The system firmware is the same for the Intense PC and MintBox 2. CompuLab also sell the Intense PC with an extended temperature range for industrial applications.
The product was introduced in mid-2013 and is still being sold through Amazon US, Amazon Canada, Amazon Germany, Amazon Spain, and directly from CompuLab.
Affected products
- Intense PC (Intense PC Value, Intense PC Business, Intense PC Pro)
- MintBox 2
Impact
Any software running with local administrator privileges has unrestricted access to read and write the system’s firmware.
An attacker can modify the contents of the system firmware to install a persistent rootkit/bootkit, or to corrupt the firmware causing the computer to cease functioning.
The attack only requires local administrator privileges, and can be executed either by using an existing OS-level exploit to gain local administrator, or via tricking the user into running an executable (e.g. via an attachment in a phishing email).
Proof of Concept
The proof of concept provided for CVE-2017-8083 can be leveraged for this vulnerability as well. The proof of concept uses the Phoenix UEFI Winflash utility to write a modified firmware to flash. Please refer to the article about CVE-2017-8083 for a detailed description of the proof of concept.
The latest CompuLab firmware for the Intense PC (20170521) modified with the upstream EDKII shell can be downloaded here.
Mitigation
At this time there is no means for the end user to enable Capsule Signature verification or to prevent the Phoenix update utility from updating the system firmware.
Therefore Intense PC owners should consider the following options:
- Ensure your operating system is up to date with the latest security patches. Do not run software from untrusted sources.
- Do not connect your Intense PC to any networks with internet access (i.e. air-gap the computer).
- Discontinue your use of the Intense PC and consider replacing the computer with one from a different manufacturer who implements signature validation for firmware updates.
Should CompuLab decide to improve the security of the Intense PC firmware by enabling Capsule Signature validation, then the above recommendations would no longer apply. However, in my communication with CompuLab regarding this issue no indication was given that they have any plans to enable Capsule Signature verification in a future update. Therefore, it seems very unlikely to me CompuLab will issue an update which enables Capsule Signature verification.
Disclosure timeline:
6 June 2017: Issue reported to CompuLab
6 June 2017: CompuLab confirms that “Default settings of this source tree [Phoenix SecureCore Tiano Enhanced Intel Ivy Bridge CPU Panther Point M] has disabled Capsule Signature option.”
6 June 2017: Issue is reported to MITRE
6 June 2017: Vulnerability is assigned CVE-2017-9457
7 June 2017: CompuLab are informed that the vulnerability has been assigned CVE-2017-9457 and details of the vulnerability will be published after 45 days
Pingback: CVE-2017-9457 CompuLab Intense PC lacks firmware signature validation | Totally Secure
Pingback: CompuLab MintBox 2 Review | «WatchMySys» Blog
I do disagree with the idea that firmware signature validation should be mandatory (which you seem to promote), as it usually makes it impossible for free software projects like Coreboot to make compatible ports. The benefits with Coreboot are that we can get a better idea of what is running on the computer (therefore more secure) and faster boot times. Some vendor BIOSes restricts what wifi cards can be used and that is not in the user’s interest, too.
I think it would be better with firmware signature validation that can be turned off by the user (of course in the BIOS, not from OS level).
I didn’t mean to imply that the only way forward was to strictly enforce firmware signature validation. So I agree with you that the option to enforce signed firmware updates should be a requirement for anyone designing a computer.
In the old days of BIOS, there was a write-protect jumper you could select to prevent BIOS updates. With UEFI, such a jumper is not possible anymore as flash is partitioned between ROM and EEPROM components (e.g. saving UEFI boot entries) and a write-protect jumper on the hardware part would prevent fundamental parts of UEFI from correctly functioning. Therefore write-protection must be implemented at a software level.
The fact that a firmware signature validation option is missing completely is a huge security oversight by CompuLab and leaves their users open to malicious software installing rogue firmware updates or bricking the device. Sadly they have not shown any interest in including a firmware signature validation option.
This isn’t necessarily true. Most complaints about x86 platform security stem from the Intel Management Engine (IME) which Coreboot can’t disable on newer platforms (such as this one). Additionally, at a firmware level a lot of code is very specific to the exact hardware in question, and may rely on proprietary/NDA-level information (e.g. IOMMU) to achieve the same functionality as proprietary code it aims to replace.
Having a FLOSS firmware will not necessarily lead to more people being able to improve it or fix bugs. I think this is well illustrated in the extremely small number of targets Coreboot supports.
Gustaf, you may be pleased to hear that I have ported coreboot to this hardware, so the vendor’s lack of signature verification/enforcement is no longer a concern 🙂