Intel updates Firmware Engine

https://twitter.com/FirmwareEngine/status/735564887267500032

Intel® Firmware Engine Release 2.0.0
Program installer for Microsoft* Windows 7/8/8.1/10.
Includes program and MinnowBoard Max and MinnowBoard Turbot platform support.

https://firmware.intel.com/learn/intel-firmware-engine/downloads

<soapbox>
Intel: please port Firmware Engine to Linux (and FreeBSD, which also has UEFI support), the current Windows-only release only helps Windows subset of your target firmware vendor ecosystem. Thanks!
</soapbox>

Petition for Intel to build a no-ME system

Here is where to sign:
https://puri.sm/posts/petition-for-intel-to-release-an-me-less-cpu-design/

I hope someone does a petition to get the Stateless Laptop built. If Intel builds a new ME-less system, it should also be building this Stateless system as part of it.

http://blog.invisiblethings.org/2015/12/23/state_harmful.html

AND… I don’t understand why OEMs are dancing around with tamper resistant screws. IMO, a system needs a lock, a good one, since lockpicking is a normal hacker sport, most locks are useless. A good laptop should have a lock to prevent casual evil maids. The Google Chromebox Pixel Developer Mode scew is nice, but an evil maid could also use that, no lock. Cars have locks. Houses have locks. Computer server rooms have locks. Data contained in laptops are often worth more than cars and houses. Why do modern expensive computers have no locks? Cost? Governments would not want them, harder to access boxes going through customs? I want a Stateless Laptop, with a secure metal enclosure and a good quality lock. Then I’ll keep the key and thumbdrives with me, and just deal with rubberhose attacks, not evil maid attacks.

PTSecurity on Disabling Intel Management Engine

N3mes1s points out an article from Maxim Goryachy and Mark Ermolov of PTSecurity, on disabling the Intel Management Engine (ME).

http://ptsecurity.com
https://github.com/ptresearch/

Click to access How%20to%20become%20the%20sole%20owner%20of%20your%20PC.pdf

HackBGRT: changes Windows boot logo on UEFI systems

Metabolix has written HackBGRT, a tool that changes the Windows boot logo on UEFI systems. It works on Intel 64-bit UEFI systems, with Secure Boot disabled.

“HackBGRT is intended as a boot logo changer for UEFI-based Windows systems. When booting on a UEFI-based computer, Windows may show a vendor-defined logo which is stored on the UEFI firmware in a section called Boot Graphics Resource Table (BGRT). It’s usually very difficult to change the image permamently, but a custom UEFI application may be used to overwrite it during the boot. HackBGRT does exactly that. Important: If you mess up the installation, your system may become unbootable! Create a rescue disk before use. This software comes with no warranty. Use at your own risk.” […]

https://github.com/Metabolix/HackBGRT

DarkReading article on firmware protection

Yuriy and John of the Intel CHIPSEC team are quoted in a new Dark Reading article on firmware security.

[…] Yuriy Bulygin and John Loucaides, security researchers at Intel Security, point out that hackers attack firmware because they know many security and IT managers aren’t paying attention to it. They say security teams are so overwhelmed by the prevailing threat landscape, that they have their hands full just deploying the basics, like firewalls, intrusion prevention systems and sandboxes. […]

http://www.darkreading.com/iot/5-tips-for-protecting-firmware-from-attacks/d/d-id/1325604

UFS Erase Block command added to UEFI

Hao Wu of Intel added Erase Block support to UFS (Universal Flash Storage) devices. Since UFS uses SCSI model in UEFI, the SCSI Unmap command was also added, but SCSI Unmap is not fully-implemented for SCSI devices, only for UFS Erase Block support.

[PATCH 0/2] Add Erase Block Protocol support for UFS devices

This patch series add the Erase Block Protocol implementation for UFS devices. Since the UFS transport layer follows the SCSI architecture, therefore, the implementation is added in the ScsiDiskDxe driver.

MdePkg IndustryStandard/Scsi.h: Add Unmap command support
MdeModulePkg ScsiDiskDxe: Add Erase Block Protocol support for UFS devices

For more information, see the patch on the EDK2-devel list, see the UFS 2.0 spec (including section 11.3.9.2). Hmm, unless I’m misreading things, the UFS spec is for members only, not public. 😦

