Tag Archives: intensepc

coreboot for CompuLab Intense PC

I am very pleased to announce that coreboot now supports the CompuLab Intense PC and MintBox 2! ??


Building coreboot
The instructions for building coreboot yourself can be found on the coreboot Wiki. You will need a Linux system with typical development packages installed such as build-essential.

Select CompuLab and Intense-PC in the Mainboard section of the coreboot menuconfig:

You need to decide at this point whether you wish to use the internal full-height PCI-Express slot for mSATA or as PCI-Express:

If you have not installed an additional mSATA SSD in your Intense PC, then you do not need to select this option. Selecting the mSATA option is only required if you have installed an mSATA SSD and want to use it in the Intense PC:

Because coreboot does not have full support for the embedded controller (EC) in the Intense PC right now, the choice of using mSATA or PCIe cannot be made at runtime. If later you wish to change the function of the slot, you need to rebuild coreboot while selecting the appropriate choice of mSATA or PCIe.

Note that the mSATA port is limited to SATA 3Gbps speeds. This is a hardware limitation of the Intense PC design, and cannot be changed by flashing coreboot.


It is important to include the Firmware Descriptor Table (FDT), ME, and GbE regions of flash. Specify these files in the Chipset section:

You can choose yourself if you want to run me_cleaner on the ME or not. Note that if you choose to run me_cleaner, all SATA ports will cease to function. This is not a coreboot specific bug, the same behaviour occurs on the CompuLab firmware when me_cleaner is run. It may or may not be possible to fix this issue, more research is needed to understand the root cause.


If you want to have video during POST, you also need to include the Intel VGA BIOS in the image. Specify this in the Devices section:

In theory coreboot graphics init is supposed to initialize the Intel HD graphics without the need for the VGA BIOS, however without the VGA BIOS I was unable to get any video output until the Linux kernel started booting. This makes using the bootloader menu or troubleshooting pre-boot issues very difficult.


I would recommend you enable logging to cbmem at a minimum. This will allow you to access the coreboot boot log in Linux using the cbmem utility. If you have trouble booting the Intense PC after flashing coreboot, I would recommend you enable logging to UART, and use the included serial dongle to debug coreboot via RS-232 (115200n8). UART support for the Intense PC should be accepted to coreboot master shortly.


The default boot order of SeaBIOS seems to be SATA HDD if present, then PXE boot (if compiled with iPXE). It is possible and easy to change this, by specifying a bootorder file to include in cbfs when building coreboot.

I have created a boot order file which searches for boot devices in the following order:

  1. USB 2.0 devices
  2. USB 3.0 devices
  3. SATA devices (in order: 2.5″ internal, mSATA, eSATA, FACE module)
  4. iPXE

You can download the bootorder file and include it in cbfs. If you don’t include iPXE as a payload, remove the last line of the bootorder.txt file. If you are not building SeaBIOS as a payload, then you do not require this file.


After building coreboot, but before flashing, we need to split the coreboot.rom file into two 8MB files. This is because the Intense PC has two 8MB NOR flash chips totaling 16MB.

Split the coreboot.rom file into two 8MB files “SC1.bin” and “SC2.bin” using dd:
$ dd if=build/coreboot.rom of=SC1.bin bs=1M count=8
$ dd if=build/coreboot.rom of=SC2.bin bs=1M skip=8


Extracting binary firmware components
You may notice above that several portions of the initial Intense PC firmware are required to successfully build coreboot. The Intel Descriptor file (otherwise known as the Flash Descriptor Table or FDT), Management Engine firmware, Gigabit Ethernet region, and VGA BIOS.

If you have not yet installed the CompuLab firmware update to address CVE-2017-8083, you should be able to dump the entire firmware using flashrom in Linux:
# flashrom -p internal:laptop=force_I_want_a_brick -r intense_pc.bin

If you have already patched your system, then flashrom will be unable to dump the firmware:
Enabling flash write... Warning: SPI Configuration Lockdown activated.
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00003000-0x00cfffff) is locked.

You will have to use a hardware method to dump the firmware from the chips. As an example, using a ch341 based SPI programmer and flashrom:
# flashrom -p ch341a_spi -r sc1.bin
# flashrom -p ch341a_spi -r sc2.bin

Confirm that sc1.bin contains the start of the flash descriptor:
$ hexdump -C sc1.bin | head -2
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000010 5a a5 f0 0f 03 01 04 03 06 02 10 12 20 01 21 00 |Z........... .!.|

Do not forget to concatenate the firmware together into a 16MB image before running ifdtool:
$ cat sc1.bin sc2.bin > intense_pc.bin

You can then extract the regions from the firmware using ifdtool (included in coreboot/utils):
$ ifdutil -x intense_pc.bin

The output of ifdtool should appear as follows:
File intense_pc.bin is 16777216 bytes
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00d00000 - 00ffffff
Flash Region 2 (Intel ME): 00003000 - 00cfffff
Flash Region 3 (GbE): 00001000 - 00002fff
Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)

ifdtool will output files for each flash region. For building coreboot, we are interested in the following regions:
flashregion_0_flashdescriptor.bin
flashregion_2_intel_me.bin
flashregion_3_gbe.bin


If ifdtool doesn’t work for some reason, verify that you have concatenated the firmware files in the correct order. Or, if you don’t want to use ifdtool, you can split it manually using dd.

Intel Descriptor file/FDT:
$ dd if=intense_pc.bin of=descriptor.bin bs=4096 count=1

