Tag Archives: compulab

CVE-2017-8083: Intense PC lacks BIOS Write Protection

6 Replies

Summary
CompuLab Intense PC and MintBox 2 fail to properly write protect flash regions, allowing an attacker with local administrator privileges to write arbitrary code to the platform firmware. This could allow a remote attacker to install a persistent firmware level rootkit to the computer, or to erase 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

At the time of discovery in March 2017, the latest firmware for CompuLab was dated 21 June 2016, and did not enable write protection on any flash regions.

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 firmware update from CompuLab was downloaded, decompressed, and loaded into UEFITool.

The default UEFI shell provided in Phoenix SecureCore was replaced with a newer version of the UEFI shell from EDK2:

The Phoenix SecureCore UEFI Shell was replaced with the EDK2 UEFI Shell.

The modified update was then written to the system firmware using the Phoenix UEFI Winflash utility:

Phoenix UEFI Winflash

It was later realized that the Phoenix UEFI Winflash utility includes a flag enabling a silent firmware update from the command line:

Phoenix UEFI Winflash supports silently updating the firmware from the command line

Using the /remote2 option removes all visual notifications that a firmware update is in progress. Additionally, when used with /console or /remote2 options, the Winflash utility does not reboot the platform when finished. The system continues to function normally, and there is no indication to the user that a firmware update has taken place at all.

Additional information
Output of the chipsec utility:

python chipsec_main.py -m common.bios_wp
################################################################
## ##
## CHIPSEC: Platform Hardware Security Assessment Framework ##
## ##
################################################################
[CHIPSEC] Version 1.3.0
[CHIPSEC] Arguments: -m common.bios_wp

WARNING: *******************************************************************
WARNING: Chipsec should only be used on test systems!
WARNING: It should not be installed/deployed on production end-user systems.
WARNING: See WARNING.txt
WARNING: *******************************************************************

[CHIPSEC] API mode: using CHIPSEC kernel module API
[CHIPSEC] OS : Windows 8.1 6.3.9600 AMD64
[CHIPSEC] Platform: Mobile 3rd Generation Core Processor (Ivy Bridge CPU / Panth
er Point PCH)
[CHIPSEC] VID: 8086
[CHIPSEC] DID: 0154

[+] loaded chipsec.modules.common.bios_wp
[*] running loaded modules ..

[*] running module: chipsec.modules.common.bios_wp
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x08 << BIOS Control (b:d.f 00:31.0 + 0xDC)
[00] BIOSWE = 0 << BIOS Write Enable
[01] BLE = 0 << BIOS Lock Enable
[02] SRC = 2 << SPI Read Configuration
[04] TSS = 0 << Top Swap Status
[05] SMM_BWP = 0 << SMM BIOS Write Protection
[-] BIOS region write protection is disabled!

[*] BIOS Region: Base = 0x00D00000, Limit = 0x00FFFFFF
SPI Protected Ranges
————————————————————
PRx (offset) | Value | Base | Limit | WP? | RP?
————————————————————
PR0 (74) | 00000000 | 00000000 | 00000000 | 0 | 0
PR1 (78) | 00000000 | 00000000 | 00000000 | 0 | 0
PR2 (7C) | 00000000 | 00000000 | 00000000 | 0 | 0
PR3 (80) | 00000000 | 00000000 | 00000000 | 0 | 0
PR4 (84) | 00000000 | 00000000 | 00000000 | 0 | 0

[!] None of the SPI protected ranges write-protect BIOS region

[!] BIOS should enable all available SMM based write protection mechanisms or co
nfigure SPI protected ranges to protect the entire BIOS region
[-] FAILED: BIOS is NOT protected completely

Output of the Intel Flash Programming Tool (FPT):

Intel’s fpt utility showing full write access to flash regions on the Intense PC

Through my discussion with CompuLab support, it has emerged that the issue is due to CompuLab not running CloseMnf prior to shipping. CloseMnf stands for “Close of Manufacturing” and hardens the system by setting write-protect flags for the various flash regions in the Master Access Section of the Descriptor Region.