https://lists.01.org/mailman/listinfo/edk2-devel
http://news.gmane.org/gmane.comp.bios.edk2.devel
http://search.gmane.org/search.php?group=gmane.comp.bios.edk2.devel&query=UFS
https://en.wikipedia.org/wiki/Universal_Flash_Storage

Universal Flash Storage (UFS) support added to UEFI

IPMIPWN

IPMIPWN came out 2 months ago and I missed it. 😦 IPMIPWN’s readme excerpt:

IPMI cipher 0 attack tool

There are a few good tools out there (Metasploit) to help you find and identify the IPMI cipher 0 vulnerability, but because its relatively trivial to exploit I have seen nothing that helps you pwn it. While it is easy to exploit, I have found I keep having to brush up on commands and junk every time I come across it which is where my tools comes in. My IPMIPWN tool does all the real work for you, it will attempt to exploit the cipher 0 vulnerability using a list of predefined default user accounts and setup an backdoor account with a semi-random username and random password. All successful backdoors are logged in loot.log. This tool works best on Kali, it does require you to have ipmiutils “apt-get install ipmitool” and NMAP installed. Enjoy.
https://github.com/AnarchyAngel/IPMIPWN

Besides IPMIPWN, and Metasploit, the tools FreeIPMI and IPMItool are also worth checking out. There is an IPMI Util  tool for Windows, and an Intel IPMI tool for MS-DOS, both of which I have not tried out.
https://sourceforge.net/projects/ipmitool/
http://www.gnu.org/software/freeipmi/
http://ipmiutil.sourceforge.net/
http://www.intel.com/design/servers/ipmi/ipmi_tool.htm

If you are new to IPMI security, start here:
https://www.us-cert.gov/ncas/alerts/TA13-207Ahttps://search.us-cert.gov/search?utf8=%E2%9C%93&affiliate=us-cert&query=IPMI&commit=Search
https://community.rapid7.com/community/metasploit/blog/2013/07/02/a-penetration-testers-guide-to-ipmi
http://fish2.com/ipmi/
http://www.cisco.com/c/en/us/about/security-center/ipmi-vulnerabilities.html

Intel OpenCIT 2.0.7 released

Adolfo V Aguayo of Intel announced the 2.0.7 release of OpenCIT  (Open Cloud Integrity Technology) library. The first time I’ve heard of OpenCIT, and they’re already at a 2.x release. 😦 Excerpted announcement:

Open CIT is the next generation attestation solution.  Open CIT provides features and capabilities in its entirety, as was made available in the Premium version, including support for ESX and Citrix-Xen, in addition to KVM on Ubuntu and RHEL.  Open CIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters.  The solution leverages Intel processors with Intel® Trusted Execution Technology (Intel® TXT) to establish HW root of trust and builds the chain of trust across hardware, OS, hypervisor and including asset tagging for Location and boundary control.  The Platform trust and asset tag attestation information is used by Orchestrators and/or Policy Compliance management to ensure workloads are launched on trusted and location/boundary compliant platforms, and they provide the needed visibility and Auditability of your infrastructure in both public and private cloud environments.

We are proud to announce the release of Open CIT. Open CIT provides features and capabilities in its entirety, as was made available in the Premium version, including support for ESX and Citrix-Xen, in addition to KVM on Ubuntu and RHEL.  OpenCIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters. Below are the key features for Open CIT:
– Establish chain of trust of BIOS, firmware, OS kernel & hypervisor by verifying against configured good known values (Whitelists)
– Ability to tag/verify hosts with custom attributes (Asset Tags) stored in TPM. Ex: Location attributes
– Open Stack integration to utilize Platform Trust and asset tags for advanced VM management
– Mutual SSL authentication supported across all the communication channels.
– RESTful API interface for easier 3rd party integration
– Audit logging for all changes including tracking of the host trust status changes
– Self-extracting installers for ease of setup & Reference UI portal
– User defined TLS policy management for host’s connections.

Distributions currently supported and the Open Stack version used for our extensions:
– Linux distributions: Ubuntu 12.04 LTS, 14.04 LTS, RHEL 6.5 and 7.x, on KVM
– OS platforms that are supported for remote attestation: Citrix XenServer 6.2, VMWare ESXi 5.5, 6, Ubuntu 12.04 LTS, 14.04 LTS, RHEL 6.5 and 7.x,
– Open Stack extensions supported: Kilo & Liberty.

