Tag: Intel

LUV 2.2-rc2 released

~ hucktech ~ Leave a comment

Megha Dey of Intel announced the v2.2-rc2 release of LUV, Linux UEFI Validation. Excerpts of announcement below, for full announcement, see LUV mailing list post.

Two main new features:

Dump list of Device-Specific Methods:
DSM (Device Specific Method) as defined in ACPI spec is a control method that enables devices to provide device specific control functions that are consumed by the device driver. DSM’s are optional on a platform and they are optional to be consumed by OS. Both these points mean that a kernel developer might be unaware of these DSM’s and hence might never use them in their device driver. By adding this feature, LUV could be used as a vehicle to educate kernel developers about these DSM’s. A device driver developer, from the list of DSM’s provided by LUV, could then evaluate the usefulness of a DSM and then decide if it needs to be used or left as an option.

Add tests in bits to detect Machine Check Errors:
Machine Check Error (MCE) test is a way to find the errors generated by the hardware or any specific subsystem(s). The value of these tests is that it detects any MCEs that might have occurred before Linux starts to boot. Hence, if detected, they were caused by hardware or possibly BIOS.

https://01.org/linux-uefi-validation/v2.2

https://lists.01.org/mailman/listinfo/luv

Intel releases Firmware Engine for Linux and Windows

~ hucktech ~ Leave a comment

Previously the Intel Firmware Engine was a Windows-only thing, and I’d usually mention the lack of Linux support when posting about each Windows release. This time they’ve ported it to Linux!!! Thanks, Intel!

https://firmware.intel.com/blog/intel-firmware-engine-40-release

Posted by BrianRichardson on 12/18/2017

The Intel® Firmware Engine 4.0 release is now available. Intel Firmware Engine enables rapid firmware configuration and customization using a graphical interface, without the need for source modifications. Customers start from a validated Intel reference design, allowing developers to configure firmware features based on their product customizations. This development process accelerates adding & removing firmware features not found in reference platform, adding 3rd party components, and integration of custom boot payloads.

Intel Firmware Engine 4.0 (Linux)

Intel Firmware Engine 4.0 adds application support for Ubuntu* Linux*, in addition to existing support for Microsoft* Windows operating systems. This release also updates the firmware core, based on the UDK2017 release available from tianocore.org, and improves deployment of microcode patch updates.

 

Intel Firmware Engine 4.0 (Linux)

Intel Total Memory Encryption (TME) and Multi-Key Total Memory Encryption (MKTME)

~ hucktech ~ Leave a comment

This document describes the memory encryption support targeting future Intel processors. Note that Intel platforms supports many different types of memory and not all SOC would support this capability for all types of memory. Initial implementation is likely to focus on traditional DRAM and NVRAM.

Total Memory Encryption (TME) – as name would imply is a capability to encrypt entirety of physical memory of a system. This capability is typically enabled in very early stages of boot process with small change to BIOS and once configured and locked will encrypt all the data on external memory buses of an SOC using NIST standard AES-XTS algorithm with 128-bit keys. The encryption key used for TME uses hardware random number generator implemented in Intel SOC and the keys are not accessible by software or using external interfaces to Intel SOC. TME capability is intended to provide protections of AES-XTS to external memory buses and DIMMs. The architecture is flexible and will support additional memory protections schemes in future. This capability when enabled is intended to support (unmodified) existing system and application software. Overall performance impact of this capability is likely to be relatively small and is highly dependent on workload.

Multi-Key Total Memory Encryption (MKTME) builds on TME and adds support for multiple encryption keys. The SOC implementation will support a fixed number of encryption keys, and software can configure SOC to use a subset of available keys. Software manages the use of keys and can use each of the available key for encrypting any page of the memory. Thus, MKTME allows page granular encryption of memory. By default MKTME uses TME encryption key unless explicitly specified by software. In addition to supporting CPU generated ephemeral key (not accessible by software or using external interfaces to SOC), MKTME also supports software provided keys. Software provided keys are particularly useful when used with non-volatile memory or when combined with attestation mechanisms and/or used with key provisioning services. In virtualization scenario, we anticipate VMM or hypervisor to manage use of keys to transparently support legacy operating systems without any changes (thus, MKTME can also be viewed as TME virtualization in such deployment scenario). An OS may be enabled to take additional advantage of MKTME capability both in native or virtualized environment. When properly enabled, MKTME is available to each guest OS in virtualized environment, and guest OS can take advantage of MKTME in same was as native OS.

Click to access Multi-Key-Total-Memory-Encryption-Spec.pdf