Intel documentation regarding CloseMnf:

Disclosure timeline:
1 March 2017: Vulnerability is reported to CompuLab via their support email address
2 March 2017: CompuLab replies they will create a beta BIOS to address the vulnerability
6 March 2017: I request a timeline to fix the issue
7 March 2017: CompuLab replies they will create a beta BIOS for testing and they “will provide an official public release in the future”
8 March 2017: CompuLab replies with instructions to run closemnf via the Intel FPT tool
8 March 2017: I inform CompuLab I am waiting for the official BIOS update to resolve the issue
8 March 2017: CompuLab replies with copy of Intel FPT tool and requests “not to publish or disclose this information”
8 March 2017: CompuLab is informed that details of the vulnerability will be published on 4 June 2017
23 April 2017: Issue is reported to MITRE
24 April 2017: Vulnerability is assigned CVE-2017-8083
3 May 2017: CompuLab communicates that they will delay fixing this vulnerability until Intel provides an updated ME firmware to address CVE-2017-5689
4 May 2017: I inform CompuLab that details of this vulnerability will be published on 4 June 2017 as previously discussed
11 May 2017: CompuLab sends a proposed fix for testing, the update script fails due to invalid command syntax for flashrom
14 May 2017: I inform CompuLab of the invalid syntax and provide the correct usage, and confirm that the fix enables write-protection on the ME/BIOS/GbE regions of flash
15 May 2017: CompuLab replies with a revised update script
15 May 2017: I inform CompuLab that the syntax of the revised script is correct, however my unit has already been updated so I cannot re-test
4 June 2017: Details of the vulnerability are published.

CompuLab have provided an update to address the issue.

I can confirm that the Phoenix update utility still functions so it is still possible to update the BIOS even after the FDR has been locked.

CompuLab MintBox 2 Review

Leave a reply

Update 11 December 2017: If you own a MintBox 2 or Intense PC and would like to run an open-source firmware which is not vulnerable to CVE-2017-8083 or CVE-2017-9457, consider flashing coreboot.

Update 30 July 2017: If you own a MintBox 2 or Intense PC your system is vulnerable to CVE-2017-9457. There is currently no planned fix for this vulnerability.

Update 6 June 2017: If you own a MintBox 2 or Intense PC, please update your system firmware to the latest version (21 May 2017). Your system is vulnerable to CVE-2017-8083.

CompuLab’s MintBox 2 is a small embedded computer designed for home, office or industrial applications that retails for $599 US. The MintBox 2 ships with Linux Mint 15 “Olivia” on it, which was supported until January 2014 (last month).

The specifications of the MintBox 2 are:
Intel Core i5 3337U (Dual-core 1.8GHz, 2.7GHz turbo, 17W)
4GB RAM (2x2GB; DDR3 1333 CL9 SODIMMs)
500GB hard drive (2.5″, 5400RPM, Hitachi HCC547550A9E380)
Dual Gigabit Ethernet (Intel and Realtek 8111F; both integrated)
Realtek 802.11b/g/n 2.4GHz WiFi/Bluetooth 3.0 combo card (RTL8723AE; half-height mini-PCIe)

Also present are two eSATA ports (SATA 300), a full size mini-PCIe which can also double as mSATA, DisplayPort and HDMI (CEC is not supported) video outputs, and 3.5mm audio in/out which also support S/PDIF (coax).

The MintBox 2 comes with a 60 month warranty (5 years), with the hard drive being covered for 24 months (2 years).

The shipping configuration uses legacy booting and partitions instead of EFI booting and LVM.

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x16ad26de

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 968752047 484375000 83 Linux
/dev/sda2 968752048 976773167 4010560 82 Linux swap / Solaris

Encrypting user’s home is supported and offers reasonable speeds, but since user data is stored on the same partition as the OS you may run into trouble if you try to upgrade Linux Mint or install another distribution.