https://github.com/opencit
https://01.org/opencit

For more information, see the OAT-devel post:
https://lists.01.org/mailman/listinfo/oat-devel

Intel SGX talk at VirusBulletin

The antivirus-centric conference VirusBulletin is happening this October, and there’s an Intel SGX talk on the agenda:

Trusted Code Execution on Untrusted Platform Using Intel SGX
Prof. Guevara Noubir (Northeastern University)
Amirali Sanatinia (Northeastern University)

Today, isolated trusted computation and code execution is of paramount importance to protect sensitive information and workflows from other malicious privileged or unprivileged software. Intel Software Guard Extensions (SGX), is a set of security architecture extensions introduced in the Skylake microarchitecture that enables a Trusted Execution Environment (TEE). It provides an ‘inverse sandbox’, for sensitive programs, and guarantees the integrity and confidentiality of secure computations even from the most privileged malicious software (e.g. OS, Hypervisor). SGX-capable CPUs only became available in production systems in Q3 2015, however they are not yet fully supported and adopted in systems. Besides the capability in the CPU, the BIOS also needs to provide support for the enclaves, and not many vendors have released the required updates for the system support. This led to many wrong assumptions being made about the capabilities, features, and ultimately dangers of secure enclaves. By having access to resources and publications such as white papers, patents and the actual SGX-capable hardware and software development environment, we are in a privileged position to be able to investigate and demystify SGX. In this paper, we first review the previous Trusted Execution technologies, such as ARM Trust Zone and Intel TXT, to better understand and appreciate the new innovations of SGX. Then we look at the details of SGX technology, cryptographic primitives and the underlying concepts that power it, namely the sealing, attestation, and the Memory Encryption Engine (MEE). Then we look at the use cases such as trusted and secure code execution on an untrusted cloud platform, and Digital Rights Management (DRM). This is followed by an overview of the software development environment and the available libraries.

https://www.virusbulletin.com/conference/vb2016/abstracts/trusted-code-execution-untrusted-platform-using-intel-sgx

https://www.virusbulletin.com/conference/vb2016/programme

EDK2 fork for LLVM security analysis

Steven Shi of Intel\SSG\STO\UEFI Firmware has created an LLVM Clang-centric fork of the EDK2 project. The EDK2 project already supports LLVM clang alongside GCC and ICC and MCS, but this fork appears to be taking advantage of some of LLVM’s security features, like Clang’s Static Analyzer, “special checkers for edk2 security” sounds interesting!

