McAfee Labs
2016 Threats Predictions
Intel Security: A five-year look ahead
http://www.mcafee.com/us/mcafee-labs.aspx

Twenty-one thought leaders from Intel Security collaborated to produce this look ahead at how the cybersecurity marketplace and actors are likely to evolve. […]

There are two sections in the document that focus on hardware/fimware security, search for the “Security on Silicon” and “Hardware” sections. A few brief experts:

We currently see only miniscule amounts of malware that target hardware or firmware vulnerabilities, but that is going to change during the next five years. We expect to see many groups leveraging newly discovered techniques, sharing what they know as they try to build effective attacks. Much of this will trickle down, from advanced nation-state intelligence and defense agencies, through big organized crime syndicates, and into broader use. Hardware and firmware protections such as secure boot, trusted execution environments, tamper protection, cryptographic acceleration, active memory protection, and immutable device identity make it more difficult for these attacks to gain a foothold, as well as easier to detect and correct them.

System firmware-based attacks pose a critical risk when coupled with the cloud or with cloud service providers. In 2015, the Intel ATR team demonstrated how to gain access to adjacent virtual machines through multiple vectors, including firmware rootkits or simple misconfigurations. Threats similar to the S3 Boot Script attack can be adapted for in-the-wild attacks. In many cases, it is just a matter of exploiting simple misconfigurations in UEFI or BIOS.

Going forward, we must be hyperaware of the system components below the operation system and how those components can be exploited or leveraged for attack. Available controls for under the operating system attacks include tools like CHIPSEC, and technologies like Intel’s Kernel Guard Technology (iKGT) and Intel BIOS Guard.

I wish that last paragraph mentioned ITL’s Stateless Laptop as one of the solutions.

Hmm, Why are there only BIOS and UEFI attacks mentioned? Where are the coreboot and U-Boot attacks? Are all listed firmware attacks against legacy BIOS systems and UEFI systems, not coreboot or U-Boot attacks? Intel spends resources on both UEFI as well as coreboot, so it seems strange to only see UEFI mentioned in their security. U-Boot also supports Intel these days, apparently without Intel’s involvement. So I’d hope to see a bit of coverage of both coreboot and prehaps a bit of U-Boot.

Is this because firmware attacks are being focused on Windows systems, not Chrome systems, due to marketshare numbers or expertise of attackers/researchers? I recall seeing some news recently claiming that Chrome PCs now outnumber Windows PCs.

Maybe because CHIPSEC only only targets Intel x86/x64 BIOS/UEFI systems, not coreboot/U-Boot systems, or ChromeOS systems, or ARM/AMD/MIPS/Itanium/other architectures, and if CHIPSEC is the only modern firmware vulnerability analysis tool, then lack of tools keeps these other systems’ security profiles dark? Why is AMD not porting CHIPSEC to AMD64, as well as the other handful of x86-compatible vendors?

Why is ARM not porting CHIPSEC to AArch32, only AArch64, and what is status of port, it was mentioned months ago but no status on final port. Once CHIPSEC’s C/asm/Perl userland and C/asm kernel HAL are ported to new arch, and Intel-centric stuff is ifdef’ed out, CHIPSEC still needs new chip-centric security tests added, and I don’t see anyone from ARM/Linaro doing this, so their port will be a gutted empty CHISPEC, not useful without new tests. Where is the ARM report mentioning the lack of CHIPSEC is a huge issue to enterprises ability to protect ARM systems?

Maybe ChromeOS + coreboot’s Verified Boot results in more secure systems than UEFI? Windows systems are UEFI and optional closed-source IBV-based BIOS, if Legacy Mode present. Chrome systems are coreboot and open-source SeaBIOS-based BIOS.

I’m glad Intel provides this kind of white papers. I wish AMD and ARM and other architecture vendors would also offer similar reports. I really wish there was some research on this from a neutral vendor, not a not a chip vendor, so we could see balanced coverage of Intel, AMD, ARM, OpenPOWER, and other systems, and their firmware, covered, including peripheral security (PCIe, NVMe, Thunderbolt, USB, etc. Doesn’t NIST have a hardware/firmware group? I wish they generated a HW/FW periodic security report. It could have the perspective to scope discussion to include trusting closed-source blobs, resident -vs- nonresident firmware solutions and their attack vectors, comparison’s of silicon and firmware (eg, Verified -vs- Secure boot) solutions, and most importantly not just solutions from a single vendor.