Lenovo BIOS to UEFI

https://github.com/theznerd/LenovoBIOStoUEFI

“Lenovo BIOS to UEFI TS Converter with CG/DG Prep: Allows you to configure SecureBoot/UEFI settings, as well as Virtualization Technology and TPM for Credential Guard and Device Guard. This script is designed to work on both ThinkPad and ThinkCentre machines. This script connects to the WMI instances for Lenovo machines, and then configures the requested settings. This script is designed to be used as part of a task sequence where you want to convert from legacy BIOS to UEFI and at the same time prepare the machine for Credential Guard and Device Guard.”

Tim Lewis resumes uefi.blogspot blog!

For a long time the uefi.blogspot.com was one of the only sources of UEFI blogging. It appears to have been inactive for about 2 years, but has 2 new posts from this month! Make sure this blog is still on your RSS feed list.

http://uefi.blogspot.com/2016/10/intel-and-insyde-embedded-white-paper.html

http://www.intel.com/content/www/us/en/embedded/software/fsp/fast-secure-iot-solutions-insyde-software-blink-boot-fsp-white-paper.html

http://uefi.blogspot.com/2016/10/pi-15-released.html

SeaBIOS 1.10.0 released!

Kevin O’Connor announced the 1.10.0 release of SeaBIOS.

New in this release:
* Initial support for Trusted Platform Module (TPM) version 2.0
* Several USB XHCI timing fixes on real hardware
* Support for “LSI MPT Fusion” scsi controllers on QEMU
* Support for virtio devices mapped above 4GB
* Several bug fixes and code cleanups

Multiple contributors: Kevin O’Connor, Stefan Berger, Gerd Hoffmann, Igor Mammedov, Dana Rubin, Marcel Apfelbaum, Alex Williamson, Cao jin, Cole Robinson, Don Slutz, Haozhong Zhang, Matt DeVillier, Paolo Bonzini, Piotr Król, Roger Pau Monne, and Zheng Bao.

More info:
https://www.coreboot.org/pipermail/seabios/2016-October/010996.html
https://www.seabios.org/Releases#SeaBIOS_1.10.0

 

IAEA Director: German Nuclear Plant Experienced Cyber Attack

STUXXNET is old news, apparently. As reported by SANS, a year ago a nuclear power plant, probably in Germany, was attacked by malware.

The director of the United Nation’s (UN’s) International Atomic Energy Agency (IAEA) said that an unnamed nuclear power plant suffered a cyberattack within the last three years. Yukiya Amano said that the targeted plant was not forced to shut down operations, and that “This issue of cyber attacks on nuclear-related facilities or activities should be taken very seriously.” Amano said that IAEA is helping nuclear facilities around the word improve cyber and physical security.
 
The director of IAEA is most likely referring to the incident involving a Korea Hydro & Nuclear Power (KHNP) plant, but recent discoveries in Germany of aged malware infections on plant process control equipment is also troubling. The nuclear industry has been well positioned to defend against Internet-borne, non-targeted, threats based because they adopted secure network architectures early, but they are now struggling to address human-enabled (e.g. infected USBs) and highly targeted cyber threats. The next step for the industry will be to transform its cyberdefense strategies from prevention-focused to a more active defense. Active defense is based on the assumption that intrusions will occur, and effective defense focuses on rapid detection of failures along with rapid collapse of free-time available to attackers.

http://www.scmagazine.com/iaea-director-cyberattack-against-a-nuclear-power-plant-occurred-years-ago/article/548192/

http://in.reuters.com/article/nuclear-cyber-idINKCN12A1P1

Nuclear Power Plant Disrupted by Cyber Attack

http://www.hlregulation.com/2016/10/13/iaea-cautions-on-cybersecurity-risks-to-nuclear-power-plants/

I wonder what malware was used, was it firmware-centric? Is ‘critical infrastructure’ really secured any better than COTS consumer devices? Do they use Intel x64 systems with UEFI-based blogs than can be tested with CHIPSEC?

Rowhammer

Wow, there are a lot of Rowhammer stories in the news recently.

 

https://github.com/vusec/drammer

https://www.vusec.net/projects/drammer/

https://twitter.com/addelindh/status/790464273810087936

 

http://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-root-android-phones-is-now-a-thing/

 

