Month: October 2017
Insyde Software security updates for Windows 10
Hurray, UEFI vendors focusing on security! 🙂
Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest
Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan
[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]
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. :-). ]
European Coreboot Conference 2017: some presentations online
Multiple PDFs from the European Coreboot Conference 2017, are already online, linked off their individual event pages, eg:
https://ecc2017.coreboot.org/schedule-location
And hopefully we can watch videos of the other presentations soon:
https://twitter.com/coreboot_org/status/924182339793678336
PS: The Coreboot event is happening in Europe nearly the same time the UEFI event is happening in Asia. I with those two firmware communities would sync their events and host them adjacently.
Firmware attacker -vs- defender job trends
A small observation: While searching for news on firmware, I have a variety of job searches, using various keywords, mostly scoped (due to tool limitations) to US-based jobs. I notice that most jobs related to firmware security are based around D.C. and require security clearance.
What concerns me is it seems the ratio is growing towards attackers, fewer related jobs by either device vendors or enterprises.
Granted vendors are hiring up all the firmware security researchers. But only a much smaller ratio of these kinds of jobs than for attacker jobs.
One good sign I have seen is a small rise in firmware security skills by enterprise sysadmins. Only a small number, but more than previously.
I wish some data scientist would do a study in attack/defense job ratios, without all the biases involved in my observations…
ReFirm Labs: IoT firmware security startup
“ReFirm Labs is at the forefront of IoT firmware security, vulnerability and zero-day discovery, and firmware remediation for IoT devices.”
http://i95business.com/2017/10/offit-kurman-represented-refirm-labs-1-5m-venture-capital-raise/
https://www.linkedin.com/pulse/iot-disasters-you-cannot-escape-terry-dunlap
Their “sister company” is Tactical Network Solutions:
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
“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.
Alex Matrosov joins NVIDIA!!
This is great news for NVIDIA security!!
Also anyone from ARM Ltd must be quite excited to see recent career paths of ex-CHIPSEC Project members. Alex and Yuriy of Eclypsium has an ARM port of CHIPSEC, which they says they they’re going to release (when!?!). Now Alex is joining Nvidia and will also be focusing on ARM. Note to the Linaro team working on the AArch64 port of LUV-live, once CHIPSEC works on ARM, you really need to get this project active again.
I hope the CHIPSEC team, and or (ARM Ltd, Linaro, Eclypsium, or now NVIDIA) helps update the CHIPSEC Project’s release of CPython. Today it is a binary-only release for x86 and x64, in the Github source tree. It’ll need ARM versions of CPython, and hopefully make CPython build for CHIPSEC transparent, or at least sign the blobs. Actually, this points out an upstream problem to Tianocore: CHIPSEC is an example of an ISV with a UEFI app that needs CPython, and has to ship it themselves. Tianocore should consider shipping CPython binaries along with ShellPkgBin binaries.
PS: I also just noticed that their book has a nice (new?) domain name: http://bootkits.io/ (no HTTPS).
Universal-IFR-Extractor
Nikolaj Schlej has a gork of Universal-IFR-Extractor. IFR is the UEFI forms language.
https://twitter.com/NikolajSchlej/status/924837830416785408?s=09
https://twitter.com/NikolajSchlej/status/924839077517582336
https://twitter.com/NikolajSchlej/status/924838214455529472
https://github.com/LongSoft/Universal-IFR-Extractor/releases/tag/v0.2
Replace your exploit-firmware with Linux: video available
https://twitter.com/qrs/status/924704712896712704
Re: https://firmwaresecurity.com/2017/10/27/google-wants-servers-without-intel-me-and-uefi/
Video of presentation is available:
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
more on Infineon TPM issue
https://www.rsa.com/en-us/blog/2017-10/roca-blaming-infineon-is-the-easy-way-out
https://www.ncsc.gov.uk/guidance/roca-infineon-tpm-and-secure-element-rsa-vulnerability-guidance
https://lwn.net/Articles/736736/
https://lkml.org/lkml/2017/10/25/382
https://blog.rapid7.com/2017/10/25/roca-vulnerable-rsa-key-generation/
https://en.wikipedia.org/wiki/ROCA_vulnerability
http://www.cvedetails.com/cve/CVE-2017-15361/
http://www.securityfocus.com/bid/101484
https://www.cvedetails.com/bugtraq-bid/101484/Infineon-RSA-Library-CVE-2017-15361-Cryptographic-Security-B.html
PoC||GTFO 0x16 released
Google wants servers without Intel ME and UEFI
Golem has a story about the recent Google presentation at OSSEU2017:
From Google Translation of German text:
Google wants servers without Intel ME and UEFI
by Sebastian GrĂĽner
According to the motto “Are you afraid?” a team of Google’s coreboot developers is working with colleagues to make Intel’s ME and the proprietary UEFI harmless in servers. And probably with success.[…]
Click to access Replace%20UEFI%20with%20Linux.pdf
Maybe I missed it, but I didn’t see the video of this presentation archived.
Hack.lu 2017 Intel AMT: Using & Abusing the Ghost in the Machine by Parth Shukla
AMI blog post with ‘firmware BSOD-like’ photos
AMI has a new blog post with a nice collection of firmware splash screens seen in the wild.
https://ami.com/en/tech-blog/aptio-and-amibios-in-interesting-places/
See-also: https://twitter.com/samkottler/status/757571758606147584
Matthew May’s UEFI Secure Boot Machine Owner Key generation scripts
Set of scripts I wrote to simplify UEFI Secure Boot Machine Owner Key generation, and signing of Nvidia, VMware, and VirtualBox kernel modules. These MOKs can be used to sign other kernel modules as well.
11 Myths About Platform Security
Jarvis Wenger has an interesting article in Electronic Design, listing misconceptions about hw/fw security, list below, read the article for all the details!
11 Myths About Platform Security: Greater system complexity means more areas are vulnerable to security breaches. This article examines the role hardware and software play in ensuring a secure computing platform.
1. When buying a product, such as a hypervisor, the software takes care of all additional security concerns in virtualization.
2. Security is only a concern for the OS/hypervisor/application.
3. I have taken care of my hypervisor, OS, application, and boot process, so my system is as secure as it can be.
4. A secure system is also a safe system.
5. My system isn’t connected to the outside world, so it’s secure.
6. My computer is isolated from the outside world, so I don’t need to run updates for the OS/Hypervisor/Application.
7. Only my most trusted employees have physical access, which means my system is secure.
8. My system is relatively secure and physically inaccessible, so it should be safe.
9. I’m using the latest up-to-date containers, therefore my application is safe.
10. The data on my device is encrypted, making it inaccessible.
11. Security is only a concern externally to a device.
http://www.electronicdesign.com/embedded-revolution/11-myths-about-platform-security
“Linux/Acpi.A!tr”: Linux ACPI malware?
I noticed this on an AV vendor’s site, about some Linux-centric (?) ACPI malware. Wish there was more info on it. If you have more details, please leave a Comment on this blog, thanks!
Linux/Acpi.A!tr
ID 7546097
Released Oct 26, 2017
Linux/Acpi.A!tr is classified as a trojan.
A trojan is a type of malware that performs activites without the user’s knowledge. These activities commonly include establishing remote access connections, capturing keyboard input, collecting system information, downloading/uploading files, dropping other malware into the infected system, performing denial-of-service (DoS) attacks, and running/terminating processes. The Fortinet Antivirus Analyst Team is constantly updating our descriptions. Please check the FortiGuard Encyclopedia regularly for updates.
MEAnalyzer v1.32.0 released
v1.32.0 includes:
Added support for CSME 11.8, 11.11 & 11.21 firmware
Added support for CSME 12 SPI FD Region structures
Added CSE Extension 22 for proper CSME 12 parsing
Added CSE Extension 14 Mod for proper DNX parsing
Added CSE Extension 5 Mod for proper Process parsing
Added CSE Extension data overflow error detection
Added CSE Extension data division error detection
Added CSE Extension data total size error detection
Improved CSE Extensions 1, 13 with CSME 12 support
Improved CSE Extension structure Revision detection
Fixed CSE unpacking crash at Key modules/regions
Fixed issues at unknown CSE Extension detection
Fixed wrong CSME 11 FIT PCH-H Z370 SKU detection
https://github.com/platomav/MEAnalyzer
Firmware Security 
You must be logged in to post a comment.