Intel porting KGT to UEFI

The other day I learned about Intel KGT:

Intel KGT

Then I noticed Matthew Garrett’s twitter feed, saying that it didn’ t work with UEFI… But today I note that Vincent Zimmer of Intel has a new Twitter post,  saying that Intel is working on porting KGT to work with UEFI:

Looking forward to UEFI-enabled iKGT!

Phoenix quiet these years

A quick personal note to Phoenix, one of the big IBVs:

Is everything ok at Phoenix? Or is it that you’re doing so good these days you don’t need to keep the public informed of your company’s activities? It is nice to see talks at UEFI Forum meeetings, but please get someone to update your blogs and press release pages. Your press release and event pages haven’t been updated since 2013. Your blog hasn’t been updated since 2010. Even Tim Lewis’  of Phoenix’s personal blog hasn’t  been updated since 2014. If this kind of interactivity with the public is an indication, I’m worried about the next firmware security update that impacts Phoenix systems, if nobody is updating things there anymore. Thanks!

http://www.phoenix.com/pages/news-events/
http://www.phoenix.com/pages/upcoming-events
http://blogs.phoenix.com/

Firmware patents….

SPOILER ALERT: This post discusses patents. If you’re an employee at a company, ask your manager if you’re able to read this sort of information…..
.
.
.

I wonder how bad it’s going to get with firmware patents… Searching the patent databases, I find THOUSANDS with ‘firmware’, HUNDREDS with ‘UEFI’, and dozens with ‘coreboot’, and many for ACPI. For example, it appears that Microsoft has patented the ability to securely update firmware:

Microsoft: Secure Firmware Updates
US 20140068585 A1, CN 104603792 A, US 8898654 B2

This is just one example, all of the big OEMs, IHVs, and ISA vendors have patents left and right in this space. 😦

Are vendors able to build UEFI — or even coreboot — systems without lawyers from some of the big companies knocking on their door asking for royalties? Where is the firmware equivalent of the “Open Invention Network”, to help smaller vendors even use basic firmware functionality with lawyers looking to monetize everything? I wonder if the Maker movement or Open Hardware or Free Hardware is going to be able to survive this.

Intel ATR on firmware security threats

Jim Walter, Director of Advanced Threat Research for Intel Security, with contributions from Yuriy Bulygin and John Loucaides, wrote a blog for Dark Reading that summarizes some recent firmware attacks.

Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware
Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks.

Read the full article here:

http://www.darkreading.com/partner-perspectives/intel/vulnerable-from-below-attacking-hypervisors-using-firmware-and-hardware/a/d-id/1321834

 

 

Intel ITS

Intel has a device to help with UEFI testing, the Intelligent Test System (ITS). ITS may have been around for a while, but I just noticed it on the Intel firmware web site. I’m presuming for now that it’s new from IDF, but I may be wrong about that. If you do UEFI testing, you might want to look at this device.

https://firmware.intel.com/learn/its/intel-its

https://designintools.intel.com/product_p/q6ujitshub001.htm

I wonder how it compares to Linaro’s LAVA. LAVA does mostly target ARM devices, but does also target Intel via QEMU, perhaps there are direct Intel targets these days.

https://validation.linaro.org/

Intel announces STM at IDF

Intel just announced STM at IDF, read Vincent’s blog for more details:

http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html

https://firmware.intel.com/content/smi-transfer-monitor-stm

https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip

Click to access A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf

Click to access STM_User_Guide-001.pdf

tool mini-review: RWEverything

RW, aka RWEverything (Read and Write Everything) is a GUI Windows-based firmware utility, written by Jeff.

“This utility access almost all the computer hardware, including PCI (PCI Express), PCI Index/Data, Memory, Memory Index/Data, I/O Space, I/O Index/Data, Super I/O, Clock Generator, DIMM SPD, SMBus Device, CPU MSR Registers, ATA/ATAPI Identify Data, Disk Read Write, ACPI Tables Dump (include AML decode), Embedded Controller, USB Information, SMBIOS Structures, PCI Option ROMs, MP Configuration Table, E820, EDID and Remote Access. And also a Command Window is provided to access hardware manually. Powerful utility for hardware engineers, firmware (BIOS) engineers, driver developers, QA engineers, performance test engineers, diagnostic engineers, etc.”

“This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial products.”

RW supports multiple Super I/O devices (Winbond (18), ITE (12), SMSC (8), FinTek (4), Nuvoton (6)) and SMBus Controllers (Intel (9), SiS (6), VIA (4), ULi (4), ATI (3), nVidia (13)).

