” Fast and lightweight x86/x86-64 disassembler library”
https://github.com/zyantific/zydis
Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode
Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet
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 runtime attacks, we propose an event-based behavior monitoring approach that relies on 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 resolve the semantic gap issue. Our approach is generic. It can monitor different targets (e.g., firmware, kernel, or hypervisor) and does not depend on a specific model of the behavior. In this work, we apply this approach to detect attacks targeting the System Management Mode (SMM), a highly privileged x86 execution mode executing firmware code at runtime. We use the control-flow of the code as a model of its behavior. We instrument two open-source firmware implementations: EDK II and coreboot. We evaluate the ability of our approach to detect state-of-the-art attacks and its runtime execution overhead by simulating an x86 system coupled with an 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 (i.e., less than the 150 µs threshold defined by Intel).
https://www.acsac.org/2017/openconf/modules/request.php?module=oc_program&action=summary.php&id=181
Microsoft WinHEC (Hardware Engineering Conference) is happening in Nov-Dec:
Re: the recent Infineon TPM problem, more and more downstream problems are being discovered. The main news presses have lots of stories on this now.
Another UEFI game….
https://twitter.com/CysekSentinel/status/920640632271409152
Automating UEFI Firmware updates
In our previous blog post we talked about the state of UEFI firmware running on Windows laptops attached to one of our research networks. In case you don’t recall the conclusion: We were surprised that many of the devices were running out-of-date firmware and decided to investigate ways in which automated UEFI firmware updates could be scaled to meet the needs of an Enterprise. This blog tells the story of what happened next.[…]
https://www.ncsc.gov.uk/blog-post/automating-uefi-firmware-updates
If you are in San Francisco later this month, the Fastly Security Speaker Series has a new event, with two firmware security-related presentations!
https://www.eventbrite.com/e/fastly-security-speaker-series-part-3-tickets-38787460338
We’re excited to announce the third installment of the Fastly Security Speaker Series. Fastly will bring some of the most innovative and thoughtful security researchers to San Francisco to share their work. Speakers include Alex Bazhaniuk, of Eclypsium, Inc. and Stephen Checkoway, whose most recent papers include: A Systematic Analysis of the Juniper Dual EC Incident, Run-DMA and On the Security of Mobile Cockpit Information Systems.
Talk 1: Exploring Your System Deeper
Alex Bazhaniuk of Eclypsium, Inc.
Ever wanted to explore deep corners of your system but didn’t know how? This could include system boot firmware, ROMs on expansion cards, I/O devices and their firmware, microprocessors, embedded controllers, memory devices, low-level hardware interfaces, virtualization and hypervisors — you could discover if any of these have known vulnerabilities, configured insecurely, or even discover new vulnerabilities and develop proof-of-concept exploits to test these vulnerabilities. Ultimately, you can verify security state of platform components of your system and how effective the platform security defenses are: hardware or virtualization based TEE, secure or trusted boot, firmware anti-tampering mechanisms, hypervisor based isolation… Or maybe you just want to explore hardware and firmware components your system has. CHIPSEC framework can help you with all of that. Since its release at CanSecWest 2014, significant improvements have been made in the framework — from making it easy to install and use to adding lots of new security capabilities. We’ll go over certain representative examples of what you can do with it such as finding vulnerabilities in SMM firmware, analyzing UEFI firmware vulnerabilities, testing hardware security mechanisms of the hypervisors, finding backdoors in UEFI images, and more.
Talk 2: The Juniper Dual EC incident
Stephen Checkoway, Assistant Professor at University of Illinois at Chicago
In December 2015, Juniper Networks announced that unknown attackers had added unauthorized code to ScreenOS, the operating system for their NetScreen VPN routers. This code created two vulnerabilities: an authentication bypass that enabled remote administrative access, and a second vulnerability that allowed passive decryption of VPN traffic. Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker. The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator’s output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack. In this talk, Stephen Checkoway presents the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. This work sits at the intersection of cryptography, protocol design, and forensics, and is a fascinating look at a problem that received a great deal of attention at the time but whose details are less well known.
Monday morning a new WiFi vulnerability is going to be released. Embedded devices and WiFi-enabled firmware is going to be needing your attention…
https://www.us-cert.gov/ncas/current-activity/2017/10/16/CERTCC-Reports-WPA2-Vulnerabilities
http://www.kb.cert.org/vuls/id/228519
https://github.com/vanhoefm/krackattacks
https://char.gd/blog/2017/wifi-has-been-broken-heres-the-companies-that-have-already-fixed-it
FWTS is the recommended ACPI test tool by the UEFI Forum!
Here’s the info from the changelog:
Missing space in title of ACPI RAS Feature Table (RASF)
Typos in Extended PCC subspaces (types 3 and 4)
Add a new NFIT Platform Capabilities Structure
PPTT ID Type Structure offsets
Remove bits 2-4 in the Platform RAS Capabilities Bitmaptable
Region Format Interface Code description
Remove support for multiple GICD structures
PDTT typos and PPTT reference Revision History
Minor correction to Trigger Action Table
General Purpose Event Handling flow
http://uefi.org/specifications
If you really want to understand what has changed in the ACPI and UEFI specs, you need to join the UEFI Forum, so you can access the Mantis bug database and understand what the Mantis numbers in the ACPI and UEFI spec revision history refer to…
PCILeech FPGA contains software and HDL code for FPGA based devices that may be used together with the PCILeech Direct Memory Access (DMA) Attack Toolkit. Using FPGA based devices have many advantages over using the USB3380 hardware that have traditionally been supported by PCILeech. FPGA based hardware provides full access to 64-bit memory space without having to rely on a kernel module running on the target system. FPGA based devices are also more stable compared to the USB3380. FPGA based devices may also send raw PCIe Transaction Layer Packets TLPs – allowing for more specialized research. For information about PCILeech itself please check out the PCILeech project.
https://github.com/ufrisk/pcileech-fpga
Double entry for Alex: he’s got a new blog post on Intel Boot Guard, plus he’s updated UEFITool!
“[…]Today I released a new build of UEFITool with visual validation of Intel Boot Guard coverage. The code pushed to the github repository. A standalone binary of UEFITool can be downloaded here.[…]”
https://github.com/LongSoft/UEFITool
Application Containers are slowly finding adoption in enterprise IT infrastructures. Security guidelines and countermeasures have been proposed to address security concerns associated with the deployment of application container platforms. To assess the effectiveness of the security solutions implemented based on these recommendations, it is necessary to analyze those solutions and outline the security assurance requirements they must satisfy to meet their intended objectives. This is the contribution of this document. The focus is on application containers on a Linux platform.
Keywords: application container; capabilities; Cgroups; container image; container registry; kernel loadable module; Linux kernel; namespace; TPM
https://csrc.nist.gov/publications/detail/nistir/8176/final
https://csrc.nist.gov/News/2017/NIST-Releases-NISTIR-8176
http://doi.org/10.6028/NIST.IR.8176
Platform Software Senior Principal Engineer/BIOS Architect (17000X39)
[…]You’ll apply skills and experience across the full cycle of software development (specification development and review, debug and validation) to enable features and capabilitiesof platforms in areas like UEFI drivers, thermal, power management, security, manageability, manufacturability, configurability and embedded controllers.
[…]
* Work with Industry forums for spec development like UEFI, DMTF, PCI Sig, ACPI, etc
* Ability to take ownership of overall UEFI platform design throughout the platform lifecycle
* 12+ years experience in BIOS / firmware SW development
* UEFI Programming expertise
* Low level programming capability -system/motherboard/device/chipset level
* Experience with analyzers and other HW tools to debug complex system SW issues
[…]
Last week Paul English of PreOS Security gave a presentation at SeaGL Conference (spelled with the RMS-preferred prefix, “Seattle GNU/Linux Conference”, pronounced like the bird “Seagull”). The presentation was about about firmware defensive skills. Whereas my previous presentation presumed an audience of enterprise (SysAdmins, SREs, Blue Teams, or DFIR), Paul’s talk presumed an audience of end-users, with no enterprise to back them up.
Alas, with most SeaGL presentations, this presentation was not video/audio-taped. His blog post has pointer to his slides.
His blog post also mentions brief status update on the sysadmin ebook that Paul is driving, he’s nearly ready, it’ll be nice to have this resource available.
Also, note that the PreOS Security web site has been revamped. All known HTTP/HTTPS problems have been resolved, and the blog backlog is getting flushed.
https://preossec.com/SeaGL-2017/
Nice to see Joe Fitzpatrick doing firmware hacks on CSPAN!
https://twitter.com/adafruit/status/918180147848720384
https://www.adafruit.com/product/2264

