HPE iLOv5 Firmware Updates, Local Bypass of Security Restrictions

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03894en_us

[…]Release Date: 2018-10-30[…]
A security vulnerability in HPE Integrated Lights-Out 5 (iLO 5) prior to v1.37 could be locally exploited to bypass the security restrictions for firmware updates.[…]

https://2018.zeronights.ru/

HP iLO: a bit more on CVE-2017-12542

https://milo2012.wordpress.com/2018/06/30/some-notes-on-hpe-ilo4-authentication-bypass-and-rce-cve-2017-12542/

https://support.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us

https://www.rapid7.com/db/modules/auxiliary/admin/hp/hp_ilo_create_admin_account

https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/admin/hp/hp_ilo_create_admin_account.rb

https://tools.cisco.com/security/center/viewAlert.x?alertId=54930

https://github.com/skelsec/CVE-2017-12542

https://github.com/bao7uo/HPE-iLO-CVE-2017-12542

https://nvd.nist.gov/vuln/detail/CVE-2017-12542

HPE: iLO: Remote Unauthorized Modification of Information

Re: https://firmwaresecurity.com/2018/06/11/subverting-your-server-through-its-bmc-the-hpe-ilo4-case-presentation-toolbox/ and https://firmwaresecurity.com/2018/06/20/airbus-seclab-ilo4_toolbox-more-info-uploaded/

NOTICE: The information in this Security Bulletin should be acted upon as soon as possible.

Release Date: 2018-06-26

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03844en_us

Subverting your server through it’s BMC: the HPE iLo4 case (presentation + toolbox)

https://github.com/airbus-seclab/airbus-seclab.github.io/blob/master/ilo/RECONBRX2018-Slides-Subverting_your_server_through_its_BMC_the_HPE_iLO4_case-perigaud-gazet-czarny.pdf

https://airbus-seclab.github.io/

https://github.com/airbus-seclab/ilo4_toolbox

HPE seeks senior UEFI developer

Senior UEFI Development Engineer
Job ID 1023806

Strong knowledge in UEFI security or firmware security in general.
Strong knowledge in TPM, Secure Boot, TXT, and RSA.
Knowledge of industry standard technologies including ACPI, USB, SMBIOS, IPMI, Redfish, and PCI express.
8+ years’ experience in firmware or BIOS/UEFI development.
In-depth knowledge of UEFI architecture and development (focused on the EDK2 development environment).

https://careers.hpe.com/job/-/-/3545/7942722

HP iLO ransomware?

https://www.bleepingcomputer.com/news/security/ransomware-hits-hpe-ilo-remote-management-interfaces/

Coping with Spectre and Meltdown: What sysadmins are doing

Esther Schindler has a new article on Spectre and Meltdown for SysAdmins:

Coping with Spectre and Meltdown: What sysadmins are doing

The recent security vulnerabilities dumped a bunch of to-do items on system administrators’ desks. Feel like you’re alone? Here’s what other sysadmins have done so far, as well as their current plans and long-term strategy, not to mention how to communicate progress to management.

https://www.hpe.com/us/en/insights/articles/coping-with-spectre-and-meltdown-what-sysadmins-are-doing-1802.html

https://groups.google.com/a/lopsa.org/forum/#!topic/discuss/OSk4U32ShGs

HPE MSA firmware site created

 

Two suggestions: 1) use HTTPS not HTTP for web site. 2) Include a hash for the blobs.

Getting HPE MSA Storage firmware just got easier
HPEStorageGuy yesterday

Making things easier for customers is always a good idea. Kipp Glover from our HPE Storage Total Customer Experience & Quality team has been working to do that. Kipp wanted to make the process easy for HPE MSA Storage customers to get the latest firmware and related information like release notes and the firmware history for each of the last three generations of MSA models. Kipp and his team worked with our hpe.com people to create the website to make getting the latest MSA firmware easy. The website is hpe.com/storage/MSAFirmware. Kipp also created a short video that shows how to navigate the site so I wanted to share that with you.

https://community.hpe.com/t5/Around-the-Storage-Block/Getting-HPE-MSA-Storage-firmware-just-got-easier/ba-p/6996632

http://h41111.www4.hpe.com/storage/msafirmware.html

 

iLo4_toolbox: Toolbox for HPE iLO4 analysis

Subverting your server through its BMC: the HPE iLO4 case
iLO is the server management solution embedded in almost every HP servers for more than 10 years. It provides every feature required by a system administrator to remotely manage a server without having to reach it physically. Such features include power management, remote system console, remote CD/DVD image mounting, as well as many monitoring indicators. We’ve performed a deep dive security study of HP iLO4 (known to be used on the family of servers HP ProLiant Gen8 and ProLiant Gen9 servers) and the results of this study were presented at the REcon conference held in Brussels (February 2 – 4, 2018, see [1]). iLO4 runs on a dedicated ARM processor embedded in the server, and is totally independent from the main processor. It has a dedicated flash chip to hold its firmware, a dedicated RAM chip and a dedicated network interface. On the software side, the operating system is the proprietary RTOS GreenHills Integrity [2].[…]

https://github.com/airbus-seclab/ilo4_toolbox

 

HP SureStart firmware protection

http://www8.hp.com/h20195/v2/GetPDF.aspx/4AA6-9339ENW.pdf

https://ronny.chevalier.io/files/coprocessor-based-behavior-monitoring-acsac-chevalier-2017.pdf

 

 

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.

HPE iLO: multiple remote vulnerabilities (HPESBHF03769 rev.1)

 