It is Windows-centric utility, shipping with Win32 or Win64 binaries. It has an extensive ChangeLog, spanning v1.6.8 from 8/6/2015 to v0.1 back around 2005, but does not ship with any documentation, just EXEs. If you use Windows, you might want to check this out. If you find the tool useful, the author has a Donate button on his home page, please consider donating to the program’s author. I wish the tool was open source, and supported multiple operating systems, …but I’ll take what I can get. Thanks Jeff!

Home

Supported Hardware

Download

tool mini-review: Read Universal utility (RUEXE)

[Correction: the .EXE is for MS-DOS, not for Windows.]

Feedback from a very smart reader:

“The Read Universal utility is a Swiss-Army-Knife for BIOS debugging, the tools that provides direct access to almost all resources like memory, IO space, PCI, SMBIOS data, UEFI variables and so on. The tool is written by AMI’s UEFI engineer James Wang.”

James site say: “I wrote RU.EXE for debugging BIOS problems in 1993. It was a simple tool but it turns out to be too complex now. And yes, I am still working for a BIOS company.”

The release includes MS-DOS-based ru.exe and UEFI-based ru.efi binaries. AFAICT, there are no sources on Google Code, it looks like this is a closed-source freeware tool. The release page for each release includes a password. Read the blog for multiple articles that describe new features.
[I’m just learning about this tool, obviously. I’ve been using open source tools for so long that I’m a bit nervous about using closed-source freeware binaries, but recommendation is from someone smart, so I’m setting up a safe environment to learn to use this tool. 🙂 ]

http://ruexe.blogspot.de/
https://code.google.com/p/ru-uefi/

Interview with LegbaCore (and: their OpROM checker ships!)

A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):

Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
    The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.

Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give FirmwareSecurity.com a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.

Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.

Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments

Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, bios_diff.py tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While bios_diff.py continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.

Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.

Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.

Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.

—-[End of interview.]

Thanks Corey and Xeno!
Links:

<blink>THEIR OPROM CHECKER IS RELEASED!</blink>
The code was added 5 days ago, and I missed it!
https://github.com/legbacore/t2e_integrity_check

Upcoming training:
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/
https://ruxconbreakpoint.com/training/bios/
http://www.legbacore.com/Training.html

Stephan’s comment on coreboot security:

Intel Boot Guard

Intel Boot Guard

As defined by Wikipedia: “Intel Boot Guard is a processor feature that prevents the computer from running firmware images not released by the system manufacturer. When turned on, the processors verifies a signature contained in the firmware image before executing it, using the hash of the public half of the signing key, which is fused into the system’s Platform Controller Hub (PCH) by the system manufacturer (not by Intel). Intel Boot Guard is an optional processor feature, meaning that it does not need to be activated during the system manufacturing. As a result, Intel Boot Guard, when activated, makes it impossible for end users to install replacement firmware such as Coreboot.

Boot Guard attempts to protect the system before Secure Boot starts. Boot Guard is a big new player in the security -vs- user-control equation. To conserve words, I’ll just point to a few other blog posts on this topic by others:

http://patrick.georgi-clan.de/2015/02/17/intel-boot-guard/
https://hacked.com/quick-hack-bios-passwords-computer/
https://mjg59.dreamwidth.org/33981.html
https://news.ycombinator.com/item?id=9135767
http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modiying-your-pcs-firmware.html

Security must be addressed, but the cost might be General Purpose Computing?

Lockdown: The coming war on general-purpose computing


http://readwrite.com/2012/01/13/the-four-horsemen-of-the-gener
https://github.com/jwise/28c3-doctorow/blob/master/transcript.md

I hope Intel — or other chip vendors — can help both audiences, not only enterprise vendors who want to use the OEM’s installation of Windows and never change their systems. The locally-present user should be able to override features like this, and install what they want, at firmware, pre-OS and OS-level software. Some systems may need to be tamper-resistant to local users, but that’s just for enterprise bank employees, not for citizens. Intel: please give us more control over the products we purchase.

Lenovo LSE, WPBT and wpbbin.exe

UPDATE: See-also:

WPBT attacks from the past: Alex at SyScan12

What’s the next built-in ACPI attack?

US-CERT: Lenovo Service Engine (LSE) BIOS Vulnerability

Lenovo Service Engine

An interesting find, potentialy scary if misused. See the Ars Technical and YCombinator stories for discovery. What is Windows’ ‘wpbbin.exe’, and how/when is it used? There’s one reference to it on Microsoft.com in a DOC related to WPBT, the Windows Platform Binary Table. From one document no longer on the Microsoft web site (saved in Google cache, found on the Ars article):