Management Engine:
$ dd if=intense_pc.bin of=me.bin bs=4096 count=1028 skip=3

Gigabit Ethernet region:
$ dd if=intense_pc.bin of=gbe.bin bs=4096 count=2 skip=1


You can extract the VGA BIOS from within Linux. First, verify the PCI ID of the Intel integrated graphics controller. On the Intense PC, this should be 00:02.0:
$ lspci | grep Graphics
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)

Once you have confirmed the PCI ID, you can dump the VGA BIOS to a file:
# echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
# cat /sys/devices/pci0000:00/0000:00:02.0/rom > vgabios.bin
# echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom

vgabios.bin should be exactly 65536 bytes and begin similar to the following:
$ hexdump -C vgabios.bin | head -2
00000000 55 aa 78 e9 b8 e9 30 30 30 30 30 30 30 30 30 30 |U.x...0000000000|
00000010 30 30 90 24 e9 a9 23 a0 40 00 b0 0a 30 30 49 42 |00.$..#[email protected]|

It is recommended to also dump the video bios table (VBT) to a file to include in cbfs, as the VBT table is expected by Windows:
# cat /sys/kernel/debug/dri/0/i915_vbt > vbt.bin

vbt.bin should be exactly 6144 bytes and look similar to the following:
$ hexdump -C vbt.bin | head -2
00000000 24 56 42 54 20 53 4e 42 2f 49 56 42 2d 4d 4f 42 |$VBT SNB/IVB-MOB|
00000010 49 4c 45 20 64 00 30 00 b8 10 e7 00 30 00 00 00 |ILE d.0.....0...|


Flashing coreboot

The following instructions are provided AS-IS and with no warranty, express or implied. Flashing coreboot can turn your computer into a brick and will void your warranty. By following these instructions you acknowledge these risks and assume all liability.

To flash coreboot onto your Intense PC, you will need an SPI programmer supported by flashrom.

An inexpensive option is a CH341 based SPI programmer (<$2 USD from eBay/AliExpress):

Another useful tool which can also be used for flashing is the Bus Pirate (~$25 USD):

The Raspberry Pi should also work. Here is a detailed post on how to use the Raspberry Pi to flash firmware to a NOR flash.

Unfortunately for us, the NOR flash in the Intense PC is in a WSON package (very very thin small outline no lead package) so a SOIC clip or SOIC socket will not work.

Because the Intense PC uses the chassis as a heat sink, you need to remove the motherboard from the Intense PC chassis to access the NOR flash. To do this, first remove the hard drive and hard drive carrier secured by a single screw:

Next, remove the 4 screws securing the bottom plate to the chassis:

Next, remove the retaining screw of the FACE module:

Next, remove the screw and two stand-offs securing the motherboard to the chassis. The screw is by the Ethernet ports, and the two stand-offs: one near the audio ports and one under the FACE module:

Disconnect the WiFi antennas (if installed) and disconnect the front panel connector near the SODIMM sockets. You should now be able to lift the motherboard out of the chassis.

You will find the two NOR flash modules on the reverse side of the motherboard:

You will need to solder connections to the pads beside each chip to back up the original firmware and to flash coreboot.

If you’re using the ch341 based programmer, then the flashrom commands would be the following:
For the NOR flash near SC1: $ sudo flashrom -p ch341a_spi -w SC1.bin
For the NOR flash near SC2: $ sudo flashrom -p ch341a_spi -w SC2.bin


Conclusion
If you value open-source software and want an alternative to the closed-source and infrequently updated CompuLab firmware, then coreboot is a great choice for the Intense PC/MintBox 2.

However building and flashing coreboot on the Intense PC is not without its risks. You will void your warranty and specialized equipment such as a soldering iron and SPI flashing tool are required.

I was disappointed to find multiple vulnerabilities in CompuLab’s Intense PC firmware. These serious vulnerabilities and CompuLab’s rather lackluster response inspired me to port coreboot to the Intense PC.

I am not an expert on the inner workings of the x86 platform and boot process, so I could not have successfully completed this port without the assistance of the excellent autoport tool.


Coreboot advantages

  • ?Open-source firmware?
  • Better memory (RAM) compatibility than the CompuLab firmware
  • Memtest86+ and iPXE can be included as a payload in flash
  • Verified boot supported via vboot

Limitations

  • VBIOS is required if you want any video output before the kernel framebuffer is initialized
  • VGA hand-off to Windows is still not working
  • ME firmware is still necessary for most users as me_cleaner breaks SATA
  • Currently no easy path to support UEFI
  • No FACE modules except for the included 4 port USB2.0 FACE module (FM-4USB) are supported (due to lack of additional FACE modules to test)

Please note that due to copyright concerns I cannot distribute binary firmware components such as the ME firmware or video BIOS. Additionally, for technical reasons I cannot provide a fully built, flashable coreboot image for your Intense PC. This is the reason for the “Extracting binary firmware components” section of the article.

If you experience issues building or using coreboot, please leave a comment or subscribe to the coreboot mailing list and ask your question there.

The coreboot project and I make no guarantee these instructions and the resulting firmware won’t turn your system into a fancy brick. The instructions produce a bootable firmware on my hardware (MintBox 2) at the time of writing, although this could change at some point in the future.

Please exercise caution and common sense when modifying system firmware and ensure you always have a backup of the original firmware on another device should something go wrong.

CVE-2017-9457: CompuLab Intense PC lacks firmware signature validation

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

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

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.