Hewlett Packard Enterprise Support Center
HPESBHF03769 rev.1 – HPE Integrated Lights-out 4 (iLO 4) Multiple Remote Vulnerabilities
Document ID: hpesbhf03769en_us
Last Updated: 2017-08-24
Potential Security Impact: Remote: Authentication Bypass, Code Execution:
A potential security vulnerability has been identified in HPE Integrated Lights-out (iLO 4). The vulnerability could be exploited remotely to allow authentication bypass and execution of code. […] Hewlett Packard Enterprise would like to thank Fabien Perigaud of Airbus Defense and Space CyberSecurity for reporting this vulnerability.

https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us

https://tools.cisco.com/security/center/viewAlert.x?alertId=54930

“Limited details are available to describe this vulnerability or how this vulnerability could be exploited by an attacker. However, a successful exploit of this vulnerability could result in a complete system compromise.”

Hagfish: UEFI Bootloader for Barrelfish

Barrelfish is a new research operating system being built from scratch and released by ETH Zurich in Switzerland, originally in collaboration with Microsoft Research and now partly supported by HP Enterprise Labs, Huawei, Cisco, Oracle, and VMware. […]

Hagfish is the Barrelfish/ARMv8 UEFI loader prototype: Hagfish (it’s a basal chordate i.e. something like the ancestor of all fishes). Hagfish is a second-stage bootloader for Barrelfish on UEFI platforms, most importantly the ARMv8 server platform. […]

http://www.barrelfish.org/

https://github.com/BarrelfishOS/hagfish

https://github.com/BarrelfishOS/uefi-sdk

HPE increases ProLiant firmware security

HPE’s Gen10 Servers Will Have Security Drilled into Silicon

by Christine Hall on June 12, 2017

Hewlett Packard Enterprise unveiled Gen10 at Discover in Las Vegas last week, the first major upgrade to its ProLiant line of servers since Gen9 was released in 2014. While the release of a new server is generally not very interesting in this age of commodity hardware, this one is a bit more notable as it has some interesting security features built into the hardware. The announcement was made by Alain Andreoli, head of HPE’s infrastructure group, with no shortage of hyperbole: “We have definitively created the world’s most secure industry standard server.” The security feature works at the firmware level, utilizing custom HPE silicon. “In each Gen10 server we have created a unique individual fingerprint for the silicon,” Andreoli explained. “Your server will not boot unless the firmware matches this print — it is just locked end to end.”[…]

http://www.datacenterknowledge.com/archives/2017/06/12/hpes-gen10-servers-will-have-security-drilled-into-silicon/

 

Brian Richardson on Redfish and x-UEFI Config Lang

Brian Richardson of Intel UEFI team has a new blog post, showing HP vendor data using DMTF Redfish as well as viewing UEFI x-UEFI Configuration Language data.

http://blogs.intel.com/evangelists/2016/05/25/firmware-modern-data-center/

For more on the x-UEFI Configuration language, see Vincent’s post:

https://firmwaresecurity.com/2016/02/18/vincent-zimmer-on-the-x-uefi-configuration-language/

UEFI ported to RISC-V!

There’ve been a few presentations on porting UEFI to the RISC-V, but now there is public code! Abner Chang of HPE has submitted multiple patches with RISC-V support for various components of EDK-II.

[PATCH 0/3] *** EDK2 base tools support RISC-V processor***

EDK2 base tools support RISC-V arch. EDK2 build tool changes to generate RISC-V PE/Coff image from RISC-V ELF file, handle RISC-V relocations and generate EDK2 FW with RISC-V image machine type.

BaseTools: Support build RISC-V PE/Coff image.
 
The changes on BaseTools is for building RISC-V ELF image and PE/Coff Image. Also to generate FW and FV for RISC-V arch.     

[PATCH 0/2] *** EDK2 MDE for RISC-V processor ***

MdePkg: MDE implementations for RISC-V arch. The implementations of RISC-V MDE base libraries.

    Add RISC-V architecture image file machine code.
    Add RISC-V architecture relocation type.    
    Add RISC-V architecture context buffer.
    Add RISC-V architecture exception types.
    Add RISC-V architecture PXE tag definition.    
    Add RISC-V architecture EFI image machine type.
    Add RISC-V architecture removable media boot path.
    Add RISC-V architecture processor binding.
    
[PATCH] OvmfPkg/PciHostBridgeDxe: [RISC-V] Add back OVMF PciHostBridge module.

Use OVMF PCI host bridge driver as the RISC-V platform BUS.
This driver is used by RISC-V Virtualization package (RiscVVirtPkg).
Currently the platfrom spec for RISC-V is not yet ready, thus we use PCI host bridge in temporarily.

[PATCH] RiscVVirtPkg: RISC-V QEMU package.

This is RISC-V QEMU package. The image which built from this package can be launched on QEMU RISC-V port (not official QEMU). RiscVVirtPkg utilizes below modules from EDK2 OVMF package,
 – PciHostBridge DXE driver.
   Use PCI host bridge driver as RISC-V platform bus spec for adopting PC/AT components.
 – QemuFwCfgLib
   QEMU firmware configuration.
 – OVMF ACPI timer lib.
 – QemuFlashFvbServicesRuntimeDxe
 – QemuVideoDxe
 – XenIoPciDxe

[PATCH] RiscVPkg: RISC-V processor package.

 New processor package added to EDK2 open source for RISC-V.
 
[PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.

The implementation of RISC-V DxeIpl.

This is only the first round of these multiple patches, given initial discussion it is likely there will be another round. In the discussion for this patch, it appears there is more support upcoming, not yet public. In the thread, Abner mentioned:

“The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I have been told to upstream RISC-V code first and then submit the spec. I will confirm this again.”

I am looking forward to seeing what happens with the RISC-V UEFI port, and seeing some consumer devices based on RISC-V!

For more info, see the various threads on the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

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