BTW, this is a great Twitter account to watch for updates to the Intel documentation.

more on Intel-SA-00068 (Intel ME) vuln

~ hucktech ~ Leave a comment

Intel has updated their advisory again, many more OEMs on the list now:

https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

Intel ME has impacted Intel WPA2:

https://security-center.intel.com/advisory.aspx?intelid=intel-sa-00101&languageid=en-fr

Microsoft provides info, but the researchers argue with their conclusions:

https://blogs.technet.microsoft.com/surface/2017/12/11/intel-management-engine-vulnerability-and-surface-devices/

 

Brian: Using CHIPSEC Whitelists to Improve Firmware Security

~ hucktech ~ Leave a comment

[Strange, I was doing the previous blog post on Brian, and during that time, he did a new blog post…]

Brian Richardson of Intel has a new blog post on using CHIPSEC whitelist command to help with UEFI security:

Using Whitelists to Improve Firmware Security

Firmware has become more popular in the world of computer security research. Attacks operating at the firmware level can be difficult to discover, and have the potential to persist even in bare-metal recovery scenarios. This type of hack has been well documented by investigations of the HackingTeam and Vault7 exploits. Fortunately, there are methods for detecting and defending against such attacks. Firmware-based attacks typically attempt to add or modify system firmware modules stored in NVRAM. Tools provided by the open source CHIPSEC project can be used to generate and verify hashes of these modules, so users can detect unauthorized changes.[…]

https://software.intel.com/en-us/blogs/2017/12/05/using-whitelists-to-improve-firmware-security
https://github.com/chipsec/chipsec

CHIPSEC in Ubuntu Linux

more on Intel-SA-00068 (Intel ME)

~ hucktech ~ Leave a comment

Intel has updated the advisory documents. There are more OEMs in the list:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

Acer
ASUS
Compulab
Dell Client
Dell Server
Fujitsu
Getac
GIGABYTE
HP Inc.
HPE Servers
Intel: NUC, Compute Stick, Compute Card
Lenovo
MSI
Oracle
Panasonic
Quanta/QCT
Supermicro
Toshiba
Vaio

AMI on Intel’s BIOS end-of-life announcement

~ hucktech ~ Leave a comment

 

https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/

Click to access Brian_Richardson_Intel_Final.pdf

 

The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂

Intel seeks senior security researcher

~ hucktech ~ Leave a comment

[Hmm, I don’t understand Intel org chart, but I’ve never heard of the Advanced Security Research Team, sounds like it is under Security Center of Excellence, which is under Platform Engineering Group (PEG)? Not to be confused with Intel Advanced Threat Research, which went off with the MkAfee split.]

“The Platform Engineering Group (PEG) is responsible for the design, development, and production of system-on-a-chip (SoC) products that go into Intel’s next generation client and mobile platforms. […] Intel Security Center of Excellence’s […] we would like you to join us as a proud member of Intel’s Advanced Security Research Team. Through your deep vulnerability analysis and mitigation development expertise, you will influence the security of a variety of Hardware, Firmware, Software & Systems spanning a range of products including Devices, Cloud, Auto, IOT, AI, VR, Drones, and Networks. Responsibilities include the following: Own emerging threat analysis, gain insights & know-how of evolving attack techniques, predict and extrapolate attack trends ahead of its occurrence, develop robust counter measures and mitigation.[…]

* 5+ years of experience in the field of system security research and excel in exploring software and hardware techniques as a method of attack against targets within the computing systems.
* Experience with spanning security expertise over HW, SW and Firmware domains.
* Knowledge of computer architecture CPU, SoC, chipsets, BIOS, Firmware, Drivers, and others
[…]
* Strong network in security community CISSP and/or other security certifications

http://jobs.intel.com/ShowJob/Id/1426937/Sr.%20Security%20Researcher

Monotonic Counter in Intel SGX and ME

~ hucktech ~ Leave a comment

Some notes on the Monotonic Counter in Intel SGX and ME
Posted on November 10, 2017 by daveti

SGX sealing is vulnerable to rollback attacks as the enclave is not able to tell if the sealed data is the latest or a old copy. To mitigate this attack, monotonic counter (MC) has been introduced in Intel SGX SDK 1.8. This post looks into some implementation details inside Intel SGX SDK.[…]

Some notes on the Monotonic Counter in Intel SGX and ME

a bit more on INTEL-SA-00068 (Intel ME)

~ hucktech ~ Leave a comment

Intel has updated the advisory page, I think the doc is at v1.3 now:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

The list of OEMs is larger now:

