Advisory Category: Software
Impact of vulnerability: Information Disclosure
Severity rating: MEDIUM
Original release: 12/05/2018
A potential security vulnerability in Intel® IPP may allow information disclosure. Intel is releasing software updates to mitigate this potential vulnerability. Data leakage in cryptographic libraries for Intel(R) IPP before 2019 update1 release may allow an authenticated user to potentially enable information disclosure via local access. Intel recommends that users of Intel® IPP update to 2019 update1 or later. Updates are available for download […] Intel would like to thank an Wichelmann (Universität zu Lübeck), Ahmad Moghimi (Worcester Polytechnic Institute), Thomas Eisenbarth (Universität zu Lübeck) and Berk Sunar (Worcester Polytechnic Institute) for reporting this issue and working with us on coordinated disclosure.
SUPPORTED (NEW) FEATURES AND CHANGES IN RELEASE:
1. The 64bit BIOS is now functional with Linux and Windows 8.1 Embedded/Windows 10.
2. The 32bit BIOS is now functional with Windows 8.1 Embedded/Windows 10.
3. Supports booting from "SD card", "USB drive" and "SATA".
4. Supports S3 resume for Linux, Windows 8.1 Embedded and Windows 10.
5. Supports S4 resume for Windows 8.1 Embedded and Windows 10.
6. Supports 64bit image GCC build (32bit image GCC build is not supported).
7. Update EDK II core from UDK2015 release to UDK2017.
8. Signed Capsule Update is supported.
9. Supports HTTP and HTTPS boot.
10. Add board UUID support.
11. Fixed the issue that USB device may not be detected at system power-on.
12. Main changes in this release
1) Add microcode M0130679906 for D1 stepping.
2) Produce SMBIOS type 1.
3) Changed manufacture name.
4) Fixed some open bugs. Please visit the following link for details.
New or Updated Modules:
Updated memconfig to only check registers that are defined by the platform
Updated common.bios_smi to check controls not registers
Added me_mfg_mode module
Added support for LoJax detection
Updated common.spi_lock test support
Added sgx_check module and register definitions
Updates to DCI support in debugenabled module
New or Updated Functionality:
Added ability for is_supported to signal a module is not applicable
Added 300 Series PCH support
Added support for building Windows driver with VS2017
Added fixed I/O bar support
Updated XML and JSON log rewrite
Updated logger to use python logging support
Added JEDEC ID command
Added DAL helper support
Added 8th Generation Core Processor support
Updated UEFI variable fuzzing code
Added C600 and C610 configuration
Added C620 PCH configuration
Updated ACPI table parsing support
Updated UEFI system table support
Added Denverton (DNV) support
Added result delta functionality
Added ability to override PCH from detected version
See release notes for list of Fixes.
[…]This provides specific guidance for firmware based upon the EFI Developer Kit II (EDKII) and coreboot. Because this document deals with host firmware internal requirements, it is not intended to provide side channel mitigation guidance for general application developers.
Scope: This addresses bare-metal firmware runtime risks and mitigation suggestions for the bounds check bypass, branch target injection, rogue data cache load, rogue system register read, and speculative store bypass side channel methods. Our examples and context are primarily focused on ring 0 firmware runtimes (for example: EFI Developer Kit II, PI SMM, and coreboot SMM). Other firmware execution environments are out of scope.[…]
Intel has a new document about hardware security and SGX:
There is tremendous opportunity for application and solution developers to take charge of their data security using new hardware-based controls for cloud and enterprise environments. Intel® Software Guard Extensions (Intel® SGX), available in its second-generation on the new Intel® Xeon® E-2100 processor, offers hardware-based memory encryption that isolates specific application code and data in memory. Intel® SGX allows user-level code to allocate private regions of memory, called enclaves, which are designed to be protected from processes running at higher privilege levels. We believe only Intel offers such a granular level of control and protection. Think about it like a lockbox in your home. Even though you have locks on your doors and a home security system, you may still secure your most sensitive data in a private lockbox with a separate key to provide extra layers of protection even if someone gained unwanted access to your home. Essentially, Intel® SGX is a lockbox inside a system’s memory, helping protect the data while it’s in-use during runtime.[…]
This website provides more than 200,000 pages with detailed latency, throughput, and port usage data for most x86 instructions on all generations of Intel’s Core architecture (i.e., from Nehalem to Coffee Lake). While such data is important for understanding, predicting, and optimizing the performance of software running on these microarchitectures, most of it is not documented in Intel’s official processor manuals.
Alexander Ermolov and Ruslan Zakirov will deliver their «NUClear explotion» talk. A major and most significant approach to UEFI BIOS security is preventing it from being illegitimately modified and the SPI flash memory from being overwritten. Modern vendors use a wide range of security mechanisms to ensure that (SMM BLE / SMM BWP / PRx / Intel BIOS Guard) and hardware-supported verification technologies (Intel Boot Guard). In other words, they do everything just not to let an attacker to place a rootkit into a system. Even the likelihood of execution in the most privileged mode of a processor – System Management Mode (can be achieved through vulnerable software SMI handlers) – is of no interest to adversaries since it does not guarantee they will be able to gain a foothold in a system. A single reboot and an attack must be started anew. However, there is a thing that can make all BIOS security mechanisms inefficient. And this thing is a vulnerable update mechanism implemented by a vendor. Moreover, quite often a legitimate updater adds lots and lots of critical security holes to a system. In this talk, we will speak about how vendors manage to throw all those security flaws together in one system using Intel NUC, a small home PC, as an example. Besides, we will demonstrate how an adversary can compromise BIOS from the userland.
by Behnam Eliyahu and Monika Sane
Telemetry refers to an umbrella of tools, utilities, and protocols to remotely extract and decode information for debugging potential issues with Intel® SSDs. Telemetry works over industry standard protocols, and eliminates or minimizes the need to remove SSDs from customer systems for retrieving debug logs. Telemetry thus enables host tools, Intel technical sales specialists, (TSS), Intel application engineers (AEs), and Intel engineering teams to better identify and debug performance excursions, exception events and critical failures in Intel® SSDs, without sending the physical drive to Intel for failure analysis. This capability is designed in accordance with NVMe* 1.3 telemetry specifications as well as corresponding ACS 4 SATA definitions (which are common industry standards), and is expected to accelerate debugging of external and internal bug sightings pertaining to Intel® SSDs. The key difference between NVMe and SATA is the fact that there is no controller-initiated capability on SATA drives.[…]
Responsible for secure design, development and operation of Intel’s hardware and software products and services. Responsibilities may include threat assessments, design of security components, and vulnerability assessment.
4+ years of experience in the field of system security research and exploring software and hardware techniques as a method of attack against targets within compute systems.
In-depth experience with security threats, vulnerability research, physical attack techniques (power analysis, fault injection, reverse engineering, etc.), side-channel attack methods.
Knowledge of security technologies: authentication, cryptography, secure protocol, etc.
Knowledge of computer architecture CPU, SoC, chipsets, BIOS, Firmware, Drivers, and others
When we switch on a computer, it goes through a series of steps before it is able to load the operating system. In this post we will see how a typical x86 processor boots. This is a very complex and involved process. We will only present a basic overall structure. Also what path is actually taken by the processor to reach a state where it can load an OS, is dependent on boot firmware. We will follow example of coreboot, an open source boot firmware.[…]
Brian Richardson of Intel has a new blog post, after the Open Source Firmware Conference, on open source firmware issues:
Vincent has a new blog post, covering some of his recent tour of speaking engagements, with a bit on UEFI, and even some FSP humor.
A newly completed Trusted Platform Module 2.0 (TPM2) software stack is being introduced, developed to comply with the most recent Trusted Computing Group (TCG) v1.38 specification and work on any TPM2 implementation. Partnering with key players within the domain of Trusted Computing such as Infineon and Fraunhofer SIT, Intel has made large investments in code improvements and new functionality compared to the previous version. This includes the initialization of the TSS Stack development and the SAPI, TCTI and abrmd layer. Based on this development, Infineon and Fraunhofer SIT enabled the support of the Enhanced System API (ESAPI) layer, which is intended to reduce programming complexity and to simplify the use and integration of the TPM.[…]
Vulnerability INTEL-SA-00086 allows to activate JTAG for Intel Management Engine core. We developed our JTAG PoC for the Gigabyte Brix GP-BPCE-3350C platform. Although we recommend that would-be researchers use the same platform, other manufacturers’ platforms with the Intel Apollo Lake chipset should support the PoC as well (for TXE version 18.104.22.1687).[…]