https://github.com/duo-labs/EFIgy-GUI

https://github.com/ZakSN/FreeBSD-UEFI-secure-boot
“Some instructions about setting up secure boot on FreeBSD in Qemu or on hardware. Uses a single combined loader and kernel, instead of a multi-stage boot process.”
[…]At the platform level, the release unifies the boot concept across all supported x86 microkernels and offers the option to boot 64-bit kernels via UEFI. For both UEFI and legacy boot, Genode consistently uses GRUB2 now.[…]
https://genode.org/documentation/release-notes/17.11
http://genode.org/
Note that NERF is also called LinuxBoot now.
https://twitter.com/qrs/status/935661801064165377
The NERF project is a collaboration with Ron Minnich at Google (creator of LinuxBIOS and coreboot) that aims to build an open, customizable, and slightly more secure firmware for server machines based on using Linux and Heads in the ROM to replace UEFI as the bootloader. Unlike coreboot, NERF doesn’t attempt to replace the chipset initialization code with opensource. Instead it retains the vendor PEI (Pre-EFI environment) code as well as the signed ACM (authenticated code modules) that Intel provides for establishing the TXT (trusted execution environment). The NERF firmware replaces the DXE (Driver Execution Environment) portion of UEFI with a few open source wrappers, the Linux Kernel and the Heads measured runtime.
https://github.com/osresearch/heads/labels/nerf
https://github.com/osresearch/heads
Some notes on the Monotonic Counter in Intel SGX and ME
Posted on November 10, 2017 by daveti
SGX sealing is vulnerable to rollback attacks as the enclave is not able to tell if the sealed data is the latest or a old copy. To mitigate this attack, monotonic counter (MC) has been introduced in Intel SGX SDK 1.8. This post looks into some implementation details inside Intel SGX SDK.[…]
Here’s a 12-page intro to UEFI, written in 2013, just uploaded to Github today:
Dummy repository for UEFI report of HS x12 (Technical Writing) course
Introduction to UEFI Technology
December 2013
Abdd El-Aziz, Mostafa
Tarek, Aly
Eldefrawy, Amr
Intel has updated the advisory page, I think the doc is at v1.3 now:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
The list of OEMs is larger now:
Acer
Compulab
Dell Client
Dell Server
Fujitsu
Getac
HP Inc.
HPE Servers
Intel® NUC, Intel® Compute Stick, and Intel® Compute Card: Support Information
Lenovo
MSI
Panasonic
Quanta/QCT
[…]Western Digital’s leadership role in the RISC-V initiative is significant in that it aims to accelerate the advancement of the technology and the surrounding ecosystem by transitioning its own consumption of processors – over one billion cores per year – to RISC-V.[…]
OEMs: users install Linux on some of the Windows boxes you sell. It is a PITA to update firmware from Linux if you only ship Windows EXEs. Rebooting into an ISO is slightly better. The proper solution for Linux is to support FWUpd.
(And the proper solution for Windows is to support Windows Update. But I heard that only a few OEMs support this, and still require OEM-centric tools to update their firmware. Sigh…)
“So for future reference: Do not set a special symbol as password in your bios. Although it acts like it is correct. It will brick your laptop and this will cost you a new motherboard if you dont find out what the symbol is replaced by.”
OEM/IBV — not just Lenovo — better input validation. Try checking for emojiis too. 😦 Int’l characters are likely to also have issues. A bit more error checking will help users from having to buy new mobos to replace their bricks, big impact!
I recently helped an IPMI vendor with a problem where they would not accept punctuation in passwords, because this misread a security FAQ by David Wheeler, and were afraid punctuation would put them at risk of shell injection attacks.
https://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/validation-basics.html
Matthew has an excellent new blog post on recent Intel ME security news.
https://mjg59.dreamwidth.org/49611.html
[…]The big problem at the moment is that we have no idea what the actual process of compromise is. Intel state that it requires local access, but don’t describe what kind. Local access in this case could simply require the ability to send commands to the ME (possible on any system that has the ME drivers installed), could require direct hardware access to the exposed ME (which would require either kernel access or the ability to install a custom driver) or even the ability to modify system flash (possible only if the attacker has physical access and enough time and skill to take the system apart and modify the flash contents with an SPI programmer). The other thing we don’t know is whether it’s possible for an attacker to modify the system such that the ME is persistently compromised or whether it needs to be re-compromised every time the ME reboots. Note that even the latter is more serious than you might think – the ME may only be rebooted if the system loses power completely, so even a “temporary” compromise could affect a system for a long period of time. It’s also almost impossible to determine if a system is compromised. If the ME is compromised then it’s probably possible for it to roll back any firmware updates but still report that it’s been updated, giving admins a false sense of security. The only way to determine for sure would be to dump the system flash and compare it to a known good image. This is impractical to do at scale. So, overall, given what we know right now it’s hard to say how serious this is in terms of real world impact. It’s unlikely that this is the kind of vulnerability that would be used to attack individual end users – anyone able to compromise a system like this could just backdoor your browser instead with much less effort, and that already gives them your banking details. The people who have the most to worry about here are potential targets of skilled attackers, which means activists, dissidents and companies with interesting personal or business data. It’s hard to make strong recommendations about what to do here without more insight into what the vulnerability actually is, and we may not know that until this presentation next month.[…]
Canonical-based FWTS obviously has Ubuntu packaging, but it now has Debian packaging!
https://ftp-master.debian.org/new/fwts_17.11.00-1.html
Looking forward to seeing an entry for Debian — and any other Linux distro which supports UEFI Secure Boot — alongiside the sole entry by Ubuntu here:
http://kernel.ubuntu.com/git/hwe/fwts.git/tree/src/uefi/securebootcert/sbkeydefs.h
[AFAICT nothing new recently, this is just the August story being rehashed again in November, I think…]
Re: https://firmwaresecurity.com/2017/08/17/apple-secure-enclave-processor-sep-firmware-hacked/
https://twitter.com/kwestin/status/934677472293072896
https://www.theiphonewiki.com/wiki/Greensburg_14G60_%28iPhone6,1%29
https://github.com/xerub/img4lib
Arg, WordPress inserts the entire contents of Github Gists into posts. To view sepsplit.c, remove the 2 spaces from below URL, or click on 2nd t.co-based URL in above @xerub tweet.
https://gist. github.com /xerub/0161aacd7258d31c6a27584f90fa2e8c
Click to access us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf
Hackaday:
Ilya Bizyaev posts on the Intel Android-IA mailing list about working to get Halium port of the ASUS ZenFone5:
I am writing to announce that I am working on a Halium (halium.org) port for ASUS ZenFone 5, a Clovertrail+ based phone. Porting Halium base to this Intel platform enables numerous open-source projects, including Ubuntu Touch (ubports.com), Plasma Mobile (plasma-mobile.org), LuneOS (webos-ports.org) and Mer (merproject.org) to use all of the Clovertrail+ devices for development and testing. I am proud to report that as of now, the Halium build system supports using custom Intel boot tools, and the device boasts a stable 3.10 kernel and Android 7.1-based system build that has Wi-Fi, touch sensor, hardware keys, LEDs and vibrator working.
Full post: android-ia@lists.01.org archives.
https://github.com/Halium/android_kernel_asus_T00F
https://github.com/Halium/android_device_asus_T00F
Hmm, I didn’t know about Halium…
https://halium.org/announcements/2017/04/24/halium-is-in-the-air.html
From the Halium blog’s initial post:
Over the years, various efforts have been made to bring GNU/Linux to mobile devices (for example Maemo, Meego, Mer, SailfishOS, Ubuntu Touch, Plasma Mobile). They have either achieved their individual goals or are working in direction of achieving them. During the development of such projects it was suggested multiple times that these communities should work together as their ultimate goal is the same. However due to various reasons this never happened in the past. However we believe that it is time to change this situation. Currently distributions like AsteroidOS, LuneOS, Mer, Plasma Mobile, SailfishOS, and Ubuntu Touch have one thing in common that they use the libhybris to interact with the android binary blobs and they also run the various android daemons using different methods. And there is lot of fragementation on how this task is handled even though these parts don’t need to be different as their essential goal is to make use of android binary blobs. Project Halium is the effort by the community which aims to bring the common grounds for different distributions and have a common base which includes the Linux kernel, Android Hardware Abstraction Layer, and libhybris. Project Halium also aims to standardize the middlewares used to interact with the hardware of the device. By having these parts shared, we believe that it will reduce the fragmentation we have currently.[…]