More on: https://firmwaresecurity.com/2017/10/10/infineon-tpms-generating-weak-keys/
https://twitter.com/laurenweinstein/status/917906158324662272
“You can check the TPM firmware running on your device by looking at the firmware_version line of the tpm_version entry in chrome://system. If the tpm_version entry is absent, this is likely because you are running an old Chrome OS version which doesn’t report this information. Upgrade to a newer version and check again.”
https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update
If you missed the Intel presentation from BlackHat Briefings this summer, and if you are in the Seattle area this Sunday, Vincent Zimmer of Intel will be reprising this presentation at the DC206 Meeting at the Black Lodge Research hackerspace.
What: Oct DC206 Meeting: Firmware is the New Black
When: October 15th, 1-3pm
Who: Vincent Zimmer
Where: Black Lodge Research
Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities
In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).
https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities
http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html
Click to access BlackHat2017-BlackBIOS-v0.13-Published.pdf
Last week I gave a presentation at SOURCE Seattle Conference, on defensive UEFI tools/guidance, mostly talking about NIST 147’s lifecycle, and how to use tools like (CHIPSEC, acpidump, FWTS) to look for signs of firmware attacks.
As I understand it, SOURCE Conference will have video of this presentation online sometime in the near future.
https://www.sourceconference.com/copy-of-seattle-2016-agenda-details
Slides have been uploaded to this blog, and are available here:.srcsea17. (PreOS Security will have an archive of all of our post-conference materials on Github shortly.)
At the conference, Bryan of the Brakeing Security podcast interviewed PreOS Security co-founder Paul English and myself, along with some other SOURCE Seattle speakers. I am not sure when that podcast is queued up for. I hate public speaking in general, but I cringe at completely unprepared interviews like this podcast. Sorry I didn’t have better concise answers to the questions put to me. I think the normal podcast drinking game is to drink whenever you hear ‘um’ or ‘I mean’. Be careful if you’re playing that game during my brief audio clips. 😦
http://www.brakeingsecurity.com/
http://brakeingsecurity.com/rss
@bryanbrake
A slide in the presentation pre-announces an upcoming tool we’re working on. That tool should be ready in a few weeks, more details soon.
https://www.infineon.com/cms/en/product/promopages/tpm-update/?redirId=59160
https://eesage.com/pages/103061850-tpm-update
ADV170012 | Vulnerability in TPM could allow Security Feature Bypass – A security vulnerability exists in certain Trusted Platform Module (TPM) chipsets. The vulnerability weakens key strength. It is important to note that this is a firmware vulnerability, and not a vulnerability in the operating system or a specific application. After you have installed software and/or firmware updates, you will need to re-enroll in any security services you are running to remediate those services.
Nice, Microsoft makes you agree to a EULA before you can view the web page. 😦
Intel(R) Xeon(R) Processor Max Effort Turbo Boost UEFI DXE driver
Programs Haswell-E/EP Xeon(R) processors (cpuid = 306F2h) on X99 (single) and C612 (dual) platforms to allow for maximum all-core turbo boost for all cores regardless of whether there are motherboard options present for overclocking/voltage control or not. For example, the 18-core Xeon(R) E5-2696 v3 processor has set from the factory an all-core turbo of 2.8GHz. This driver programs the highest un-fused ratio (i.e. the 1C Turbo bin) as the new Turbo bin for all boost configurations including all-core turbo. In other words, the 1C turbo bin becomes the all-core turbo bin and the E5-2696 v3 processor now demonstrates an all-core turbo of 3.8GHz!
Allows for per-package, dynamic undervolting (retains PCU control while applying a fixed negative Vcore offset) IA (i.e. Core), CLR (CBo/LLC/Ring) a.k.a Uncore, and System Agent (SA) voltage domains independently which provides for higher all-core sustained clocks during heavy workloads, including AVX2 workloads
Allows for setting static Uncore ratio for maximum performance (lowest typical access latency and accompanying maximum throughput) or setting to limit less than maximum (typical 30x). It is possible to trade cache speed for Core speed and studies show that 100MHz of Core speed-up is roughly equivalent to 1000MHz of cache speed-up. That being said, lowering your Uncore power budget to make it to that next-higher Core speed bin is often a worthwhile trade-off
Allows to disable CPU SVID telemetry (a.k.a. “PowerCut”) which may reduce or remove altogether TDP power limitations for some system combinations. Allows to set a fixed VCCIN voltage (not recommended if available to be set in BIOS)
Driver is designed to work on up to 8S systems. Verified functional on multiple 1S and 2S systems with accompanying modified BIOS (remove any microcode revision update patches)
May work for other Intel(R) Xeon(R) processor types/steppings including Broadwell-E/EP (untested as of yet), and possibly even SKY-E/EP (also, untested as of yet)
[…]
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.
You must be logged in to post a comment.