Acer
Compulab
Dell Client
Dell Server
Fujitsu
Getac
HP Inc.
HPE Servers
Intel® NUC, Intel® Compute Stick, and Intel® Compute Card: Support Information
Lenovo
MSI
Panasonic
Quanta/QCT

 

 

Matthew on Intel ME security: worst case here is terrible, but unlikely to be relevant to the vast majority of users

~ hucktech ~ Leave a comment

Matthew has an excellent new blog post on recent Intel ME security news.

https://mjg59.dreamwidth.org/49611.html

[…]The big problem at the moment is that we have no idea what the actual process of compromise is. Intel state that it requires local access, but don’t describe what kind. Local access in this case could simply require the ability to send commands to the ME (possible on any system that has the ME drivers installed), could require direct hardware access to the exposed ME (which would require either kernel access or the ability to install a custom driver) or even the ability to modify system flash (possible only if the attacker has physical access and enough time and skill to take the system apart and modify the flash contents with an SPI programmer). The other thing we don’t know is whether it’s possible for an attacker to modify the system such that the ME is persistently compromised or whether it needs to be re-compromised every time the ME reboots. Note that even the latter is more serious than you might think – the ME may only be rebooted if the system loses power completely, so even a “temporary” compromise could affect a system for a long period of time. It’s also almost impossible to determine if a system is compromised. If the ME is compromised then it’s probably possible for it to roll back any firmware updates but still report that it’s been updated, giving admins a false sense of security. The only way to determine for sure would be to dump the system flash and compare it to a known good image. This is impractical to do at scale. So, overall, given what we know right now it’s hard to say how serious this is in terms of real world impact. It’s unlikely that this is the kind of vulnerability that would be used to attack individual end users – anyone able to compromise a system like this could just backdoor your browser instead with much less effort, and that already gives them your banking details. The people who have the most to worry about here are potential targets of skilled attackers, which means activists, dissidents and companies with interesting personal or business data. It’s hard to make strong recommendations about what to do here without more insight into what the vulnerability actually is, and we may not know that until this presentation next month.[…]

Halium for Android-IA/Clovertrail+

~ hucktech ~ 1 Comment

Ilya Bizyaev posts on the Intel Android-IA mailing list about working to get Halium port of the ASUS ZenFone5:

I am writing to announce that I am working on a Halium (halium.org) port for ASUS ZenFone 5, a Clovertrail+ based phone. Porting Halium base to this Intel platform enables numerous open-source projects, including Ubuntu Touch (ubports.com), Plasma Mobile (plasma-mobile.org), LuneOS (webos-ports.org) and Mer (merproject.org) to use all of the Clovertrail+ devices for development and testing. I am proud to report that as of now, the Halium build system supports using custom Intel boot tools, and the device boasts a stable 3.10 kernel and Android 7.1-based system build that has Wi-Fi, touch sensor, hardware keys, LEDs and vibrator working.

Full post:  android-ia@lists.01.org archives.

https://github.com/Halium/android_kernel_asus_T00F
https://github.com/Halium/android_device_asus_T00F

Hmm, I didn’t know about Halium…

https://halium.org/

https://halium.org/announcements/2017/04/24/halium-is-in-the-air.html

From the Halium blog’s initial post:

Over the years, various efforts have been made to bring GNU/Linux to mobile devices (for example Maemo, Meego, Mer, SailfishOS, Ubuntu Touch, Plasma Mobile). They have either achieved their individual goals or are working in direction of achieving them. During the development of such projects it was suggested multiple times that these communities should work together as their ultimate goal is the same. However due to various reasons this never happened in the past. However we believe that it is time to change this situation. Currently distributions like AsteroidOS, LuneOS, Mer, Plasma Mobile, SailfishOS, and Ubuntu Touch have one thing in common that they use the libhybris to interact with the android binary blobs and they also run the various android daemons using different methods. And there is lot of fragementation on how this task is handled even though these parts don’t need to be different as their essential goal is to make use of android binary blobs. Project Halium is the effort by the community which aims to bring the common grounds for different distributions and have a common base which includes the Linux kernel, Android Hardware Abstraction Layer, and libhybris. Project Halium also aims to standardize the middlewares used to interact with the hardware of the device. By having these parts shared, we believe that it will reduce the fragmentation we have currently.[…]

architecture

 

HP Labs: Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the SMM

