It appears that Intel now has updates available:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
Tag: Intel
new CHIPSEC test for Xen XSA-188
Proof-of-concept module for Xen XSA-188 (https://xenbits.xen.org/xsa/advisory-188.html)
CVE-2016-7154: “use after free in FIFO event channel code”
Discovered by Mikhail Gorobets
This module triggers host crash on vulnerable Xen 4.4
Usage:
“chipsec_main.py -m tools.vmm.xen.xsa188“
https://github.com/chipsec/chipsec/blob/master/source/tool/chipsec/modules/tools/vmm/xen/xsa188.py
Intel Firmware Engine 2.1.1 for Windows released
U-Boot ported to Intel64
Simon Glass of Chromium posted a *82-part* patch to the U-Boot list, with a port of U-Boot from 32-bit x86 to 64-bit x64 support. Quoting Simon’s initial message:
[PATCH 00/82] x86: Add initial support for 64-bit U-Boot
At present U-Boot runs entirely in 32-bit mode on x86, except for the initial switch from 16-bit mode. On 64-bit machines it is possible to run in 64-bit mode. This series starts the process of adding this support. The main benefit of 64-bit mode for a boot loader is direct access to all available memory. There are also more registers, but this makes very little difference. This feature is implemented by putting all of the 32-bit code in an SPL build. SPL then runs through all the init that has to be done in 32-bit mode, changes to 64-bit mode and then jumps to U-Boot proper. Typically the total code size increases slightly. For example, on link in 32-bit mode, U-Boot has around 480KB of code (admittedly with a large number of features enabled). In 64-bit mode, U-Boot falls to around 460KB, but SPL adds another 60KB, for a net increase of 40KB. Partly this is due to code duplication and partly it is due to the worse code density of 64-bit code on x86. Many major features are not implemented yet, for example:
– SDRAM sizing
– Booting linux
– FSP support
– EFI support
– SCSI device init
– Running video ROMs
Still, this is a big step forward towards full 64-bit support. To enable it, select CONFIG_X86_RUN_64BIT. This series is available at u-boot-x86/64-working.
91 files changed, 1796 insertions(+), 705 deletions(-)
See full description in the post:
http://lists.denx.de/pipermail/u-boot/2016-September/267925.html
UEFI EDK2 Platform Proposal V2
Michael Kinney of Intel posted the V2 RFC for the EDK2 Platform Proposal, dealing with how to deal with repos and branches. Outline of changes and problem statement excerpted below, see the full proposal for much more details.
Changes from V1:
* edk2-platform is not a fork of edk2.
* edk2-platforms branches contain CPU, Chipset, SoC, and platform specific packages
* edk2-plaforms/master contains all open platforms that are synced with edk2/master.
* Each edk2-platforms branch may support many platforms (not just one)
* Use PACKAGES_PATH to do builds using packages from multiple repositories
* Update edk2-platforms branch naming to clearly identify platforms that are considered stable and platforms that are under active development.
* edk2 developers may be required to verify platforms in edk2-platforms builds as part of test criteria. Especially platforms that are intended to be used with edk2/master in edk2-platforms/stable-* branches.
Problem statement: Need place on tianocore.org where platforms can be maintained by the EDK II community. This serves several purposes:
* Encourage more platforms sources to be shared earlier in the development process
* Allow platform sources to be shared that may not yet meet all edk2 required quality criteria
* Allow platform source to be shared so the EDK II community may choose to help finish and validate
* Allow more platforms to be used as part of the edk2 validation and release cycle.
* Not intended to be used for bug fixes.
For more information, see the archives of the edk2-devel@lists.01.org list.
Update on Intel SMM updates
Regarding this:
Intel has revised it’s advisory with new dates. September 27th is the new date.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
Alex leaves Intel ATR!
Wow, Alex Matrosov is leaving Intel Advanced Threat Research (ATR).
As I understand it, he is one of the CHIPSEC team. I hope the project can handle his loss.
It is unclear what he’ll be doing next. Maybe he’ll be joining Apple? They are hiring all the great researchers…)
New UEFI Capsule Update and Recovery sample
Jiewen Yao of Intel checked in a *45-part* patch to the Tianocore project, adding a new UEFi Capsule sample and documentation!
This series patch provides sample on how to do signed capsule update and recovery in EDKII. The feature includes:
1) Define EDKII signed system BIOS capsule format.
2) Provide EDKII signed system BIOS update sample.
3) Provide EDKII signed recovery sample.
4) Provide Microcode update sample for X86 system.
5) Update Quark to use new capsule/recovery solution.
6) Update Vlv2(MinnowMax) to use new capsule/recovery solution.
The signed capsule/recovery solution is in MdeModulePkg. The capsule in IntelFrameworkModulePkg is deprecated. The Microcode update solution is in UefiCpuPkg.
124 files changed, 17848 insertions(+), 384 deletions(-)
For more info, see the full patch:
https://lists.01.org/mailman/listinfo/edk2-devel
.
UEFI EDK2 FDF V1.27 draft spec available
Laurie Jarlstrom of Intel announced the latest UEFI FDF spec: V1.27 Draft for Review.
“Please Review By EOW”.
I think I already saw an issue show up on the public EDK2 bug database.
EDK II FDF File Spec v1.27 DRAFT for Review
Update Sept 2016 (DRAFT)
This document describes the EDK II Flash Description (FDF) file format. This format was designed to support new build requirements of building EDK and EDK II modules within the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of current Unified EFI, Inc. (UEFI 2.6 and PI 1.4) compliant binary images. The FDF file is used to describe the content and layout of binary images. Binary images described in this file may be any combination of boot images, capsule images or PCI Options ROMs.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications
Update on Intel SMM vulnerability
Intel SMM EoP mitigations due Sep-19
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
Intel has a security advisory about SMM Elevation of Privilege vulnerability on multiple Intel product. It appears they have an estimated release for this: “Estimated Sept. 19th”
Severity rating: Important
Intel is releasing mitigations for a privilege escalation issue. This issue affects the UEFI BIOS of select Intel Products. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable function to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Other vendors’ products which use the common BIOS function SmmRuntime may be impacted. To find out whether a product you have may be vulnerable to this issue, please contact your system supplier. Intel highly recommends applying the mitigations. For Intel branded products where a mitigation is still pending, we recommend following good security practices including running with least privilege and keeping security software and operating systems up to date.
The advisory also shows how to use dmidcode on Linux to get the vendor ID:
dmidecode -t 0 | grep Version | awk -F : ‘{ print $2 }’ | sed s/\ //g
dmidecode -t 2 | grep Product | awk -F : ‘{ print $2 }’ | sed s/\ //g
More info:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr
New Intel/UEFI whitepaper: Establishing the Root of Trust
https://twitter.com/Intel_UEFI/status/773597835467956224
Click to access UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf
Vincent Zimmer and Michael Krau of Intel have written a new whitepaper for the UEFI Forum: “Establishing the root of trust”.
The first step in securing a computing device – from a simple embedded device to a supercomputer and everything in between – is to ensure that it can start up under the following conditions:
– It is operating as expected
– All the firmware needed to run the system is intact
– It has not been tampered with in any way
As described in the first white paper in this series, Understanding the Chain of Trust and Its Vital Role in Keeping Computing Systems Secure, the UEFI specification includes a mechanism for ensuring the integrity and security of firmware (the all-important link between the hardware and the operating system) as a system starts up. This mechanism is called Secure Boot and uses public key cryptography to validate that each piece of firmware has been digitally signed and is therefore unmodified as the system starts up. In a chain of trust, each piece of firmware must be digitally signed before it can start up. Once one piece of code has been validated, it can then validate the next section and so on until the system is fully booted and control handed over to the operating system. But how does that chain get started? While difficult, it would be possible for an attacker to inject malicious attack code of some sort prior to start of the chain of trust to gain low-level and nearly undetectable control over the system. To prevent this, the chain of trust requires a strong foundation. In modern systems, this is known as the root of trust. A root of trust, one that can be counted on to anchor the chain of trust in the face of the most determined attackers, can be established in a number of ways. The most secure approaches use some form of an unchangeable section of hardware to validate the initial keyed signature, but there are a number of effective approaches. Ultimately it comes down to the level of security you’re comfortable with and an understanding of the approach used to establish the root of trust. This white paper looks at several common methods for establishing a root of trust as the basis for the UEFI Secure Boot process. […]
Intel SGX tutorial part 4 to be released shortly
John M. of Intel has a new blog post with status on his next Intel SGX tutorial. Nice, it looks like there are many upcoming articles!
[…] Part 4 of the Intel Software Guard Extensions (Intel SGX) Tutorial Series will be coming out in the next few days. In it, we’ll be starting our enclave implementation, focusing on the bridge/proxy functions for the enclave itself as well as the middleware layer needed for the C++ code to interact with it. If you recall from the introduction, we are planning five broad phases in the series. With part 4 we complete our transition from the first phase, which focused on concepts and design, to the development and integration in the second. I want to take a few minutes to talk about what else is coming up and roughly where we are headed over the coming weeks. Part 5 will complete the development of the enclave. While part 4 is focused on the enclave interface layer and the enclave definition language (EDL), in part 5 we will code up the internals of enclave itself. In part 6, we’ll add support for dual code paths so that the application runs on hardware that is both Intel SGX capable and incapable. In a change from our original plan for the series, part 7 will look at power events (specifically, suspend and resume) and its impact on enclaves. After that, we’ll enter into the third phase of the tutorial which focuses on testing and validation. Here, we’ll demonstrate that Intel SGX is providing the expected security benefits. We’ll also look at tuning the enclave configuration to better match our usage. The final two phases, packaging and deployment, and disposition, will follow.
[…]
https://software.intel.com/en-us/blogs/2016/09/09/intel-software-guard-extensions-intel-sgx-tutorial-series-looking-ahead
https://software.intel.com/en-us/articles/introducing-the-intel-software-guard-extensions-tutorial-series
Intel Distribution for Python
Intel has a new Anaconda Python distribution, built with Intel libs to enhance speed/concurrency to help.
It is registration-required freeware if you download it from Intel. It mentions below that it might also be installable via Anaconda, unclear if registration is required for Anaconda. I’ve not found the source to this project yet, but I could’ve missed it.
https://software.intel.com/en-us/blogs/2016/09/08/intel-distribution-for-python
A few excerpts from their home page below:
Get up to 97 times faster numerical processing on SciPy stack: NumPy, SciPy, and scikit-learn boosted by the Intel® Math Kernel Library. Speed up data analytics with pyDAAL and parallelize Python workloads with enhanced Intel® Threading Building Blocks (Intel® TBB).
The all-included, out-of-the box distribution accelerates core Python packages including NumPy, SciPy, pandas, scikit-learn, Jupyter, matplotlib, and mpi4py. It integrates the powerful Intel® Math Kernel Library (Intel® MKL), Intel® Data Analytics Acceleration Library (Intel® DAAL) and pyDAAL, Intel® MPI Library, and Intel® Threading Building Blocks (Intel® TBB).
Multithreaded Python workloads can take advantage of multicore architectures from Intel using Intel TBB optimized thread scheduling and efficient communication with the Intel MPI Library.
Installing and managing your Python environment is made easy with the all-in-one installer from Intel or by installing packages from Anaconda Cloud using conda. Third-party packages can be installed with both conda and PIP.
Use the Intel® Distribution for Python powered by Anaconda as a drop-in replacement for your current Python environment to get high performance out of the box. Your Python applications immediately gain significant performance and can further be tuned to extract every last bit of performance using the Intel® VTune™ Amplifier.
The Intel® Distribution for Python is available for free for Python 2.7.x and 3.5.x on OS X*, Windows* 7 and later, and Linux*.
PS: Alas, this does not to appear to be integrated with Intel’s port of CPython to UEFI. 🙂
new Minnowboard variant
It sounds like this new Minnowboard Turbot Quad Core from ADI will be out in December for around $190.
“ADI Engineering announced an upcoming Quad Core varient of the MinnowBoard Turbot that will used the E3845 SoC. Compatible with the existing MAX and Turbots this brings a new level of performance to the SoC for those computationally expensive tasks.”
For more info, click on the G+ link in the above tweet, WordPress appears to discard G+-based URLs today.
From the Netgate pre-order page:
Improvements over MinnowBoard Turbot Dual Core
* Twice the core count. Higher clock speed.
* Over 2.5 times FASTER than the MinnowBoard Tubot dual core.
* Better Ethernet! This board has Intel i211 vs Realtek NIC.
* Fansink keeps it cool! Suitable for higher temp applications.
http://store.netgate.com/Turbot4.aspx
Nothing here yet AFAICT: http://minnowboard.org/
FFRI on CHIPSEC
FFRI have done a presentation on CHIPSEC:
Monthly Research 2016.7: About security assessment framework “CHIPSEC”
Click to access MR201607_About_security_assessment_framework_CHIPSEC_ENG.pdf
Intel Multi-byte NOP opcode made official
The latest version of IA-32 Intel Architecture Software Developers Manual Volume 2B: Instruction Set Reference, N-Z contains the opcode for a multi-byte NOP instruction. The opcode is
0F 1F mod-000-rm
The multi-byte NOP can have any length up to 9 bytes. Quite useful for alignment. […]
Ugh, how do you track changes like this? Diffing those PDFs? Is there any ‘changelog’ for things like this?
ftp://download.intel.com/design/Pentium4/manuals/25366719.pdf
https://software.intel.com/en-us/forums/watercooler-catchall/topic/307174
Intel SGX tutorial part3 published today
Thanks to John M. of Intel for noting on this blog that part 3 of his tutorial is now available:
https://software.intel.com/en-us/articles/software-guard-extensions-tutorial-series-part-3
“In Part 3 of the Intel® Software Guard Extensions (Intel® SGX) tutorial series we’ll talk about how to design an application with Intel SGX in mind. We’ll take the concepts that we reviewed in Part 1, and apply them to the high-level design of our sample application, the Tutorial Password Manager, laid out in Part 2. We’ll look at the overall structure of the application and how it is impacted by Intel SGX and create a class model that will prepare us for the enclave design and integration.”[…]
The SMM Rootkit Revisited: Fun with USB (from ARES’15)
http://ieeexplore.ieee.org/document/6980293/?reload=true&arnumber=6980293
System Management Mode (SMM) in x86 has enabled a new class of malware with incredible power to control physical hardware that is virtually impossible to detect by the host operating system. Previous SMM root kits have only scratched the surface by modifying kernel data structures and trapping on I/O registers to implement PS/2 key loggers. In this paper, we present new SMM-based malware that hijacks Universal Serial Bus (USB) host controllers to intercept USB events. This enables SMM root kits to control USB devices directly without ever permitting the OS kernel to receive USB-related hardware interrupts. Using this approach, we created a proof-of-concept USB key logger that is also more difficult to detect than prior SMM-based key loggers that are triggered on OS actions like port I/O. We also propose additional extensions to this technique and methods to prevent and mitigate such attacks.
CaptainHook
CaptainHook is hooking framwork for x86/x64 arch, it’s based on capstone disassembler engine. CaptainHook equipped with smart engine (TO FINISH). CaptainHook is easy to using, and very freandly. the hook engine is much like MS Detours, so why to choose it?
* its support x64 (Detours x64 is commerical – $10,000~)
* CaptainHook will know where to locate your hook in real time, its analyze the code, and find if small API redirection (Wow64 hook on kernelbase for example, or on protector like VMP or Themida) was occurred
* in the next release, CaptainHook will contain an engine for jmp/conditional jmp repair – if your hook corrupt sensitive code
* in the next release, CaptainHook will contain more hook type, like PageGuard hooking etc.
[…]
ACPICA shipping acpidump.efi
In recent news on the ACPICA site is:
“AcpiDump for UEFI is now available at Downloads/uefi-support – 26 August, 2016 – 13:57”
The tool acpidump now targets UEFI, in addition to OSes. In addition to shipping source via Github, they ship a zip with prebuilt Intel 32- and 64-bit .efi binaries, no ARM binaries.
https://github.com/acpica/acpica/tree/master/source/tools/acpidump
https://acpica.org/downloads/uefi-support
If there is a place where the above web site’s ‘recent news’ is delivered via RSS or Atom or Twitter or NNTP or some announce mailing list or even Facebook, please leave a Comment. I think I’m not on the right ACPI list or something… Thanks.
Firmware Security 
You must be logged in to post a comment.