Hastily-written news/info on the firmware security/development communities, sorry for the typos.
[I think this documentation is new. Maybe the feature is new as well.]
This topic explains how to configure System Guard Secure Launch and System Management Mode (SMM) protection to improve the startup security of Windows 10 devices. The information below is presented from a client perspective.[…]
Using CPU System Management Mode to Circumvent Operating System Security Functions
Loı̈c Duflot, Daniel Etiemble, Olivier Grumelard
Abstract. In this paper we show how hardware functionalities can be misused by an attacker to extend her control over a system. The originality of our approach is that it exploits seldom used processor and chipset functionalities, such as switching to system management mode, to escalate local privileges in spite of security restrictions imposed by the operating system. As an example we present a new attack scheme against OpenBSD on x86-based architectures. On such a system the superuser is only granted limited privileges. The attack allows her to get full privileges over the system, including unrestricted access to physical memory. Our sample code shows how the superuser can lower the “secure level” from highly secure to permanently insecure mode. To the best of our knowledge, it is the first time that documented processor and chipset functionalities have been used to circumvent operating system security functions.
2019 OCP Global Summit:
Case Study: Alternatives for SMM usage in Intel Platforms
Sarathy Jayakumar, Principal Engineer – Firmware, Intel Corporation
The broadcast System Management Mode (SMM) model has been used for many years to manage priority system events but has a number of disadvantages. Overuse of System Management Interrupts (SMI) results in performance degradation, increases latency with higher core counts, and introduces potential race conditions. SMM is also difficult to debug and has access to system resources outside of the OS environment, which makes it target for firmware exploits. This session expands on Intel’s initiative to reduce SMM footprint and provide alternatives for handling runtime platform events. Intel described SMI reduction methods based on Protected Runtime Mechanism (PRM), UEFI Capsule, and the Baseboard Management Controller (BMC) at the 2018 OCP Regional Summit. The presentation features a case study and demonstration using Intel® Xeon® Scalable Processors with EDK II firmware.
https://www.opencompute.org/summit/global-summit
In French. And has a transcript.
“Security Issues Related to Pentium System Management Mode”
Loïc Duflot Direction Centrale de la Sécurité des Systèmes d’Information SGDN/DCSSI 51 boulevard de la Tour Maubourg Paris
Written by Bruno · 2018-12-18 · in Exploit
[…]In summary, if we consider we have found a vulnerability allowing to call an arbitrary address in SMM, the final steps for the exploitation are:[…]
https://www.synacktiv.com/posts/exploit/code-checkmate-in-smm.html
System Management Module Vulnerabilities
Lenovo Security Advisory: LEN-24374
Potential Impact: Privilege escalation
Severity: High
Scope of Impact: Lenovo-specific
CVE Identifier: CVE-2018-9083, CVE-2018-9084, CVE-2018-16089, CVE-2018-16090, CVE-2018-16091, CVE-2018-16092, CVE-2018-16094, CVE-2018-16095, CVE-2018-16096
Summary Description:
A Lenovo security audit of the System Management Module firmware uncovered the following vulnerabilities. SMM networking is disabled by default, and these cannot be exploited until networking is enabled:
CVE-2018-16089: A field in the header of SMM firmware update images is insufficiently sanitized, allowing post-authentication command injection on the SMM as the root user.
CVE-2018-16090: The SMM certificate creation and parsing logic is vulnerable to post-authentication command injection.
CVE-2018-16091: The SMM certificate creation and parsing logic is vulnerable to several buffer overflows.
CVE-2018-9083: The SMM contains weak default root credentials which could be used to log in to the device OS — if the attacker manages to enable SSH or Telnet connections via some other vulnerability.
CVE-2018-9084: If an attacker manages to log in to the device OS, the validation of software updates can be circumvented.
CVE-2018-16092: The FFDC feature includes the collection of SMM system files containing sensitive information; notably, the SMM user account credentials and the system shadow file.
CVE-2018-16094: An internal SMM function that retrieves configuration settings is prone to a buffer overflow.
CVE-2018-16095: The SMM records hashed passwords to a debug log when user authentication fails.
CVE-2018-16096: The SMM web interface for changing Enclosure VPD fails to sufficiently sanitize all input for HTML tags, possibly opening a path for cross-site scripting.
https://support.lenovo.com/pt/fi/solutions/len-24374
see-also:
https://exchange.xforce.ibmcloud.com/vulnerabilities/153003
3mdeb points out that there is a patent by Intel with information focused on disabling Intel SMM.
Don’t click on this link if you’re an engineer and are not allowed to view patent information.
EPA-RIMM: A Framework for Dynamic SMM-based Runtime Integrity Measurement
Brian Delgado, Karen L. Karavanic
(Submitted on 9 May 2018)
Runtime integrity measurements identify unexpected changes in operating systems and hypervisors during operation, enabling early detection of persistent threats. System Management Mode, a privileged x86 CPU mode, has the potential to effectively perform such rootkit detection. Previously proposed SMM-based approaches demonstrated effective detection capabilities, but at a cost of performance degradation and software side effects. In this paper we introduce our solution to these problems, an SMM-based Extensible, Performance Aware Runtime Integrity Measurement Mechanism called EPA-RIMM. The EPA-RIMM architecture features a performance-sensitive design that decomposes large integrity measurements and schedules them to control perturbation and side effects. EPA-RIMM’s decomposition of long-running measurements into shorter tasks, extensibility, and use of SMM complicates the efforts of malicious code to detect or avoid the integrity measurements. Using a Minnowboard-based prototype, we demonstrate its detection capabilities and performance impacts. Early results are promising, and suggest that EPA-RIMM will meet production-level performance constraints while continuously monitoring key OS and hypervisor data structures for signs of attack.
Intel® NUC BIOS SW SMI Call-Out
Intel ID: INTEL-SA-00110
Product family: Intel® NUC Kits
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Original release: Apr 17, 2018
Last revised: Apr 17, 2018
Summary:
This update will improve the security of system firmware for the below listed Intel NUC models. Intel has identified a potential vulnerability in Intel NUC kits with insufficient input validation in system firmware that potentially allows a local attacker to elevate privileges to System Management Mode (SMM). Intel highly recommends that users update to the latest firmware version (see table above).
Intel would like to thank Embedi for reporting this issue and working with us on coordinated disclosure.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00110&languageid=en-fr
Aurora: Providing Trusted System Services for Enclaves On an Untrusted System
Hongliang Liang, Mingyu Li, Qiong Zhang, Yue Yu, Lin Jiang, Yixiu Chen
(Submitted on 10 Feb 2018)
Intel SGX provisions shielded executions for security-sensitive computation, but lacks support for trusted system services (TSS), such as clock, network and filesystem. This makes \textit{enclaves} vulnerable to Iago attacks~\cite{DBLP:conf/asplos/CheckowayS13} in the face of a powerful malicious system. To mitigate this problem, we present Aurora, a novel architecture that provides TSSes via a secure channel between enclaves and devices on top of an untrusted system, and implement two types of TSSes, i.e. clock and end-to-end network. We evaluate our solution by porting SQLite and OpenSSL into Aurora, experimental results show that SQLite benefits from a \textit{microsecond} accuracy trusted clock and OpenSSL gains end-to-end secure network with about 1ms overhead.
The below video was uploaded recently. The previous talk was from a few years ago. I’m unclear if this video is new or from a few years ago…
The emergence of hardware virtualization technology has led to the development of OS independent malware such as the Virtual Machine based rootkits (VMBRs). In this paper, we draw attention to a different but related threat that exists on many commodity systems in operation today: The System Management Mode based rootkit (SMBR). System Management Mode (SMM) is a relatively obscure mode on Intel processors used for low-level hardware control. It has its own private memory space and execution environment which is generally invisible to code running outside (e.g., the Operating System). Furthermore, SMM code is completely non-preemptible, lacks any concept of privilege level, and is immune to memory protection mechanisms. These features make it a potentially attractive home for stealthy rootkits. In this paper, we present our development of a proof of concept SMM rootkit. In it, we explore the potential of System Management Mode for malicious use by implementing a chipset level keylogger and a network backdoor capable of directly interacting with the network card to send logged keystrokes to a remote machine via UDP. The rootkit hides its memory footprint and requires no changes to the existing Operating System. It is compared and contrasted with VMBRs. Finally, techniques to defend against these threats are explored. By taking an offensive perspective we hope to help security researchers better understand the depth and scope of the problems posed by an emerging class of OS independent malware.
https://dl.acm.org/citation.cfm?id=1460892
http://clearhatconsulting.com/index.php/papers/
I’m not sure if this is a new change, but I just noticed that the Intel System Debugger appears to have some fresh documentation:
https://software.intel.com/node/744419
Common Debugger Tasks
* Viewing and Modifying Registers
* Execution Trace
* Debugging UEFI BIOS
* Debugging Runtime Loaded Linux* OS Kernel Modules
* Debugging System Management Mode (SMM)
* Programming a Flash Memory
CVE-2017-5721 Proof-of-Concept
UsbRt SMM Privilege Elevation
This is a Proof-of-Concept code that demonstrates the exploitation of the CVE-2017-5721 vulnerability. This PoC causes a system to be completely stuck because of Machine Check Exception occurred.
All you need is CHIPSEC Framework installed. And don’t forget to put GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash acpi=off” in /etc/default/grub if you have Intel device.
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).
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.
First Online: 12 October 2017
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10453)
The growing reliance on cloud-based services has led to increased focus on cloud security. Cloud providers must deal with concerns from customers about the overall security of their cloud infrastructures. In particular, an increasing number of cloud attacks target resource allocation in cloud environments. For example, vulnerabilities in a hypervisor scheduler can be exploited by attackers to effectively steal CPU time from other benign guests on the same hypervisor. In this paper, we present Scotch, a system for transparent and accurate resource consumption accounting in a hypervisor. By combining x86-based System Management Mode with Intel Software Guard Extensions, we can ensure the integrity of our accounting information, even when the hypervisor has been compromised by an escaped malicious guest. We show that we can account for resources at every task switch and I/O interrupt, giving us richly detailed resource consumption information for each guest running on the hypervisor. We show that using our system incurs small but manageable overhead—roughly 1 μ
s every task switch or I/O interrupt. We further discuss performance improvements that can be made for our proposed system by performing accounting at random intervals. Finally, we discuss the viability of this approach against multiple types of cloud-based resource attacks.
https://link.springer.com/chapter/10.1007/978-3-319-66332-6_18
Lenovo says scope of AMI issue is “Industry-Wide”, which implies that other Intel/AMI-based OEMs may also have this issue, not just Lenovo.
BIOS SMI Handler Input Validation Failures
CVE Identifier: CVE-2017-3753
Lenovo Security Advisory: LEN-14695
Severity: High
Scope of Impact: Industry-Wide
Last Modified: 08/09/2017
Potential Impact: Execution of code in SMM by an attacker with local administrative access
A vulnerability has been identified in some Lenovo products that use UEFI code developed by AMI. With this vulnerability, conditions exist where an attacker with administrative privileges or physical access to a system may be able to run specially crafted code that can allow them to bypass system protections such as Device Guard and Hyper-V. AMI has supplied a fix for this vulnerability to Lenovo. Users should update the BIOS on affected systems to the latest available version to address this issue.
Security-conscious users should consider the following mitigation steps if an immediate BIOS update is not possible to protect themselves to the fullest extent with the understanding that they DO NOT fix or fully protect against an exploit of this vulnerability:
* Enable Secure Boot on your system
* Disable the boot to UEFI shell
* Disable boot from any source but the primary internal hard drive
* Set a BIOS setup password, so Secure Boot cannot be disabled and the boot to the UEFI shell cannot be re-enabled
* Operate as an unprivileged (non-administrator)
https://nvd.nist.gov/vuln/detail/CVE-2017-3753
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3753
https://support.lenovo.com/us/en/product_security/len-14695
AFAICT nothing on the AMI site on this.
A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:
The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.
https://github.com/gencymex/smmtestbuildscript
[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/
[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Firmware Security 
You must be logged in to post a comment.