Reminder to OEMs: publish the hashes of your platform firmware. Hopefully using codehash.db.
In below twitter thread, Joanna asked Dell support for hashes for their firmware. Eventually, Rick Martinez of Dell got involved, so this is a good example of a conversation on this topic by two who understand the issues.
http://en.community.dell.com/techcenter/extras/m/white_papers/20287278
It looks like Dell needs to use HTTPS:
Quoting the Phoronix post:
“talks range from Linux power management and energy awareness to developments around kernel live patching, NUMA, the state of UEFI support, NVMe, DRM/KMS, and other areas of the Linux kernel. “
https://www.linuxplumbersconf.org/2017/ocw/events/LPC2017/schedule
https://www.linuxplumbersconf.org/2017/audio-recordings-posted/
Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode
Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet
HP Labs
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 such attacks, we propose an event-based behavior monitoring approach that links to 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 solve the semantic gap issue. Our approach does not depend on a specific model of the behavior nor a specific target. We apply this approach to detect system management mode (SMM), a highly privileged x86 executable mode executing firmware code at runtime. We model the behavior of SMM using CPU registers (CR3 and SMBASE). We have two open-source firmware implementations: EDK II and coreboot. We evaluate the ability to detect and detect the effects of 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 (ie, less than the 150 μs threshold defined by Intel).
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.