Jacob Torrey: coding in a post-Rowhammer world

Jacob Torrey has a presentation on ROWHAMMER:

https://twitter.com/JacobTorrey/status/789830356652462080

[…] Earlier this year at TROOPERS I presented on how many tenets of the LangSec theories could be integrated into a modern SDLC through providing a framework for “verification-oriented programming”. This idea revolved around the notion that “to err is human, to be caught at compile-time (or as close to it as possible) divine”, and that developers are going to make mistakes, but a good SDLC should be able to catch those bugs rapidly. […]

 

http://blog.jacobtorrey.com/rowhammer-defensive-programming

Dmytro takes on the Intel NUC

Dmytro Oleksiuk has a new blog post with UEFI security issues with an Intel NUC using AMI Aptio UEFI BIOS.

(Sad to see that Intel appears to not appear to run CHIPSEC as part of release management QA their own NUCs.)

Exploiting AMI Aptio firmware on example of Intel NUC
[…] Today I’m sharing with you the story of my next x86 machine hacking — we’re going to talk about UEFI vulnerabilities, exploit mitigation features of System Management Mode and new exploit called Aptiocalypsis. Also, this time I did responsible disclosure to Intel and AMI, so, at the moment of this publication you already can patch some of vulnerable products.

Lots of interesting things happened since release of ThinkPwn exploit. Firstly I supposed that vulnerable code was written by Lenovo or its Independent BIOS Vendor (IBV), but later it turned out that they’ve taken this totally mad driver from Intel reference code. This exact code is not available in public, but open source firmware of some Intel boards has it too. For example, SmmRuntimeManagementCallback() function from Intel Quark BSP it’s exactly the same vulnerable code that I’ve found in firmware of my T450s. It’s also interesting that vulnerable code is quite old (it comes from EFI 1.x era) but nevertheless, it was never present in EDK2 source from public repository — its version of QuarkSocPkg was heavily modified in comparison with vulnerable one. The horrible and vulnerable by design piece of code was removed by Intel somewhere in the middle of 2014, but it seems that there were no security advisories regarding this issue. Due to this IBVs had no chance to fix this vulnerability in their relatively old code base and the bug appeared in modern computers from Lenovo, Intel, GIGABYTE, Dell, HP, Fujitsu and other OEM’s (oops!).

Well, I guess at this point it’s much or less clear that currently there’s nothing to do with ThinkPad anymore, it was pwned with 0day, it has too awkward code base that follows ancient version of EFI specification and 8 series chipset that is not the freshest stuff you can get. As my next target for firmware security adventures I’ve decided to take some Skylake based machine of well-known vendor who might have a decent firmware that would be interesting to break. Because I like all kinds of small x86 compatible computers, I’ve put my eye on the latest generation of Intel NUC. It also looks interesting because platform vendor knows his hardware better than anyone else, so, from firmware security perspective, Intel NUC is definitely not the worst choice.[…]

http://blog.cr4.sh/2016/10/exploiting-ami-aptio-firmware.html

 

Dirty COW Linux security issue

From the OSS-Security list, some details on a new “Dirty COW” Linux security issue:

CVE-2016-5195 “Dirty COW” Linux kernel privilege escalation vulnerability

This was brought to the linux-distros list (and briefly inadvertently to the distros list, although discussion continued on linux-distros only) on October 13 and it was made public yesterday, so it must be in here as well.  Unfortunately, no one posted about it in here so far (the person who brought this to [linux-]distros must have done so!), and I don’t have time to make a proper posting (with full detail in the message itself, as per oss-security list content guidelines), but I figured it’s better for me to post something than nothing at all.

Red Hat’s description:

“A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.  An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.”

https://access.redhat.com/security/cve/cve-2016-5195
https://bugzilla.redhat.com/show_bug.cgi?id=1384344
https://security-tracker.debian.org/tracker/CVE-2016-5195
http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
https://lkml.org/lkml/2016/10/19/860
https://dirtycow.ninja
https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

https://www.us-cert.gov/ncas/current-activity/2016/10/21/Linux-Kernel-Vulnerability

U-Boot gets improved testing

Tom Rini of Konsulko posted an 8-part patch to the U-Boot list, improving their CI infrastrucute. It is nice to see firmware projects with improved testing!

