Reversing Toshiba laptop BIOS protection

Michał Kowalczyk has an interesting presentation on Intel BIOS reversing, focusing on a Toshiba system. Presentation is in Polish. If you have a Toshiba, see the excerpt below with advisory info.

https://twitter.com/q3k/status/928672822808973312

 

Oficjalne stanowisko Toshiby
Toshiba is working on a temporary BIOS update that can be used to prevent the security issue that has been raised and expects to release this update on its website within the next 2 weeks.
Toshiba plans to start the release of a permanent fix for some models from January, 2018 and will complete the releases of permanent fix for all applicable models by the end of March 2018.

Click to access bd81619010b3b8ef012ff8af491a034bd9c6c3adfd76ddbb180c43c15f291fc1.pdf

http://dragonsector.pl/

 

SeaBIOS 1.11.0 released

New in this release:
* Initial support for NVME drives
* Support for vga emulation over a serial port in SeaBIOS (sercon)
* Support for serial debugging using MMIO based serial ports
* Support for scsi devices with multiple LUNs
* Support for boot-to-boot persistent coreboot cbmem logs
* Improved coreboot vga (cbvga) mode setting compatibility
* Several bug fixes and code cleanups

For full announcement, see Kevin O’Connor’s posting to the SeaBIOS list.

http://seabios.org/Releases
http://seabios.org/Download
https://mail.coreboot.org/mailman/listinfo/seabios

Positive Technologies: JTAG in each house: full access via USB

It is amazing to see the Intel ME research coming out of Positive Technologies!

From Google Translate:

JTAG in each house: full access via USB

Researchers at Positive Technologies have activated hardware debugging (JTAG) for Intel Management Engine, which allows full access to all PCH devices (Platform Controller Hub) using Intel DCI technology (via USB interface). We plan to share the details at one of the nearest conferences. And how to activate this interface, but for the main processor, we will tell below.[…]

https://habrahabr.ru/company/pt/blog/341946/

https://translate.google.com/translate?hl=en&sl=ru&u=https://habrahabr.ru/company/pt/blog/341946/

Intel ME is the new “Pandora’s Box”, defenders are going to need bigger (better) tools… 😦

Intel TXE 3.0 security update??

Quoting an article from hexus.net:

MSI adds latest Intel TXE 3.0 security update

In order to avoid severe security vulnerabilities for the platforms, MSI motherboards now support the latest Intel Trusted Execution Engine (TXE) 3.0 for safer system protection. According to recent Intel comprehensive security review, security vulnerabilities are identified and could potentially allow attackers to gain unauthorized access to platforms features, secrets and 3rdparty secrets protected by Intel TXE. Therefore, Intel has validated and released Intel TXE 3.0 updates to address the encountered security situations. Currently all MSI 100,200 and 300 series motherboards are supporting the newest Intel TXE 3.0 by updating to the latest BIOS and installing the latest software updates. MSI always places strong emphasis on security and anti-hack issues to makes sure all MSI motherboard users are operating under the most secure circumstances. MSI will continue to provide additional updates if necessary to ensure maximum platform security protection for users.[…]

https://hexus.net/tech/items/mainboard/111626-msi-adds-latest-intel-txe-30-security-update/

[ Update: my last paragraph was wrong, removed. see Comment by reader. :-). ]

Fall UEFI Plugfest agenda

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Intel patch for UEFI pre-memory DMA protection in PEI

Intel has submitted a V3 patch to the tianocore EDK2 project, with additional DMA protection for UEFI on Intel systems.

[PATCH V3 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI

V3:
1) update the function comments of InitDmar()
2) update the function comments of SiliconInitializedPpiNotifyCallback()
3) remove duplicated BAR debug message.
4) fix the size field in the mPlatformVTdNoIgdSample structure.

V2:
Minor enhancement: Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(), for better code management.

V1:
This series patch adds Pre-Memory DMA protection in PEI. The purpose is to make sure when the system memory is initialized, the DMA protection takes effect immediately. The IntelVTdPmrPei driver is updated to remove the global variable and add VTD_INFO_PPI notification. The VTdInfoSample driver is updated to install the initial VTD_INFO_PPI before memory init, and add more content after memory init by reinstalling VTD_INFO_PPI. This patch is validated on one Intel Client kabylake platform.

For more info, see full patch:
https://lists.01.org/mailman/listinfo/edk2-devel

Chipsec v1.3.4 released

New or Updated Functionality:
* Updated support for 7th/8th generation Intel processors
* Added ability to undefine a configuration entry
* Added HAL and utilcmd for TPM Event Log
* Added utilcmd for TPM commands
* Added support for Apollo Lake
* added utilcmd to inspect PCI command/control registers