Hello,
I forked a edk2 branch to apply the LLVM compiler and tool chain technologies (http://www.llvm.org/) on the edk2 codebase in below link. If you are also interested in the LLVM/Clang support, please take a look. I welcome and appreciate any feedback or contribution to this branch.

https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm

So far, this branch focus on below items:
* Clang compiler optimization for edk2 code size improvement, e.g. Link Time Optimization (LTO)
* Clang Static Analyzer (scan-build) for edk2, e.g. special checkers for edk2 security, checkers for Intel Firmware Engine automation

There are 4 new tool chains are introduced in branch llvm:
* CLANG38: Clang3.8.0 build tool chain, and enable code size optimization flag (-Os) by default on both Ia32 and X64.
* CLANGLTO38: Base on CLANG38 to enable LLVM Link Time Optimization (LTO) for more aggressive code size improvement.
* CLANGSCAN38: Base on CLANG38 to seamlessly integrate Clang scan-build analyzer infrastructure into edk2 build infrastructure.
* GCCLTO53: Enabled GCC Link Time Optimization (LTO) and code size optimization (-Os) for more aggressive code size improvement.

There are several known issues as below. WELCOME and APPRECIATE any suggestion to them:
* Not use gold linker for now, but directly use standard ld. GNU gold linker ld-new (GNU Binutils 2.26.20160125) 1.11 fails to link edk2 static library file (*.dll) with error message: “ld: internal error in do_layout, at ../../binutils-2.26/gold/object.cc:1819” Have submitted a bug in Bug 20062 – Gold2.26 fail to link Uefi firmware with internal error in do_layout, but ld works (https://sourceware.org/bugzilla/show_bug.cgi?id=20062)
* CLANG LTO optimization (on ld, not on gold) can generate incorrect code. Current CLANGLTO38 LTO X64 debug build will generate wrong code for BasePrintLib.inf and LzmaCustomDecompressLib.inf modules, and the Ovmf boot will hang in these two modules. Already add work around to disable the lto optimization in these two modules’ inf files. Please see the log of commit 6a55aa9c3fa58f275041bf8cda138643f04baf5c
* GCC LTO optimization can generate incorrect code. Current GCCLTO53 is even worse than CLANGLTO38, and there are more modules need to disable the LTO optimization to work around the CPU exceptions during boot time.

For more info, see the patch on the edk2-devel list:
https://github.com/shijunjing/edk2
https://github.com/shijunjing/edk2/tree/llvm
https://lists.01.org/mailman/listinfo/edk2-devel

I wonder if this project is related to the Intel LLVM KLEE/S2E static analysis project that they are hopefully going to open source this year?

Intel firmware security research at WOOT

I hope they take the handful of metrics that William’s LangToolUEFIZBIOS(sp) — his grad project — did. It’ll be a lot simpler as a LLVM filter, no need for all the Java ANTLR code!

Two UEFI Form tools, plus one UEFI C Module complexity tool

Debian drops Intel 486/586 support for i386 target

Ben Hutchings announced a policy change at Debian, i386 must now be 686-class processors:

Debian i386 architecture now requires a 686-class processor:

Last year it was decided to increase the minimum CPU features for the i386 architecture to 686-class in the stretch release cycle.  This means dropping support for 586-class and hybrid 586/686processors.(Support for 486-class processors was dropped, somewhat accidentally, in squeeze.) This was implemented in the Linux kernel packages starting with Linux 4.3, which was uploaded to unstable in December last year. In case you missed that change, gcc for i386 has recently been changed to target 686-class processors and is generating code that will crash on other processors.  Any such systems still running testing or unstable will need to be switched to run stable (jessie). The older processors will continue to be supported in jessie until at least 2018, and until 2020 if i386 is included in jessie LTS.

[1] The following processors, supported in jessie, are now unspported:

* AMD K5, K6, K6-2 (aka K6 3D), K6-3
* DM&P/SiS Vortex86, Vortex86SX
* Cyrix III, MediaGX, MediaGXm
* IDT Winchip C6, Winchip 2
* Intel Pentium, Pentium with MMX
* Rise mP6
* VIA C3 ‘Samuel 2’, C3 ‘Ezra’

True, this is not firmware-centric, but Debian is pretty upstream when it comes to embedded Linux systems…

For more info, see the full post on the debian-devel-announce list:

https://lists.debian.org/msgid-search/1462623810.19332.46.camel@decadent.org.uk

List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

AMD
AMI
Apple
Dell
Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Lenovo
Microsoft
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

http://uefi.org/security

Intro to Intel SGX Sealing

https://twitter.com/intelswfeed/status/727993359516745729

Alexander B. of Intel has written a blog post describing the Sealing abilities of Intel SGX:

Introduction to Intel® SGX Sealing:
This post is intended to introduce developers to the Sealing capability available on SGX enabled platforms. Sealing is the process of encrypting enclave secrets for persistent storage to disk. This allows secrets to be retrieved if the enclave is torn down (either due to power event or by the application itself), and subsequently brought back up. Encryption is performed using a private Seal Key that is unique to that particular platform and enclave, and is unknown to any other entity. […] For a more detailed treatment of SGX sealing capabilities, refer to the following documents: […]

Full post:
https://software.intel.com/en-us/blogs/2016/05/04/introduction-to-intel-sgx-sealing
https://software.intel.com/en-us/sgx

 

More on Intel FSP

First, Vincent replied to my last FSP post with an URL to another FSP-related spec, the Boot Setting File (BSF) spec, see the comments here:

Intel FSP 2.0

Click to access BSF_1_0.pdf

Second, Vincent has two posts of his own on FSP, I may’ve blogged about one, but I believe the other one is new, there’s a lot of new FSP links to start learning…:

http://vzimmer.blogspot.com/2016/04/open-source-platforms-fsp-consumers-fsp.html

https://firmware.intel.com/blog/open-source-platforms-edkii-using-intel-fsp

 

update on Atom’s demise: Minnow’s swim on

It appears that the Minnows may be spared from the recent news of Atom’s demise, see the below comments from Intel on the subject:

http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20160502/002239.html

 

https://plus.google.com/+MinnowboardOrg/posts/CBGiLXRexxt