A rich set of tools exist to aid Windows provisioning, ranging from driver injection and offline registry management to sysprep imaging tools.  However, there is a small set of software where the tools are not enough.  The software is absolutely critical for the execution of Windows but for one reason or another, the vendor is unable to distribute the software to every provisioning entity.  This paper describes a mechanism for a platform, via the boot firmware, to publish a binary to Windows for execution.  The mechanism leverages a boot firmware component to publish a binary in physical memory described to Windows using a fixed ACPI table. The information provided here was originally published in conjunction with the availability of Windows 8. The guidance and requirements to use WPBT functionality has been updated for the Windows 10 timeframe.

https://www.google.com/?gws_rd=ssl#q=wpbbin.exe+site:microsoft.com
http://arstechnica.com/civis/viewtopic.php?p=29497693&sid=ddf3e32512932172454de515091db014#p29497693
https://news.ycombinator.com/item?id=10039870
https://lkml.org/lkml/2015/5/20/1155
https://www.microsoft.com/en-us/download/details.aspx?id=38405

Found while researching the above: Lenovo has security updates for LSE:

LEN 2015-077: Lenovo Service Engine (LSE) BIOS for Desktop
LEN-2015-020: Lenovo Service Engine (LSE) BIOS for Notebook

Lenovo Security Advisory: LEN-2015-020
Potential Impact: Privilege Escalation
Severity: High
Summary: Vulnerabilities have been identified in the Lenovo Service Engine (LSE). Lenovo has released a BIOS update to disable Lenovo Service Engine and a utility to remove services and files left on the system for systems running Windows 7, 8, 8.1 and 10. See below for a full list of notebook systems with LSE installed. 

https://support.lenovo.com/us/en/product_security/lse_bios_notebook
https://support.lenovo.com/us/en/product_security

Post-Domas Intel BIOS update

Intel has released some BIOS updates after Domas’ recent vulnerability:

Domas’ x86 vulnerability

Title: Local APIC Elevation of Privilege
Intel ID: INTEL-SA-00045
Impact of vulnerability: Elevation of Privilege
Severity rating:  Important
Original release:  Aug 04, 2015

Intel is releasing mitigations for a privilege escalation issue. This issue affects certain Intel processors based on older Intel micro-architectures. The issue identified is a method that enables malicious code to gain access to SMM. An issue was disclosed to Intel which leverages architectural differences in processors prior to 2nd Generation Intel Core Processors to gain access to SMM. Administrator or root level privileges are required to execute the attack.
 
Affected products: Intel Server Board S5500BC, Intel Server Board S5500HCV, Intel Server Board S5500HV, Intel Server Board S5500WB, Intel Server Board S5520HC, Intel Server Board S5520HCT, Intel Server Board S5520UR, Intel Workstation Board S5520SC
    
Intel highly recommends applying the mitigations.
 
Intel would like to acknowledge Christopher Domas of Battelle for working with us on this coordinated disclosure.

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

Genode OS v15.05

Found on Joanna’s Twitter feed:
https://twitter.com/rootkovska/status/629256162706329601

Genode is new to me. Genode Labs makes the “Genode OS Framework”. Genode is a new OS, not a new Linux distribution. It is “a GPLv2-licensed construction kit for building specialized operating systems out of small building blocks including different kernels, device drivers, protocol stacks, and applications”. This current release is a major release for Genode. The new documentation is a large 472 page PDF. The current release adds “rudimentary GPT” support. GPT aside, I don’t see any other UEFI-related technology support, only “BIOS” references to firmware.

Version 15.05 represents the most substantial release in the history of Genode. It is packed with profound architectural improvements, new device drivers, the extension of the supported base platforms, and a brand new documentation.

We understand the complexity of code and policy as the most fundamental security problem shared by modern general-purpose operating systems. Because of high functional demands and dynamic workloads, however, this complexity cannot be avoided. But it can be organized. Genode is a novel OS architecture that is able to master complexity by applying a strict organizational structure to all software components including device drivers, system services, and applications.”

“The current implementation can be compiled for 8 different kernels: Linux, L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom kernel for running Genode directly on ARM-based hardware. Whereas the Linux version serves us as development vehicle and enables us to rapidly develop the generic parts of the system, the actual target platforms of the framework are microkernels. There is no ‘perfect’ microkernel – and neither should there be one. If a microkernel pretended to be fit for all use cases, it wouldn’t be ‘micro’. Hence, all microkernels differ in terms of their respective features, complexity, and supported hardware architectures.