https://github.com/chipsec/chipsec/commits/master

https://github.com/chipsec/chipsec/releases/tag/v1.3.4

 

Embedi: UEFI BIOS holes. So much magic. Don’t come inside.

24 October, 2017
UEFI BIOS holes. So Much Magic. Don’t Come Inside.
In recent years, embedded software security has become a red-hot topic, attracting the attention of high profile security researchers from all around the globe. However, the quality of code is still far from perfect as long as its security is considered. For instance, the CVE-2017-5721 SMM Privilege Elevation vulnerability in the firmware could affect such scope of vendors like Acer, ASRock, ASUS, Dell, HP, GIGABYTE, Lenovo, MSI, Intel, and Fujitsu. This white paper is intended to describe how to detect a vulnerability in a motherboard firmware with the help of the following tools: Intel DAL, UEFITool, CHIPSEC, RWEverything, and how to bypass the patch that fixes this vulnerability.[…]

https://embedi.com/blog/uefi-bios-holes-so-much-magic-dont-come-inside

MSI-GT7x-VGA-Switch: toggle Intel/Nvidia VGA from UEFI Shell

MSI-GT7x-VGA-SWITCH: Selects VGA from LINUX or EFI!

These programs or batch scripts will let you swtch the VGA from INTEL to NVIDIA (or the opposite). This is possible at the moment only from Windows (bad choice MSI!). Now it will also be possible from Linux or directly from an EFI SHELL! Intel.nsh and nvidia.nsh are two EFI Shell scripts that can be run directly from EFI shell. Just “make intel” and “make nvidia” to compile the 2 C sources. A reboot is needed afterwards because the VGA is switched by BIOS at boot time.[…]

https://github.com/Zibri/MSI-GT7x-VGA-SWITCH

Linux UEFI Validation Project v2.2-rc1 released

Megha Dey of Intel has taken over the role of LUV maintainer, and announced the 2.2-rc1 release. Excerpts of announcement are below, read full announcement for list of bugfixes.

This is to announce the release of LUV v2.2-rc1. Firstly, I would inform all of you that I have taken over the role of maintainer of this project from Ricardo Neri. I would like to thank Ricardo for all the guidance and support he has provided to make this release possible. This release comes approximately 3 months after our last 2.1-rc2 release and we are further working to have releases more frequently. It mostly includes updates to yocto, meta-oe, various test suites and kernel version. We have also added a new test suite called pstore-test which will run the pstore selftests of the kernel and added some tests in kernel-efi-warnings to detect machine check errors. Given that this is the first time I am doing the release, it is possible for some issues to arise, hence it made sense to have this release as rc1 of v2.2 to allow stabilization towards the next release cycle.

We added a new test suite called pstore-test. This test-suite will check the pstore behavior and are useful to avoid regressions of pstore. This test-suite will cause a reboot during its execution. The necessary groundwork to ensure these type of test suites can be integrated seamlessly into LUV has also been included in this release.

Also, Ricardo added some tests in kernel-efi-warnings to detect machine check errors such as system bus errors, parity errors, cache errors and TLB errors. Linux has support to detect this underlying mechanism and report the error in the kernel message buffer.

We include FWTS V17.09.00 Chipsec 1.3.3 and NDCTL v58, the latest versions available as of this week.

The release images for x86 (disk and network) will be available on 10/23/2017.

 

https://01.org/linux-uefi-validation/v2.2 (apparently this URL won’t be valid until 10/23?)

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

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

OpenXT

Linux.com has a nice article on Xen, Linux, TPM, and TXT. It also mentions the OpenXT toolkit.

https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt

OpenXT is an open-source development toolkit for hardware-assisted security research and appliance integration. Released as Open-Source Software (OSS) in June 2014, OpenXT stands on the shoulders of Xen Project and OpenEmbedded. It is derived from XenClient XT, which was first released in May 2011. It includes hardened Xen VMs that can be configured as a user-facing virtualization appliance, for client devices with Linux and/or Windows guests. It has been used to develop managed software appliances to isolate demanding graphics workloads, untrusted workloads and multiple networks on a single laptop or desktop. OpenXT is optimized for x86 devices with Intel VT-d, TXT (Trusted Execution Technology) and a TPM. OpenXT is being developed to meet the varied needs of the security and virtualization communities, as a toolkit for the configurable disaggregation of operating systems and user workflows. Client appliances developed on OpenXT can contain a mixture of open-source and proprietary software, supporting a range of business models.[…]

https://openxt.atlassian.net/wiki/spaces/OD/pages/10747915/What+is+OpenXT

 

UEFI security presentation at Seattle DC206 Meeting

