Uncategorized

fwupd and Linux Vendor Firmware Service

I haven’t been covering LVFS and fwupd much. Luckily, Michael Larabel of Phoronix.com has been doing a good job. Richard Hughes has built a Firmware Update for GNOME-based Linux systems. Excerpting from some of Richard’s posts, including his asking for help getting word out to vendors to support it:

fwupd is a simple daemon to allow session software to update device firmware on your local machine. It’s designed for desktops, but this project is also usable on phones, tablets and on headless servers. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool or the system D-Bus interface directly.

I’ve spent the last couple of months talking with various Red Hat partners and other OpenHardware vendors that produce firmware updates. These include most of the laptop vendors that you know and love, along with a few more companies making very specialized hardware. We’ve now got a process, fwupd, that is capable of taking the packaged update and applying it to the hardware using various forms of upload mechanism. We’ve got a specification, AppStream, which is used to describe the updates and provide metadata for what firmware updates are available to be installed. What we were missing was to “close the circle” and provide a web service for small and medium size vendors to use to upload new firmware and make it available to Linux users. Microsoft already provides such a thing for vendors to use, and it’s part of the Microsoft Update service. From the vendors I’ve talked to, the majority don’t want to run any tools on their firmware to generate metadata. Most of them don’t even want to commit to hosting the metadata or firmware files in the same place forever, and with a couple of exceptions actually like the Microsoft Update model. I’ve created a simple web service that’s being called Linux Vendor Firmware Service (perhaps not the final name). You can see the site in action here, although it’s not terribly useful or exciting if you’re not a hardware vendor. If you are vendor that produces firmware and want an access key for the beta site, please let me know. All firmware uploaded will be transferred to the final site, although I’m still waiting to hear back from Red Hat legal about a longer version of the redistribution agreement.

Over the last couple of months I’ve been emailing various tech companies trying to get hold of the right people to implement this. So far the reaction from companies has been enthusiastic and apathetic in equal measures. I’ve had a few vendors testing the process, but I can’t share those names just yet as most companies have been testing with unreleased hardware. This is where you come in. On your Linux computer right now, think about what hardware you own that works in Linux that you know has user-flashable firmware? What about your BIOS, your mouse, or your USB3 hub? Your network card, your RAID card, or your video card? Things I want you to do:

* Find the vendor on the internet, and either raise a support case or send an email. Try and find a technical contact, not just some sales or marketing person
* Tell the vendor that you would like firmware updates when using Linux, and that you’re not able to update the firmware booting to Windows or OS-X
* Tell the vendor that you’re more likely to buy from them again if firmware updates work on Linux
* Inform the vendor about the LVFS project : https://beta-lvfs.rhcloud.com/

At all times I need you to be polite and courteous, after all we’re asking the vendor to spend time (money) on doing something extra for a small fraction of their userbase. Ignoring one email from me is easy, but getting tens or hundreds of support tickets about the same issue is a great way to get an issue escalated up to the people that can actually make changes. So please, spend 15 minutes opening a support ticket or sending an email to a vendor now.

If you know of any vendors, please try to help Richard out with his above request. I hope Richard has contacts at the USB and UEFI trade groups, to directly get word out to their member-vendors.

http://www.fwupd.org/
https://beta-lvfs.rhcloud.com/
https://github.com/hughsie/fwupd
http://www.freedesktop.org/software/appstream/docs/

https://blogs.gnome.org/hughsie/2015/08/13/linux-vendor-firmware-project-we-need-your-help/
https://blogs.gnome.org/hughsie/2015/06/24/introducing-the-linux-vendor-firmware-service/
https://blogs.gnome.org/hughsie/2015/08/21/embargoed-firmware-updates-in-lvfs/
http://www.phoronix.com/scan.php?page=news_item&px=Linux-LVFS-Embargoed
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Vendor-Firmware-S
http://www.phoronix.com/scan.php?page=news_item&px=linux-lvfs-embargoed

Standard
Uncategorized

Preparing for Android firmware updates

Kris Carlon of AndroidPIT has written an article for end-users to help them prepare for a system update for their Android phones. Not bad advice to give to your non-technical friends:

https://www.androidpit.com/what-to-do-before-an-android-update

On UEFI-based systems, like Intel-based Android-IA systems, I’d add:

  • save your ROM with before the update, and again after the update, booting LUV-live and using CHIPSEC.