The MintBox 2 supposedly supports up to 16GB of memory, and indeed I had no issues with the 4GB installed, or with an 8GB (2x4GB) kit from Patriot memory. I tried three different 16GB kits (G.SKILL, Patriot, Micron) in the MintBox 2, and all three were incompatible. As such, I highly recommend you consult the list of approved memory modules before purchasing a 16GB kit for the MintBox 2. I am awaiting a 16GB kit that was certified to work with the MintBox 2 and will update this post when it arrives.

People familiar with Linux Mint will know what the standard user interface is like, and the MintBox 2 does not deviate from it apart from a cheeky MintBox 2 wallpaper. Everything works out of the box, with ethernet and wireless configured for DHCP. Suspend to RAM works well and performance is on par with other dual-core computers running Linux Mint.

I installed Arch Linux on my MintBox 2 using EFI boot. This requires reformatting the hard drive completely to use a GPT partitioning scheme. An EFI service partition is required to store the grub boot loader, unless you opt to use the EFI stub in the linux kernel (which I did not). You will also have to boot from live media and use the efibootmgr tool to insert a boot record into EFI nvram to point to your boot loader or you will be sitting sadly in the [seemingly] useless EFI shell wondering why it won’t boot.

As with most other consumer electronics, there is little to no option to tweak in the EFI configuration utility (“BIOS”). There are no voltage monitors, and only the CPU temperature sensor is available over SMBus. Users do not have control over CPU speed, C-states, memory frequency or timings. There is an option for whether the full-height mini-PCIe slot is mSATA or regular mini-PCIe, and users can choose to enable or disable Virtualization (VT-x; VT-d is not supported by the HM76 chipset).

The December 2013 firmware update provides users with the ability to pre-define how much memory to share with the IGP (128MB, 256MB or 512MB) which is reserved and unavailable to the OS. I believe previous firmware versions dynamically allocate VRAM based on the Intel IGP driver requests from the OS.

Depending on the workload the CPU temperature can vary from mid-40s to mid-70s (Celsius), but is almost never hotter. This is average for a mobile CPU and well within safe limits. The stock RAM hits mid-60s in heavy use, but DIMMs with 16 chips (as opposed to 8) run in the mid-70s.

CompuLab support was a little lacklustre at first, but improved tremendously after I discussed my issues with the MintBox product manager. They issued an RMA and replaced the unit to see if the compatibility issue was isolated, but the replacement has the same issues.

Overall the MintBox 2 is a very nice computer. The MintBox 2 is a fanless design, which is very nice from a noise perspective but certainly won’t win it any awards in the design department. The connectivity options are very nice, and exceed what other manufacturers are offering in a small form-factor fanless PC.

I was torn between buying a MintBox 2 and a Mac Mini. I liked the MintBox 2 connectivity options, even though it lacks ThunderBolt, and the fanless design was a bonus. The MintBox 2 also uses a lower TDP CPU than the Mac Mini (17W versus 35W), but is clocked lower.

If you want to buy a computer that works out of the box with Linux and don’t mind paying a premium for it, then the MintBox 2 is an excellent choice. However, the Mac Mini does give you more connectivity options (4xUSB 3.0, FW800 and ThunderBolt) and is compatible with almost all 16GB memory kits available on the market.

Pros:
+ Low-power
+ Fanless
+ I/O options without purchasing expensive adaptors
+ 5-year warranty
+ coreboot! (added December 2017)

Cons:
– Limited support for 16GB of RAM
– Limited I/O (no ThunderBolt)
– RMA requires shipping the unit to CompuLab’s US or Israel office which means about 2 weeks without your computer (as opposed to bringing the Mac Mini in to an Apple store and getting it fixed/replaced within a day or two)
– Multiple security vulnerabilities present in the system firmware (added July 2017)

Update: I installed the Corsair CT2CP102464BF1339 16GB kit and it seems to be working well in the MintBox. I also measured the power usage of the MintBox. At idle the MintBox draws 11W (110V mains) and under full load it draws around 27W.