If you missed the Intel presentation from BlackHat Briefings this summer, and if you are in the Seattle area this Sunday, Vincent Zimmer of Intel will be reprising this presentation at the DC206 Meeting at the Black Lodge Research hackerspace.

https://www.dc206.org/?p=216

What: Oct DC206 Meeting: Firmware is the New Black
When: October 15th, 1-3pm
Who: Vincent Zimmer
Where: Black Lodge Research

Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities

In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).

https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities
http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html

Click to access BlackHat2017-BlackBIOS-v0.13-Published.pdf

https://blacklodgeresearch.org/

https://www.facebook.com/events/1611758852222280/

Intel Whitepaper updated: Using IOMMU for DMA Protection in UEFI Firmware

We recommend firmware developers review this docment to understand threats from unauthorized internal DMA, as well as DMA from non-PCI devices that platform firmware may configure. Using an IOMMU such as Intel VT-d allows fine-grain control of memory protection without broadly disabling bus-mastering capabilities in the pre-boot space.

Note: this whitepaper was originally published under the title “A Tour beyond BIOS Using Intel® VT-d for DMA Protection in UEFI BIOS” in January 2015.

https://firmware.intel.com/blog/updated-whitepaper-using-iommu-dma-protection-uefi-firmware

Click to access Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf

Security updates for Intel NUC firmware (INTEL-SA-00084)

Intel ID: INTEL-SA-00084
Product family: Intel® NUC Kits
Impact of vulnerability: Elevation of Privilege
Severity rating: Critical
Original release: Oct 06, 2017

This update improves protection against mitigates multiple vulnerabilities related to security features in Intel® NUC system firmware (BIOS). BIOS Administrator and User password bypass: Insufficient protection of password storage in system firmware for NUC7i3BNK, NUC7i3BNH, NUC7i5BNK, NUC7i5BNH, NUC7i7BNH versions BN0049 and below allows local attacker to bypass Administrator and User passwords via access to password storage. SPI Write Protection Bypass: Insecure platform configuration in system firmare for NUC7i3BNK, NUC7i3BNH, NUC7i5BNK, NUC7i5BNH, NUC7i7BNH versions BN0049 and below allows an attacker with physical presence to run arbitrary code via unauthorized firmware modification during BIOS Recovery. SMM Privilege Elevation: Insufficient input validation in system firmware for Intel® NUC systems allows local attacker to execute arbitrary code via manipulation of memory. Boot Guard Bypass: Incorrect policy enforcement in system firmware for Intel® NUC systems allows attacker with local or physical access to bypass enforcement of integrity protections via manipulation of firmware storage. Dangerous SPI Opcode Protections: Insufficient policy enforcement in system firmware for Intel® NUC systems allows attacker with local or physical access to violate integrity or availability of nonvolatile storage for firmware via specially crafted accesses to nonvolatile storage. Intel highly recommends that users update to the latest version. Intel would like to thank Nikolaj Schlaj for reporting CVE-2017-5700 and CVE-2017-5701 and working with us on coordinated disclosure. Intel would like to thank Embedi for reporting CVE-2017-5721 and CVE-2017-5722 and working with us on coordinated disclosure.[…]

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

 

 

Embedi: Bypassing Intel Boot Guard

https://twitter.com/_embedi_/status/915974703772205056

In recent years, there is an increasing attention to the UEFI BIOS security. As a result, there are more advanced technologies created to protect UEFI BIOS from illegal modifications. One of such technologies is Intel Boot Guard (BG) – a hardware-assisted BIOS integrity verification mechanism available since Haswell microarchitecture (2013). So-called «UEFI rootkits killer» this technology is designed to create a trusted boot chain (where a current boot component cryptographically measures/verifies the integrity of the next one) with Root-of-Trust locked into hardware.[…]

https://embedi.com/blog/bypassing-intel-boot-guard

Intel seeks senior security researcher

Job ID: JR0037962
Senior Security Researcher

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. PEG strives to lead the industry moving forward through product innovation and world class engineering. Intel Security Center of Excellence’s goal is to be a prominent leader in the industry to assure security in computing platforms by conducting advanced security research. If you are a seasoned threat, vulnerability and exploit research expert who craves for tons of fun and pride in raising the security bar for ubiquitous computing systems, 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. This role requires maintaining substantial knowledge of state-of-the-art security principles, theories, attacks etc. and contribute those insights to internal and external stakeholders. Participation in development or intellectual property is also a responsibility.

* Applicants should possess at least 10 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.
* Ability to span security expertise over HW, SW and Firmware domains. Passion for the latest gadgets and building security into these gadgets.
* Knowledge of computer architecture CPU, SoC, chipsets, BIOS, Firmware, Drivers, and others

 

 

http://jobs.intel.com/ShowJob/Id/1352711/Senior%20Security%20Researcher