Lee Leahy and Vincent Zimmer of Intel gave a presentation on the coreboot payload package of UEFI:
EDK-II & CorebootPayloadPkg: Lee Leahy, Vincent Zimmer
Tag: Intel
Intel on Intel FSP 2.0 and coreboot
Giri Mudusuru and Vincent Zimmer of Intel gave a presentation with an overview of Intel FSP 2.0:
new EFI search features added to CHIPSEC
There’s a stream of new of checkins added to CHIPSEC, these last few weeks.
post-1.2.3-CHIPSEC updates
CHIPSEC has had a few updates since the recent 1.2.3 release, see commit history and recent Tweet:
Intel Graphics Driver for Windows: EOP vulnerability
Intel has released a security advisory for Intel Graphics Drivers for Windows. Excerpted announcement:
Multiple Potential Vulnerabilities in the Intel® Graphics Driver for Microsoft Windows
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Multiple potential vulnerabilities exist in the Intel® Graphics Driver for Microsoft Windows impacting versions prior to 28MAR2016. The vulnerabilities can lead to a privilege escalation or denial of service condition. Intel highly recommends that customers of the affected products obtain and apply the latest versions of the driver. Discovered by Piotr Bania of Cisco Talos
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00054&languageid=en-fr
https://downloadcenter.intel.com/product/80939/Graphics-Drivers
http://www.talosintelligence.com/reports/TALOS-2016-0087/
Intel on Intel ME backdoors
Steve Grobman of Intel has a new blob post which talks about — amongst other things — concerns of backdoors in the Intel Management Engine.
CHIPSEC 1.2.3 released!
Excerpt of CHIPSEC 1.2.3 release notes:
New/updated modules:
* tools.vmm.vbox_crash_apicbase — test for CVE-2015-0377
* udated common.bios_ts, common.uefi.s3bootscript, remap
* added template config file smm_config.ini for tools.smm.smm_ptr SMI fuzzer
* added template config file te.cfg for tools.secureboot.te tool
New/improved functionality:
* Added basic TPM access and TPM 1.2 support
hal/tpm.py and hal/tpm12_commands.py HAL components
* Added basic Embedded Controller (EC) support
hal/ec.py HAL component and chipsec_util ec util
* Added processing of x86 paging hierarchy
hal/paging.py and hal/cpu.py HAL components and chipsec_util cpu pt util
* Added processing of Second Level Address Translation paging hierarchy (EPT)
hal/vmm.py HAL component and chipsec_util vmm pt util
* Added processing of IOMMU (VT-d) paging hierarchy
hal/iommu.py HAL component and chipsec_util iommu pt util
* Basic support for hypervisor hypercall interfaces
hal/vmm.py HAL component and chipsec_util vmm hypercall util
* Added message bus interface for Atom SoC (Linux)
hal/msgbus.py HAL component and chipsec_util msgbus util
* CPUID functionality moved from hal/cpuid.py to hal/cpu.py HAL component
Use chipsec_util cpu cpuid util
* Added parsing of RAW images in UEFI firmware volumes
* Updated smbus and SPD HAL components to use XML config
* Added qrk.xml configuration file for Quark CPUs, updated configuration for Haswell Server (hsx.xml)
* Fixed location of MMCFG in server platforms. Results from prior versions may need to be recollected on server platforms.
See full release notes for list of bugfixes.
ACPI/APEI BERT support for Linux
Tony Luck of Intel submitted a patch to the Linux (Kernel,ACPI) lists, to add ACPI BERT (Boot Error Record Table) support to the Linux kernel. The original patch appears to be from Huang Ying of Intel, I think.
New Linux kernel parameter:
bert_disable: Disable BERT OS support on buggy BIOSes.
Excerpting comments from the patch:
ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
The following log is a BERT record after system reboot because of hitting a fatal memory error:
BERT: Error records from previous boot:
[Hardware Error]: It has been corrected by h/w and requires no further action
[Hardware Error]: event severity: corrected
[Hardware Error]: Error 0, type: recoverable
[Hardware Error]: section_type: memory error
[Hardware Error]: error_status: 0x0000000000000400
[Hardware Error]: physical_address: 0xffffffffffffffff
[Hardware Error]: card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
[Hardware Error]: error_type: 2, single-bit ECC
For more information, see the patch message thread on the Linux-kernel list:
http://vger.kernel.org/majordomo-info.html
Intel releases SGX for Linux!
Intel SSD vulnerability
Intel Security Center reports a vulnerability in some Intel SSD drives. See the full announcement for model specifics.
Vulnerability impacting the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series drives
Intel ID: INTEL-SA-00053
Product family: Intel® Solid-State Drive Consumer, Embedded and Data Center
Impact of vulnerability: Elevation of Privilege
Severity rating: Moderate
Original release: Jun 14, 2016
A vulnerability was identified in the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series leading to a potential data corruption issue. A vulnerability was identified in the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series leading to a potential data corruption issue. This may occur If the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series or Intel® Solid State Drive DC S3100 Series drives receive a read or write command during ATA security locked state. Intel has not received any reports of any Intel SSD products having experienced this issue. Intel strongly recommends that customers with the listed products download and apply the mitigated firmware version using the update source outlined above.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00053&languageid=en-fr
BoingBoing on Intel ME
Damien Zammit has a new post on BoingBoing:
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they’ll expose all affected systems to nearly unkillable, undetectable rootkit attacks. I’ve made it my mission to open up this system and make free, open replacements, before it’s too late. […]
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
Fall UEFI Forum plugfest is in September in Seattle
ASUS UEFI Update Driver Physical Memory Read/Write
“A short while ago, slipstream/RoL dropped an exploit for the ASUS memory mapping driver (ASMMAP/ASMMAP64) which was vulnerable to complete physical memory access (read/write) to unprivileged users, allowing for local privilege escalation and all sorts of other problems. An aside to this was that there were also IOCTLs available to perform direct I/O operations (in/out instructions) directly from unprivileged usermode, which had additional interesting impacts for messing with system firmware without triggering AV heuristics.
[…]
In addition to the ASMMAP bugs, I also reported the exact same bugs in their UEFI update driver (AsUpIO.sys). This driver is deployed as part of the usermode UEFI update toolset, and exposes almost identical functionality which (as slipstream/RoL pointed out) is likely from an NT3.1 example driver that was written long before Microsoft took steps to segregate malicious users from physical memory in any meaningful way.”
[…]
a bit more on Intel CET
http://blogs.intel.com/evangelists/2016/06/09/intel-innovating-stop-cyber-attacks/
https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
The GRSecurity post has a few more links as well:
[…]
Full disclosure: we have a competing production-ready solution to defend against code reuse attacks called RAP, see [R1], [R2]. RAP isn’t tied to any particular CPU architecture or operating system, and it scales to real-life software from Xen to Linux to Chromium with excellent performance.
[…]
Conclusion
In summary, Intel’s CET is mainly a hardware implementation of Microsoft’s weak CFI implementation with the addition of a shadow stack. Its use will require the presence of Intel processors that aren’t expected to be released for several years. Rather than truly innovating and advancing the state of the art in performance and security guarantees as RAP has, CET merely cements into hardware existing technology known and bypassed by academia and industry that is too weak to protect against the larger class of code reuse attacks. One can’t help but notice a striking similarity with Intel’s MPX, another software-dependent technology announced with great fanfare a few years ago that failed to live up to its many promises and never reached its intended adoption as the solution to end buffer overflow attacks and exists only as yet another bounds-checking based debugging technology.
Intel CET
https://twitter.com/aionescu/status/741035301246783488
Intel release new technology specifications to protect against ROP attacks
By Baiju Patel on June 9, 2016
“Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections, Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known JOP) are two such techniques that has been gaining popularity. ROP or JOP attacks are particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.
Intel and Microsoft recognized the seriousness of ROP attacks as well as the difficulty in developing the means to protect from ROP/JOP. Together, we considered over ten technology innovations to address these emerging threats over last 7 years and narrowed it down to the CET specification for x86/x64 architecture to make significant advances in addressing the ROP threat. Based on prior experience with defining instruction set extensions, and enabling challenges associated with a new ISA, we set goals to have an ISA for ROP/JOP prevention that is transparent to most well designed/implemented software requiring minimal to no changes; yet allow opt out capability for SW that requires changes. We also wanted to make sure that the solution is applicable to not just applications, but also to operating system kernels, and is beneficial to SW written using most programming languages. We also wanted to ensure that software enabled for CET works on legacy platforms without changes (albeit with no security benefits). Finally, and most importantly, we wanted to address all known ROP/JOP attacks.
While we include a brief description of CET here, there is no substitute for careful reading of the complete specification. Here we highlight two key aspects of ISA to get you started, namely, shadow stack and indirect branch tracking. It is the combination of these two that are designed to address both ROP and JOP class of attacks. […]”
CHIPSEC updates
The CHIPSEC team have tweeted about an upcoming 1.2.3 release with more Xen, Hyper-V, IOMMU, EPT support.
Also, Yuriy Bulygin of the Intel CHIPSEC team has posted some videos of their REcon training showing CHIPSEC usage:
https://github.com/chipsec/chipsec
It looks like their last checkin to the public git repo was in April:
https://github.com/chipsec/chipsec/commits/master
new Intel FSP 2.0 documents available
Vincent Zimmer of Intel UEFI has posted TWO blog posts, to catch up to.
In the first, he point out some newly-released Intel FSP 2.0 documents:
https://firmware.intel.com/blog/how-build-it
https://firmware.intel.com/develop
In the second, he talks about UEFI history, focused on the 2 editions of the Beyond BIOS book (and the recent UEFI reference book in comic book pop culture).
http://vzimmer.blogspot.com/2016/06/shields-and-networks.html
PS: Intel Press, the web pages (including errata) for the Beyond BIOS 2nd Edition and UEFI Shell books are broken. It sucks to have an $80 book with a broken web site. Nothing personal, it seems most tech book publishers are terrible at persistant web sites and ‘cool URIs’. 😦
Intel X[L]710 Ethernet controlllers have NVMe firmware exploit
Intel’s Security Center has a new advisory about Intel Ethernet Controller X710 and XL710 with their NVM image, excerpted below. Update is available.
Strangely, it is from yesterday (May 2016), but copyrighted 2013.
NVMe trade group: Where is the NVMe firmware equivalent of CHIPSEC? Where are the NVMe security tools? 😦
Potential vulnerability in the Intel® Ethernet Controller X710 and XL710 product families
Intel ID: INTEL-SA-00052
Product family: Intel® Ethernet Controller X710 and XL710 Product Families
Impact of vulnerability: Denial of Service
Severity rating: Important
Original release: May 31, 2016
A vulnerability was identified in the Intel Ethernet Controller X710 and XL710 product family NVM image v5.02 and v5.03. Intel released an update to mitigate this issue on 31MAY2016. Intel has found a security vulnerability in the v5.02 and v5.03 release of the NVM images for the Intel® Ethernet Controller X710 and XL710 family. Intel has released a v5.04 NVM image to mitigate this issue. This update is available to customers through the Intel Download Center. Intel highly recommends that customers of the affected products obtain and apply the updated versions of the NVM image through the Intel Download Center at (https://downloadcenter.intel.com/download/24769).
(C) 2013, Intel Corporation
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00052&languageid=en-fr
Sogeti ESEC: SMM unchecked pointer vulnerability
[Update: SMM driver dev advice for this from issue is here:
]
Bruno of Sogeti ESEC Lab has published an interesting paper with an SMM exploit, well-written with lots of background on UEFI and SMM exploits, lots of images/figures and links, definately worth reading:
SMM unchecked pointer vulnerability
Mon 30 May 2016 by Bruno
This article explains the exploitation of an SMM unchecked pointer vulnerability present in several firmwares. As this vulnerability is a memory corruption, it only applies to firmwares including the unpatched vulnerable DXE driver. It first explains the SMM mode and some of its mechanisms, then the reversing of the UEFI driver in which the vulnerability is present, then the exploitation of the vulnerability in it-self and finally a little conclusion about the impact of the vulnerability. […]
This vulnerability was initially found on two different firmwares of different OEM, both of them seem to have a lot in common. Their firmware were based on one version of the EDK implementation by Intel with several new features added. After some research it appears that both were using code provided by American Megatrends Inc. (AMI) . We contacted AMI and the OEM and got quick responses from them. We would like to thank them for working with us, especially Lenovo for coordinating with us. […]
This vulnerability allows to gain code execution in SMM. In the case of both studied firmwares the flash was not protected by the Protected Range (PR) registers, code execution in SMM allows rewriting the flash and potentially the setup of a persistent bootkit.
On January 2016 VirusTotal (VT) began to provide information on firmware images as described in their blog post . We used this for finding firmware which includes the SMIFlash driver. In total we found approximately 900 different firmwares (type:rom) which contains it, 468 of those had different versions, however it is likely that a lot of these firmwares are just different versions of one another. We have gathered the Vendor identification provided by VT for each of those firmware and got approximately 10 different constructors however 84% of the firmwares have AMI as vendor. […]
http://esec-lab.sogeti.com/posts/2016/05/30/smm-unchecked-pointer-vulnerability.html
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:
Firmware Security 
You must be logged in to post a comment.