Hastily-written news/info on the firmware security/development communities, sorry for the typos.
AntiVirus Today just ‘revived’ an old story from 2013, AFAICT no new news at all:
https://twitter.com/antivirustoday/status/652933400479711232
http://www.theregister.co.uk/2013/04/11/ami_uefi_key_leak/
It is old news, but a good read if you missed this story 3 years ago, and it does remind vendors about the need for security in your firmware.
I just noticed “Sysmagazine geek daily blog: a translation of the popular Russian IT blog, Habrahabr.ru”. So, it contains English translated versions of Nikolaj’s Russian UEFI security series on habrahabr.ru. I’d been using Google Translate, this is slightly easlier to use. Here’s the English version of Nikolaj’s series:
http://sysmagazine.com/posts/266935/
http://sysmagazine.com/posts/267197/
http://sysmagazine.com/posts/267237/
http://sysmagazine.com/posts/267491/
http://sysmagazine.com/posts/267953/
http://sysmagazine.com/posts/268135/
http://sysmagazine.com/posts/268423/
Here’s the original series:
http://habrahabr.ru/users/coderush/topics/
In the last part of the series, he lists various people of interest, but not much about himself. Nikolaj’s UEFI Tool is consistently at the top of Github’s active list for UEFI. More popular than Intel CHIPSEC, or the TianoCore Git mirrors. UEFItool is also one of the better maintained tools in the field of firmware security, very active at fixes. I’d put him near the top of the list, along with ITL, LegbaCore, and Intel ATR/CHIPSEC team, as a prime source of firmware security knowledge. He’ll be speaking at ZeroNights in Moscow this December on UEFI…
http://2015.zeronights.org/agenda.html#schlej
http://2015.zeronights.org/speakers.html#schlej
Quoting their documentation:
Estuary provides a total solution for general-purpose computer based on aarch64 architecture. Anyone can quickly bring up an ARM64 platform – both software and hardware with Estuary. The major goals for Estuary project are:
* A stable\available quick start solution based on ARM64 computer, so that anyone can easily get and bring up the complete development environment, so that you can just focus on your particular field quickly.
* A common basic platform, which should be sustainable and will be continuously improved, can attract\absorb and integrate all 3rd part achievement ceaselessly.
* Sufficient technological documentation, so that any user or partner can easily get useful help from it.
* Simple and effective communication forum for ARM64 ecosystem, so that users can interact and share each other to improve ARM64 ecosystem.
* A bug tracking system, so that anyone can raise, track and help to resolve the issues, this will help to mature the solution and enhance the ecosystem.
* Multiple ARM64-based hardware platforms, and related software to speed up the ARM64 ecosystem development.
* The most key goal of Estuary project is to support, enable and speed up the maturity of ARM64 ecosystem.
For hardware, they currently support two AArch64 SOC boards, D01, D02 boards. For OS, they support Linux or Windows. For, firmware they say they support “Multi-kinds of boot loader will be enabled for Estuary, include but not limited to UEFI\Grub, uboot.” But currently they appear to support UEFI and GRUB. Amongst the other tools included in Estuary is a LAVA system, Linaro’s Automated Validation system, which performs continuous integration on QEMU- and multiple ARM-based devices, letting you reinstall firmware, OS, run pre-OS tests, and gather results.
They include their UEFI changes in their project changelogs, eg their 2.0 release from last month included two entries on UEFI:
9. Pubished the latest UEFI source code for D02 and eanbled building UEFI from source code directly.
11. Upgraded UEFI to add PCIE scaning.
a. Remove GE4 and keep only GE5 on UEFI, to avoid confusion with 2 NICs.
b. Re-enable PCI Express link up for port 1 and 2 (According to PCI Express slots on the board).
c. Fix PXE timeout issue.
d. Re-enable showbrdnum and setbrdnum commands on EBL.
e. Fix several other bugs.
They are still using Ubuntu 12.04.
More information:
http://open-estuary.com/uefi-and-grub
https://github.com/open-estuary/uefi
https://github.com/open-estuary/uefi.git
http://git.savannah.gnu.org/cgit/grub.git
http://open-estuary.com/estuary/
http://open-estuary.com/estuary-v2-0/
http://open-estuary.com/d02-2/
http://open-estuary.com/d01-2/
Earlier today, Matthew Garret posted a problem on Twitter about Intel Linux and Intel TXT mode:
Later that day, Vincent Zimmer of Intel is apparently helping to get that Intel project working with UEFI:
A few weeks ago, a similar thing happened with Intel SGX. Intel is lucky to have Vincent Zimmer, who is very engaged with Linux security/development community, in helping to fix Intel projects to properly support UEFI. Many large companies do not have this kind of public individual involvement.
A short security lesson from Matthew (click on Twitter link for follow-up post):
[BTW, sorry WordPress doesn’t seem to render Twitter’s HTML table when scrolling through the site If you ever see multiple blank lines in the post it is probably a Twitter URL that WordPress didn’t render, refresh to fix. You have to refresh on new pages, often, or view the post on a separate page (which generates a refresh). I post messages while online and finding news, but don’t spend a huge amount of extra time formatting the posting, simple ASCII text plus a few URLs. The interactive WordPress HTML UI to add a hyperlink triples the time to post each message, and WordPress won’t accept HTML <A> links. WordPress renders some URLs differently, like showing the image of a JPEG/PNG/etc, and showing the Youtube video link and hiding the rest of a web page which contains a Youtube URL — like Kickstart funding pages.]
Since IDF this Summer, a few UEFI Forum vendors have announced support for Intel’s “Innovation Engine”, which was announced at IDF. Recently, AMI just announced more support for it:
The problem is, Intel has yet to provide ANY information on this Innovation Engine vaporware. These “we also support Intel IE” press releases, with no information on what Intel IE is, are getting tiresome. Intel, please produce some information on IE, not just get partners to ship vague vaporware press releases!
Johan Arwidmark recently posted an article, “List of Windows 10 features that requires UEFI”
One of the many restrictions of the Windows 10 inplace-upgrade process is that it doesn’t support changing BIOS to EUFI (see my Windows 10 Upgrade Limitations post for complete listing). So, do you really need UEFI to deploy Windows 10? The answer is no, Windows 10 can absolutely be deployed to BIOS-based machines, but some of it’s features does require UEFI. Here is the (current) list:
Full article:
http://deploymentresearch.com/Research/Post/514/List-of-Windows-10-features-that-requires-UEFI
They’ve added a 2-day training course on BIOS/SMM, “Advanced x86: Introduction to BIOS & SMM”! The BIOS researchers at MITRE — and half of them now at LebaCore — are one of the main pioneers of BIOS research, and this is one of ther main training sessions. Wow!
“Around 2011, the trustworthy system measurement research project that Xeno Kovah was running at MITRE decided to start digging deeper than the Windows kernel and rootkit detection, to try and detect malicious software at the BIOS level. Xeno & Corey Kallenberg continued to work on Kernel, while team member John Butterworth was tasked with starting to learn about BIOS in parallel. John’s work led to the “BIOS Chronomancy” work (published at both BlackHat and ACM CCS), porting the team’s existing Timing-Based Attestation system from the kernel level down to the BIOS. Xeno then asked John to start making an open source training class to capture his knowledge, the same way that Xeno & Corey had captured their past knowledge on the project and uploaded it to OST. John created a 2 day Intro BIOS class and got it public released from MITRE. The intention originally was that it would cover all basics of BIOS which would be applicable to both legacy BIOS, CoreBoot, or UEFI-based systems. And then it was expected there would be a follow on class digging deeper into the specifics of UEFI. Unfortunately time prohibited the creation of that 2nd 2 days of classes focusing on UEFI, so you can see that some minimal UEFI content was eventually shoehorned into this class, though frequently there isn’t enough time to get to it within 2 days. It is our hope that this Introductory BIOS & SMM class will help demystify how x86 systems work at the low levels, so that people can better understand the BIOS/SMM/SecureBoot vulnerabilities described in the team’s work while at MITRE, and later after Xeno & Corey founded LegbaCore. With this knowledge in hand, hopefully students can fully appreciate and explain to others why it is so critical that BIOS patch management be performed by organizations, to eliminate the vulnerabilities that lurk at this level.
https://www.syscan360.org/en/schedule/
SyScan is happening soon. There are multiple hardware/firmware-level talks, including one on VxWorks. And, since I’ve a bit of a UEFI focus, there is this one:
Is There An EFI Monster Inside Your Apple?
Pedro Vilaça
A few months ago I publicly disclosed an Apple EFI firmware zero day. It was a very powerful bug allowing direct access to the EFI firmware from the operating system. EFI rootkits are some of the most powerful and most interesting rootkits. Because they work at a very low level they can play a lot of tricks to hide themselves from forensics and persist for a long time. EFI monsters are a bit like jaguars, stealthy and rarely seen by humans. This doesn’t mean they do not exist. EFI monsters are most certainly part of spy agencies rootkits catalog. Very few tools exist to chase them. This talk is about introducing you to the EFI world so you can also start to chase these monsters. EFI world might look scary but it’s a bit easier than you think and a lot of fun. Thunderstrike 2 (to be presented at BlackHat) is a fine example of the power of EFI rootkits and the problems they present.
Nikolaj has written a 7th part to his 6-part series on UEFI security!
It covers AMD security processors, Intel STM, Intel SGX, TPM 2.0, and other current technologies.
There is mention at the end of an upcoming article on taming Secure Boot, generating your own keys, looking forward to that!
There’s a new UEFI-aware ISO-building tool out, called ebiso:
UEFI bootable ISO image creator
Primary intention of ebiso was to create simple bootable UEFI ISO image for ReaR https://github.com/rear/rear on SLES11.
* supports 8.3 file name and partialy (filenames up to 200 bytes in filename length) RRIP (Rock Ridge Interchange Protocol)
* no additional dependencies
* released under GPL
* currently under heavy testing 😉
* more info will come (maybe)
* tested with rear on SLES11 SP3 and Centos 6.7
Aaron Pop has created a new Tianocore module:
A EDK2 Package that supplies a UEFI driver that will bind on top of Graphics Output Devices and rotate any Blt operations by 0, 90, 180 or 270 degrees.
The license appears to be custom, but BSD-like. Perhaps someone can convince Aaron to relicense to BSD and submit to Tianocore? 🙂 Presumably more vendors will need this as they ship UEFI-based tablets/smartphones and want to let user use the device the way they want.
https://github.com/apop2/UefiGopRotate
Stevenyu1982 has started the Puppet-razor-custom project on Github.
Based on puppet razor, adding new features to support our environments. Features:
* Adding IPXE UEFI support
* Routing the IPXE UEFI and Legacy based on current BIOS setting
* Change the default BIOS boot order from Pxe and Change the UEFI to Legacy boot to support Oel6.5 installation
* ASU command intergation for changing the BIOS settings
* MegaCLI command intergraion for raid creation.
Console Inc, an Android-based OS vendor, has started a new Github project for UEFI firmware for Android called AndCanGO:
AndCanGO: A project to unify the various UEFI & IA-capable fastboot and bootloaders, with its goal to deliver a custom, update-friendly Android recovery and GUI installer.
It is currently just created, an as-yet empty project. Watch for it to change in the upcoming days, along with some of their other related projects (which are not empty).
Red Hat’s Product Security team is working with OSS-security to get a CVE listed for the below patch. Excerpting the OSS-security request from Wade Mealing of Red Hat, which was in turn paraphrased from Linn Crosetto, perhaps others:
When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexec_load. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a boot_params flag to indicate the state of UEFI Secure Boot. This flag is then used in setup_arch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.
TLDR: this allows a bypass the security mechanism of securelevel/secureboot combination.
This patchset affects Red Hat specific kernels as secureboot is not fully fully implemented upstream yet.
It appears you need an account to view the bug database entry, and the patch:
Patch: https://bugzilla.redhat.com/show_bug.cgi?id=1243998#c3
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1243998
Three tweets from William Lam of VMware, with more information about new features (and one limitation) of UEFI, including a useful VMware UEFI article:
Excerpt from article:
For those of you who may not know, UEFI is meant to eventually replace the legacy BIOS firmware. There are many benefits with using UEFI over BIOS, a recent article that does a good job of explaining the differences can be found here. In doing some research and pinging a few of our ESXi experts internally, I found that UEFI PXE boot support is actually possible with ESXi 6.0. Not only is it possible to PXE boot/install ESXi 6.x using UEFI, but the changes in the EFI boot image are also backwards compatible, which means you could potentially PXE boot/install an older release of ESXi.
http://www.virtuallyghetto.com/2015/10/support-for-uefi-pxe-boot-introduced-in-esxi-6-0.html
Microsoft: Trusted Boot Security Feature Bypass Vulnerability
CVE-2015-2552
Product: Windows NT series 8.0+
Affected versions: See “systems affected”.
Reported by: “Myria”
An attacker with administrative access to a Windows machine with UEFI Secure Boot enabled may bypass code signing policy checks by putting intentionally-malformed configuration options in the boot configuration database (BCD).
https://technet.microsoft.com/en-us/library/security/ms15-111.aspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2552
http://seclists.org/bugtraq/2015/Oct/70
https://support.microsoft.com/en-us/kb/3096447
Mike Terrell and Troy Martin are giving a talk at the Midwest Management Summit (MMS) on transitioning Windows systems from BIOS to UEFI.
Making the switch from BIOS to UEFI
The Unified Extensible Firmware Interface (UEFI) is the next generation interface between the operating systems and the platform firmware. UEFI replaces the legacy Basic Input/Output System (BIOS) firmware that has been around since the beginning of personal computers. Although UEFI has been around for several years, manufacturers have provided support for legacy BIOS by the means of a Compatibility Support Module (CSM). This allows support for booting from MBR-partitioned disks. The downside to this old school booting method is that it is vulnerable to root kits and other intelligent types of malware that inserts itself into the booting process. In this session, you will learn the differences of BIOS and UEFI, the benefits of UEFI and Windows 10 security benefits that are only available when running UEFI. How to use Configuration Manager to inventory systems that are running UEFI (as well as those that are not). Also, you will learn about the common pitfalls when making the switch from BIOS to UEFI, how to avoid them, and how zero touch OSD is actually possible when making the switch.
http://mmsmoa.com/
http://mms2015.sched.org/event/a6243319bb0dcd3c631fda78c2763480
Mike Terrill has an article on using Windows 10 and Secure Boot, and using Configuration Manager to show the state of Secure Boot:
Inventory Secure Boot State and UEFI with ConfigMgr
Now that Windows 10 has been released, you are probably starting to take a closer look at the new OS and the related security benefits that it has to offer. Secure Boot is a supported security feature in Windows 10 that secures the boot process by only allowing the loading of drivers and boot loaders that are signed with a trusted signature. The first versions of Windows to support Secure Boot were Windows 8 and Windows Server 2012. Secure Boot requires computer systems to be running UEFI 2.3.1 (or later). Legacy ROMs or compatibility support modules (CSM) must be disabled in order to enable Secure Boot. In this blog, I will show you how to extend the Configuration Manager hardware inventory so that you can report on the state of Secure Boot in your environment. This will not only tell you which systems have Secure Boot enabled or disabled, but it will also help you detect systems that are not currently running UEFI (the ones running in BIOS mode). Identifying these systems will be helpful when determining the deployment method that you will select when moving to Windows 10. If it is a requirement of your security team that all systems running Windows 10 must also be running Secure Boot, it will give you an idea on how much effort will be involved during the deployment process. […]
Check out the Comments section of the recent post on Tianocore being ported to OpenPOWER:
https://github.com/ozbenh/edk2
So there are TWO ports of Tianocore to OpenPOWER, and a few days ago I knew about neither of them.
I wonder if OpenPOWER will officially adopt UEFI as a firmware option for their platform. I’ve heard indirect bragging from IBM that their systems can be 100% fully open source firmware, no blobs.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Firmware Security 
You must be logged in to post a comment.