For ARM-based systems, I wish that ARM had both AArch32 and AArch64 ports of CHIPSEC. Linaro may be porting CHIPSEC to AArch64 as part of LUV. But Linaro seems more focused on AArch64 these days, so AArch32 systems may not have security tools. For x86, there’re extensive bibliographies by LegbaCore and other security researchers on x86 BIOS/UEFI vulnerabilities, but I’ve hard a hard time finding a similar list of ARM vulnerabilities. I presume that’s because most are hidden behind iOS/Android-centric vulnerability, and other ARM-based embedded devices, with the various ARM vendor variations. If there was security data for ARM users to watch for, then the community could help ARM/Linaro with the CHIPSEC ports.

Standard
Uncategorized

Analysis of embedded Linux online firmware update

Earlier this week, w_s_m_i_t_h wrote an article on Reddit, researching the online firmware update of a vendor, including use of wireshark, binwalk, and other tools. The GNU FDL 1.3-licensed posting is listed here:

Roku – A little Roku with my morning coffee; A firmware update MITM technique
https://www.reddit.com/r/netsec/comments/3eu4iv/a_little_roku_with_my_morning_coffee_a_firmware/

Standard
Uncategorized

Hacking Team had other bootkits

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

http://tsyrklevich.net/2015/07/22/hacking-team-0day-market/

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:
http://www.intelsecurity.com/advanced-threat-research/blog.html

Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:

08/19/13,  ASUS BIOS device driver LPE, Firefox RCE added

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE added

See Vlad’s blog for pointers to other Wikileaks.org-based email articles on these two entries.

I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “Uefi_windows_persistent.zip” and “Z5WE1X64.fd” files listed in the Intel ATR blog.

Standard
Uncategorized

Apple Mac Mini EFI firmware update 1.8

As reported by Apple Support, and mentioned by Apple Insider and 9to5Mac news sites, Apple just released a firmware update for Mac Mini hardware for some models.

“This update is recommended for Mac mini (late 2012) models. This update addresses an issue that may prevent a USB keyboard from being recognized after the system wakes from sleep.”

I don’t know specifics of this release, and what security implications this has.

More Information:

https://support.apple.com/en-us/HT201518
https://support.apple.com/kb/DL1828?locale=en_US
http://appleinsider.com/articles/15/07/15/apple-releases-mac-mini-emi-firmware-update-to-fix-usb-keyboard-issue
http://9to5mac.com/2015/07/15/mac-mini-firmware-update-1-8/

Standard
Uncategorized

Rasberry Pi firmware revised to use Linux 4.0

As reported by Michael Larabel in Phoronix, the Raspberry Pi firmware has been changed, it now uses the Linux 4.0 kernel.

As Michael says, “For this low-cost ARM single board computers, the newer kernel is beneficial for new features, file-system improvements, and new device support like when it comes to USB peripherals and adapters.”

More information:
http://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Linux-4.0
https://www.raspberrypi.org/forums/viewtopic.php?t=113753&p=778141

Standard
Uncategorized

UEFI 2.5 ESRT in Linux 4.2

One new feature in UEFI 2.5 is the ESRT (EFI System Resource Table). As reported in Phoronix, ESRT supports has been added to the Linux kernel, and it appears that it’ll be in Linux 4.2. Quoting Peter Jones’ ESRT patch to sysfs on the linux-efi list, describing ESRT:

“The EFI System Resource Table (ESRT) provides a read-only catalog of system components for which the system accepts firmware upgrades via UEFI’s “Capsule Update” feature.  This module allows userland utilities to evaluate what firmware updates can be applied to this system, and potentially arrange for those updates to occur. The ESRT is described as part of the UEFI specification, in version 2.5 which should be available from http://uefi.org/specifications in early 2015.  If you’re a member of the UEFI Forum, information about its addition to the standard is available as UEFI Mantis 1090. For some hardware platforms, additional restrictions may be found at http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx , and additional documentation may be found at  http://download.microsoft.com/download/5/F/5/5F5D16CD-2530-4289-8019-94C6A20BED3C/windows-uefi-firmware-update-platform.docx .”

Peter’s patch adds sysfs files for the EFI System Resource Table (ESRT) under /sys/firmware/efi/esrt and for each EFI System Resource Entry under entries/ as a subdir. See the UEFI 2.5 specification for more details on ESRT.

More Information:

http://www.uefi.org/specifications
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Features-Coming
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-EFI-System-ESRT-Table
http://permalink.gmane.org/gmane.comp.bios.tianocore.scm/3554
http://comments.gmane.org/gmane.linux.kernel.efi/5359

Standard