[PATCH 0/8] Various travis-ci improvements

The following series does a few things with our existing travis-ci infrastructure.  We update to the latest Ubuntu release that is supported (there are only 2 Linux host choices) and make use of toolchains that are available that way when possible and fix building of x86.  I added in microblaze and sh4 and xtensa to the build loop (I left out blackfin and openrisc as they have compile problems currently in general). The biggest change here is that I’ve added support for test.py running on qemu-x86, qemu-ppce500, qemu-mips*, vexpress_ca15_tc2, vexpress_ca9x4, and integratorcp_cm926ejs along with sandbox.

This final part is I think the most important.  With this change all it now takes to have some build coverage and some test.py coverage is a github account.  You can then login to travis-ci.org that, click a few things and get build and test coverage with minimal effort now.  It takes about 2 hours in its current configuration but could easily be cut down in ones personal repository for quicker test cycles.  And for the record, in addition to email notifications by default one will have https://api.travis-ci.org/repos/USERNAME/u-boot/builds.atom available as an atom feed, in addition to the numerous other notification methods available.

http://lists.denx.de/mailman/listinfo/u-boot

coreboot 4.5 released

Martin Roth posted a new coreboot blog post, announcing version 4.5 of coreboot! Look at the blog post for lots of details.
Two hightlights for me are: “Add support for TPM 2.0″and “SPI & refactored I2C TPM driver”.

We are happy to announce the release of coreboot 4.5. The 4.5 release covers commit 80a3df260767 to commit 0bc12abc2b26. This release is the first since the project switched from doing quarterly releases to doing biannual releases.  The next release will be in April of 2017. Since the last release in April, the coreboot project has had 1889 commits by 119 authors. The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/releases/ There is a 4.5 tag in the git repository, and a branch will be created as needed.

coreboot statistics:
Total Commits: 1889
Average Commits per day: 10.92
Total authors: 119
New authors: 47
Total Reviewers: 67
Total Submitters: 19
Total lines added: 164950
Total lines removed: -182737
Total difference: -17787

Announcing coreboot 4.5

ISACA report on firmware-based malware

Jose Gonzalez from Trapezoid.com brought this to my attention:

I thought you would be interested to see this ISACA report released today. The main findings were covered by Computer Weekly:

“More than half (52%) of the study’s participants who place a priority on security within hardware lifecycle management report at least one incident of malware-infected firmware being introduced into a company system, with 17% of these incidents having a material impact. In contrast, those that do not prioritise security in the hardware lifecycle process have a high rate of unknown malware occurrences (73%). This indicates many vulnerabilities remain undetected and unpatched, creating security risks. This lack of knowledge is having an impact on confidence too, with 71% of respondents in this category (low security priority) feeling unprepared to deal with a cyber attack. To be able to address these weaknesses, the report said organisations need to foster increasing co-operation and communication between IT departments and audit professionals, and establish robust controls for hardware lifecycle management. The study shows that acting on feedback from the auditing teams is key to mitigating risk.”

http://www.computerweekly.com/news/450401249/Most-businesses-vulnerable-to-cyber-attacks-through-firmware-study-shows
http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Firmware-Security-Risks-and-Mitigation.aspx

Secure Boot in vSphere 6.5

Tom Fenton has an article in Virtualization Review on the latest version of VMWare’s vSphere 6.5, and this release includes UEFI changes:

[…]Another major security upgrade in this release is “Secure Boot,” to prevent unauthorized operating systems and software from loading during the startup process. Secure Boot is a feature enabled by UEFI, and can be used not only when booting the hypervisor, but also when booting up the guests. VMware has also updated its logging to include the ability to track who did what on a vSphere system. […]

https://virtualizationreview.com/articles/2016/10/18/vsphere-6_5-first-look.aspx

DMTF releases more Redfish tools

The DMTF has a Github project for DMTF. They’ve recently updated it to include new tools, including ‘redfishtool’. Quoting their press release:

New tools recently shared include:
 * Redfish Service Validator – a Python 2.7 tool for checking conformance of any “device” with a Redfish service interface against a Redfish CSDL schema.
 * Redfish Profile Simulator – a Flask-based real simulator of the initial OCP Feature profile. Resources are loaded from a mockup into Python dictionary structures.
 * Redfishtool CLI tool – a Python 3.4 program that implements a commandline tool for accessing the Redfish API. The tool outputs Redfish JSON responses for common use cases, and shows the proper way to implement the hypermedia aspects of the Redfish API.
 * Mockup Creator – a Python 3.4 program that creates a Redfish Mockup folder structure from a real live Redfish service. The program executes Redfish GET requests to the Redfish service and saves the response in a file structure.

These new items join additional tools currently available in the GitHub repo:
* CSDL to JSON-schema converter – converts a valid Redfish CSDL schema to the JSON-schema (draft v4) format.
* OData CSDL Validator – a Python 3.0 tool that crawls through OData-formatted metadata, parses it and validates that it conforms to OData V4.0.
* Mockup Server – a simple Python 3.4 program that can be copied into a folder at the top of any Redfish mockup and serve Redfish requests on the specified IP/port.
* Documentation Generator – a utility to format text and values extracted from the Redfish JSON-schema files and incorporate text from additional Markdown documents to generate either web-based (Slate) or easily printed (converted to PDF) end-user documentation of the Redfish schema.

http://www.dmtf.org/standards/redfish
http://redfish.dmtf.org
http://dmtf.org/standards/spmf

Veracrypt security issues

Multiple news sources are reporting issues with TrueCrypt replacement VeraCrypt, a UEFI application. Quoting The Register:

[…] Quarkslab senior security researcher Jean-Baptiste Bédrune and senior cryptographer Marion Videau crawled through the VeraCrypt codebase, focussing on version 1.18 of the platform and the DCS EFI Bootloader 1.18 (UEFI), examining new security features introduced since the April 2015 security audit of TrueCrypt. They report boot passwords in UEFI mode and code length in legacy mode could be retrieved by attackers.[…]

http://www.pcworld.com/article/3132368/critical-flaws-found-in-open-source-encryption-software-veracrypt.html

http://www.theregister.co.uk/2016/10/18/veracrypt_audit/

The VeraCrypt Audit Results

My slides from BsidesPDX’16

I gave a brief presentation at Security BSides Portland (BsidesPDX) a few days ago. Title was “Firmware Tools for Security Researchers”. Since it was only a 20-minute time slot, I only had time to cover a few tools, and didn’t get a chance to mention other noteworthy tools. Sorry for the delay in uploading, returned from conference to a bit of post-storm damage at home.  PDF of slides are here:

bsidespdx2016

I’ve promised an ‘awesome-firmware-security’ set of links for a while, these slides are part of that effort, and will have a draft of this — with many more tools — in about 2 weeks.

I met a few people from the CHIPSEC team at BsidesPDX, which was an honor. I also got a few interesting questions from some smart attendees, and will be doing a few new blog posts on the things I learned at the event.

CPP-UEFI-Wrapper

CPP-UEFI-Wrapper is a new project to create a C++ wrapper for C-centric UEFI. It is just getting started, not yet ready for use.

https://github.com/GuildMasterInfinite/CPP-UEFI-Wrapper

C++ UEFI Wrapper:
This project is a C++ wrapper for the UEFI specification, intended for people who write UEFI applications (OS loaders, shells, etc.) The project is composed of two parts, 1) The low-level wrapper, that uses structs and pointers to directly implement the UEFI specification. and 2) The high-level, object-oriented wrapper, that uses classes to represent various UEFI protocols. Features:
* Uses modern C++14 features (constexpr, static_assert, strongly typed enums).
* Mainly intended for UEFI applications, not UEFI drivers or firmwares.
* Relies on some C/C++ headers, but does not require a hosted standard library (obviously).
[…]

Intel to add ‘deep learning’ instructions to Xeon

Piotr Luc of Intel submitted a patch to the Linux kernel, adding ‘deep learning’ instrutions for future Xeon processors.

https://lkml.org/lkml/2016/10/12/530
[PATCH] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features.
AVX512_4VNNIW  – Vector instructions for deep learning enhanced word variable precision.
AVX512_4FMAPS – Vector instructions for deep learning floating-point single precision.
The new instructions are to be used in future Intel Xeon & Xeon Phi processors.
The spec can be found in Intel Software Developer Manual or in Instruction Set Extensions Programming Reference.
See https://software.intel.com/sites/default/files/managed/69/78/319433-025.pdf.