Genode allows the use of each of the kernels listed above with a rich set of device drivers, protocol stacks, libraries, and applications in a uniform way. For developers, the framework provides an easy way to target multiple different kernels instead of tying the development to a particular kernel technology. For kernel developers, Genode contributes advanced workloads, stress-testing their kernel, and enabling a variety of application use cases that would not be possible otherwise. For users and system integrators, it enables the choice of the kernel that fits best with the requirements at hand for the particular usage scenario.

Inverse Path’s USB Armoury supports Genode as of 15.02:  “The Genode OS Framework supports the USB armory since version 15.02 implementing a TrustZone Secure virtual-machine monitor (VMM) supervising Linux running in the Normal world. Support is in the very early stages. The Linux kernel requires minimal patching to be executed in the Normal world, at the moment Martin Stein from Genode Labs provides a repository with a patched kernel.

http://genode.org/documentation/release-notes/15.05
https://github.com/genodelabs/genode
http://sourceforge.net/projects/genode/files/

No Starch Press: Rootkits and Bootkits

[Wow!]

Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats
by Alex Matrosov, Eugene Rodionov, and Sergey Bratus

Spring 2016, 304 pp.
ISBN: 978-1-59327-716-1
$39.95 EARLY ACCESS Ebook
$49.95 Print Book and EARLY ACCESS Ebook

Get 30% off with the coupon code EARLYBIRD

Modern malware is always evolving because malware authors are constantly finding new ways to bypass security and avoid detection. Defending against (and even discovering) the latest malicious software requires cunning and extensive expertise because attackers have become much more sophisticated.

One particularly fascinating and threatening area of malware development is that of rootkits and bootkits. We’re talking hard stuff – attacks buried deep in a machine’s boot process or firmware. These are the kind of attacks that keep malware analysts up late at night. But help is on the way.

In Rootkits and Bootkits, authors Alex Matrosov, Eugene Rodionov, and Sergey Bratus share the knowledge and expertise they’ve gained during years of professional research. You’ll learn how to expose hidden files systems that can make rootkits so hard to identify and remove. You’ll explore how malware has evolved from rootkits like TDL3 to the present; how this stealthy software can take hold of a system; and how to counter anti-debugging, anti-disassembly, and anti-virtual machine measures. You’ll also learn how bootkits work, and how Windows boots so that you can better prevent infections in the first place.

Cybercrime syndicates and malicious actors keep pushing the envelope, writing ever more persistent and covert attacks. But the game is not lost. In this low-level tour through the wilds of malware, you’ll learn how to reverse next generation threats. Explore the cutting edge of malware analysis with Rootkits and Bootkits.
About the Author

Alex Matrosov has more than 10 years experience with malware analysis, reverse engineering and advanced exploitation techniques. He is a senior security researcher in the Advanced Threat Research team at Intel Security Group and prior to this role, he spent four years focused on advanced malware research at ESET. Matrosov is co-author of numerous research papers including Stuxnet Under the Microscope, and is frequently invited to speak at major security conferences such as REcon, ZeroNights, Black Hat and Virus Bulletin.

Eugene Rodionov, PhD, graduated with honors from the Information Security faculty of the Moscow Engineer-Physics Institute. He currently works at ESET, where he is involved with internal research projects and performs in-depth analysis of complex threats. His interests include kernel-mode programming, anti-rootkit technologies and reverse engineering. Rodionov has spoken at security conferences such as REcon, Virus Bulletin, ZeroNights, CARO and AVAR, and has co-authored numerous research papers.

Sergey Bratus is a Research Associate Professor in the Computer Science Department at Dartmouth College. He has previously worked at BBN Technologies on Natural Language Processing research. Bratus is interested in all aspects of Unix security, in particular in Linux kernel security, and detection and reverse engineering of Linux malware.