~ hucktech ~ Leave a comment

Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode
Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet
HP Labs
Highly privileged software, such as firmware, is an attractive target for attackers. Thus, BIOS vendors use cryptographic signatures to ensure firmware integrity at boot time. Nevertheless, such protection does not prevent an attacker from exploiting vulnerabilities at runtime. To detect such attacks, we propose an event-based behavior monitoring approach that links to an isolated co-processor. We instrument the code executed on the main CPU to send information about its behavior to the monitor. This information helps to solve the semantic gap issue. Our approach does not depend on a specific model of the behavior nor a specific target. We apply this approach to detect system management mode (SMM), a highly privileged x86 executable mode executing firmware code at runtime. We model the behavior of SMM using CPU registers (CR3 and SMBASE). We have two open-source firmware implementations: EDK II and coreboot. We evaluate the ability to detect and detect the effects of ARM Cortex A5 co-processor. The results show that our solution detects intrusions from the state of the art, without any false positives, while remaining acceptable in terms of performance overhead in the context of the SMM (ie, less than the 150 μs threshold defined by Intel).

https://hal.inria.fr/hal-01634566/

A bit more on INTEL-SA-00086 (Intel ME update)

~ hucktech ~ Leave a comment

Intel’s advisory updated overnight:
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

More OEM announcements:
http://pc-dl.panasonic.co.jp/itn/info/osinfo20171121.html
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00036596en_us
https://us.answers.acer.com/app/answers/detail/a_id/51890

Updating Intel Management Engine firmware on a Lenovo without a Windows Install

More on INTEL_SA-00086 (Intel ME update)

~ hucktech ~ Leave a comment

Advisory doc updated overnight:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

Vendors are starting to issue advisories:
https://support.lenovo.com/us/en/product_security/len-17297
http://www.dell.com/support/article/us/en/19/sln308237/dell-client-statement-on-intel-me-txe-advisory–intel-sa-00086-?lang=en
http://www.dell.com/support/article/us/en/19/qna44242/dell-server-statement-on-intel-me-txe-advisory–intel-sa-00086-?lang=en
https://www.intel.com/content/www/us/en/support/articles/000026230/mini-pcs.html

https://www.us-cert.gov/ncas/current-activity/2017/11/21/Intel-Firmware-Vulnerability

A few researchers’ comments on the quality of this advisory:

https://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html#msg10191

If you disable Intel ME, does that mean Intel SGX, Boot Guard, and other tech is also broken? Pandora’s box is full of toys…

https://twitter.com/NikolajSchlej/status/932753528875114496

 

Intel Management Engine Critical Firmware Update

~ hucktech ~ Leave a comment

Intel® Management Engine Critical Firmware Update (Intel SA-00086)

Intel Q3’17 ME 11.x, SPS 4.0, and TXE 3.0 Security Review Cumulative Update (INTEL-SA-00086)
Product family: Various
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Original release: Nov 20, 2017
Last revised: Nov 20, 2017

In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of our Intel® Management Engine (ME), Intel® Server Platform Services (SPS), and Intel® Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience. As a result, Intel has identified security vulnerabilities that could potentially place impacted platforms at risk. Systems using ME Firmware versions 11.0/11.5/11.6/11.7/11.10/11.20, SPS Firmware version 4.0, and TXE version 3.0 are impacted.[…]Based on the items identified through the comprehensive security review, an attacker could gain unauthorized access to platform, Intel® ME feature, and 3rd party secrets protected by the Intel® Management Engine (ME), Intel® Server Platform Service (SPS), or Intel® Trusted Execution Engine (TXE). This includes scenarios where a successful attacker could:

* Impersonate the ME/SPS/TXE, thereby impacting local security feature attestation validity.
* Load and execute arbitrary code outside the visibility of the user and operating system.
* Cause a system crash or system instability.
[…]
Acknowledgements:
* External Security Researchers and Intel Validation.
* Intel would like to thank Mark Ermolov and Maxim Goryachy from Positive Technologies Research for working collaboratively with Intel on a coordinated disclosure for CVE-2017-5705.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

Detection tool for Linux and Windows:
https://downloadcenter.intel.com/download/27150

 

Intel open sources HAXM, Hardware Accelerated Executation Manager for Mac/Windows

~ hucktech ~ Leave a comment

Intel Hardware Accelerated Execution Manager (HAXM)

HAXM is a hardware-assisted virtualization engine (hypervisor) that uses Intel Virtualization Technology to speed up IA (x86/ x86_64) emulation on a host machine running Windows or macOS. It started as an Android SDK component, but has recently transformed itself into a general accelerator for QEMU. HAXM can be built as either a kernel-mode driver for Windows or a kernel extension for macOS.[…]

https://github.com/intel/haxm

 

See-also:

https://01.org/android-ia/q-and-a/what-haxm

https://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager-intel-haxm

https://github.com/Nukem9/Haxm