Table of Contents
Introduction
Part 1: ROOTKITS
Chapter 1: What’s in a Rootkit: The TDL3 Case Study (NOW AVAILABLE)
Chapter 2: Festi Rootkit: The Most Advanced Spam Bot
Chapter 3: Observing Rootkit Infections
Chapter 4: Rootkit Static Analysis: IDA Pro
Chapter 5: Rootkit Dynamic Analysis: WinDbg
Part 2: BOOTKITS
Chapter 6: Bootkit Background and History (NOW AVAILABLE)
Chapter 7: The Windows Boot Process: Bringing Up a System in a Trustworthy State (NOW AVAILABLE)
Chapter 8: From Rootkits (TDL3) to Bootkits (TDL4): Bypassing Microsoft Kernel-Mode Code Signing Policy (NOW AVAILABLE)
Chapter 9: Operating System Boot Process Essentials (NOW AVAILABLE)
Chapter 10: Static Analysis of a Bootkit Using IDA Pro (NOW AVAILABLE)
Chapter 11: Bootkit Dynamic Analysis: Emulators and Virtual Machines
Chapter 12: Evolving from MBR to VBR Bootkits: Mebromi & Olmasco
Chapter 13: VBR Bootkits: Rovnix & Carberp
Chapter 14: Gapz: Advanced VBR Infection
Chapter 15: UEFI Boot vs. MBR/VBR
Chapter 16: Contemporary UEFI Bootkits
Part 3: DEFENSE AND FORENSIC TECHNIQUES
Chapter 17: How Secure Boot Works
Chapter 18: HiddenFsReader: Bootkits Forensic Approaches
Chapter 19: CHIPsec: BIOS/UEFI Forensics
Part 4: ADVANCED REVERSE ENGINEERING
Chapter 20: Breaking Malware Cryptography
Chapter 21: Modern C++ Malware Reversing
Chapter 22: HexRaysCodeXplorer: Practical C++ Code Reconstruction

https://www.nostarch.com/rootkits

Recapping Marek’s Jan2015 AMD security vulnerability

[I’m pretty dumb when it comes to AMD systems. 😦 I am just catching up to what most of the rest of the world knows about their technology, and security. I asked on the EDK2-devel mailing list for a clue on AMD’s firmware strategy, and Gary Simpson of AMD was kind enough to answer my questions. I’ll post a version of his answers in an upcoming blog, in the mean time look on the edk2-devel archives on 7/31 for his message. I’m still trying to understand some of the answers from AMD, from firmware development perspective, mainly AGSEA and how it works. Much more on this in future blog posts. In the mean time, I’m also catching up to AMD silicon/firmware security, and the most recent public story appears to be from January:]

Back in January of this year, there were a few stories on one AMD firmware vulnerability, reported last April, fixed last November, reported at December’s Chaos Communications Congress. At 31C3, Rudolf Marek, a Czech programmer, gave a presentation about a security vulnerability on AMD’s x86 chips, insufficient security checks before execution allows malware injection. AMD’s Mullins, Beema, Temash, Trinity, Richland, Kaveri, and Kabini chips are impacted. AMD released new free firmware update to resolve things.

It is nice to hear that “AMD responded quickly” and that this vulnerability was resolved in a “timely” manner!

If you have AMD systems, make sure you have this recent update!

Some quotes from stories on this vulnerability:

“The problem is caused by a vulnerability in the AMD SMU (System Management Unit) Unit APU / SoC mentioned, which does not perform pre-implementation code ‘appropriate checks’. AMD responded quickly, closing this security gap with a firmware update to your AGESA (AMD Generic Encapsulated Software Architecture), which is available for manufacturers of motherboards for PCs, notebooks and tablets, based on these APU / SoC AMD. The developer recommends users, requiring manufacturers of compatible motherboards with the APU / SoC affected, the release of new versions of BIOS with the new version of AGESA incorporated; since some motherboard manufacturers might not feel obliged to publish BIOS updates for older products such as stem socket FM2 cards (compatible with Trinity and Richland).”

“Marek told an audience at the Chaos Communications Congress that he worked with AMD for a year to fix the security flaw. He recommended that users contact their motherboard vendors to push the fix to their computers. “[Ask] your vendors for a fixed AGESA [AMD Generic Encapsulated Software Architecture],” Marek said. “This is the only way to push vendors to update BIOSes for older platforms,” he added.”

“As pointed out by Marek firmware insufficiently correctly checks the signature code that allows an attacker to insert your own code and execute it. This is done via the System Management Unit (SMU), which is also responsible for the power saving function. But he was also deeply involved in the configuration. The firmware on 32-bit controller LatticeMicro32 (LM32) from Lattice Semiconductor. Rudolf Marek broke the key used to sign the code hash SHA1. He took the code from SMU update BIOS, and then run the code on an emulator. After breaking the code Rudolph was able to add their own team in SMU and execute them.”

“The firmware is available as part of AMD AGESA (AMD Generic Encapsulated Software Architecture). It has already been updated AMD in late November, the request was sent to manufacturers of motherboards, notebooks and complete systems. They should implement AGESA in your BIOS and UEFI. Updates should already be implemented for most systems, but manufacturers do not disclose relevant information.”

“Back in April last year, Rudolf Marek informed of its existence AMD, who has confirmed the vulnerability in the summer, and it was fixed at the end of November. Hopefully, manufacturers have responded to this problem in a timely manner, and added in a modified AGESA updating the BIOS.”

More Information:

http://www.theregister.co.uk/2015/01/14/amd_plugs_chip_firmware_holes/
http://www.fierceitsecurity.com/story/research-uncovers-security-hole-amd-chips-enable-attack-inject-malware/2015-01-20
https://lenzfire.wordpress.com/2015/01/17/amd-releases-new-free-firmware-for-vulnerabilities-in-their-fm2-fm2-am1-apu-
http://www.hardwareluxx.ru/index.php/news/hardware/prozessoren/33090-amd-firmware-apu.html
http://www.heise.de/newsticker/meldung/Sicherheitsluecke-in-Firmware-von-AMD-Prozessoren-2512960.html
https://events.ccc.de/congress/2014/Fahrplan/events/6103.html
https://media.ccc.de/browse/congress/2014/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek.html#video

Click to access ccc-final.pdf

Intel ATR research on CERT VU 976132

Earlier today I posted on US-CERT’s recent vulnerability note for multiple UEFI vulnerabilties:

US CERT BIOS Vulnerability Note VU#577140!

Later today, Intel has released new research about this:

Technical Details of the S3 Resume Boot Script Vulnerability

“This paper describes technical details of a vulnerability (VU #976132 / CVE-2014-8274) in the protection of EFI based system firmware and platform configuration when resuming from the S3 sleep state.  The issue was independently discovered and presented at 31C3 in December 2014. After discovering this issue, the Advanced Threat Research team has been working to notify BIOS developers and ensure that mitigations are created. We are releasing a test module for the open source CHIPSEC platform security assessment framework. This will assist users in identifying whether their platforms might be affected by this issue.

Read the full report here:

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

Note the part about a new CHIPSEC test, to test for this vulnerability, so watch the CHIPSEC Github for an update. I don’t see an update as of yet.

OEMS: please watch the security talk from Phoenix from the last UEFI Forum plugfest, especially the advise to run CHIPSEC before you ship any new systems. Please ensure your QA team uses fresh CHIPSEC builds.

Consumer Reports and other PC reviewers: Please add the CHIPSEC pass/fail data for any new systems. OEMs will improve their internal QA once they realize that the first thing the public reviewers will be calling out the OEMs on known-bad products.

More information:

US CERT BIOS Vulnerability Note VU#577140!

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

US CERT BIOS Vulnerability Note VU#577140!

Today, US CERT released a Vulernability Notice for UEFI firmware:

Vulnerability Note VU#577140
BIOS implementations fail to properly set UEFI write protections after waking from sleep mode

Multiple BIOS implementations fail to properly set write protections after waking from sleep, leading to the possibility of an arbitrary BIOS image reflash.
Description

According to Cornwell, Butterworth, Kovah, and Kallenberg, who reported the issue affecting certain Dell client systems (CVE-2015-2890):

    There are a number of chipset mechanisms on Intel x86-based computers that provide protection of the BIOS from arbitrary reflash with attacker-controlled data. One of these is the BIOSLE and BIOSWE pair of bits found in the BIOS_CNTL register in the chipset. When the BIOSLE bit is set, the protection mechanism is enabled. The BIOS_CNTL is reset to its default value after a system reset. By default, the BIOSLE bit of the BIOS_CNTL register is cleared (disabled). The BIOS is responsible for re-enabling it after a reset. When a system goes to sleep and then wakes up, this is considered a reset from the hardware’s point of view.

    Therefore, the BIOS_CNTL register must be reconfigured after waking from sleep. In a normal boot, the BIOS_CNTL is properly configured. However, in some instances BIOS makers do not properly re-set BIOS_CNTL bits upon wakeup. Therefore, an attacker is free to reflash the BIOS with an arbitrary image simply by forcing the system to go to sleep and wakes again. This bypasses the enforcement of signed updates or any other vendor mechanisms for protecting the BIOS from an arbitary reflash.

A similar issue affecting Apple systems (CVE-2015-3692) involves the FLOCKDN bit remaining unset after waking from sleep. For more information, refer to Pedro Vilaça’s blog disclosure.

See URL for full Notice.

http://www.kb.cert.org/vuls/id/577140