Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Intel just announced STM at IDF, read Vincent’s blog for more details:
http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html
https://firmware.intel.com/content/smi-transfer-monitor-stm
https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip
Click to access A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf
ACPI is not only in the firmware of Intel-based systems, but it’s also now inside ARM-based systems. Today on the Linaro-ACPI mailing list, there was a patch for ACPI BERT support for AArch64. I think support had already been in for Intel already, unclear how long.
APEI Boot Error Record Table (BERT) support
Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. Once error log is printed out clear error status so it would not be print during next boot again.
ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. The following log is a BERT record after system reboot because of hitting a fatal error.
BERT: Obtained BERT iomem region <00000000fe801000-00000000fe802000> for BERT.
[Hardware Error]: Error record from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section_type: memory error
[Hardware Error]: physical_address: 0x00000000fe800000
[Hardware Error]: physical_address_mask: 0x0000000000000fff
[Hardware Error]: card: 0 module: 1 bank: 0 device: 1 row: 1 column: 1 bit_pos
For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1.
For more information about this patch, see this thread:
https://lists.linaro.org/pipermail/linaro-acpi/2015-August/005611.html
For more on BERT, also see /src/acpi/bert/bert.c in the FirmWareTestSuite (FWTS).
http://www.spinics.net/lists/linux-acpi/msg57384.html
https://lists.linaro.org/mailman/listinfo/linaro-acpi
What: Seattle Area SysAdmin Guild (SASAG) September Meeting
When: September 10, 2015, 19:00-21:00
Where: WTC-E 1st floor conference room (2211 Elliott Avenue, 6th Floor, 6S139, Seattle, WA 98121)
Why: Defending Intel UEFI systems from firmware attackers
In this talk, we’ll give an overview of the open source firmware security tools you can use to help detect ‘bootkits’, ‘firmworms’, and other firmware-level malware (as well as other defects and system failures), as well as some ideas how you might integrate firmware security into your long-term maintenance plan. Tools include: CHIPSEC, UEFITool, UEFI Firmware Parser, and some others discussed in this blog. (I’m not sure about the location, I think it’s the Washington Trade Center.) Unlike most talks on this topic, this talk will target system administrators, not security researchers.
https://github.com/chipsec/chipsec
https://github.com/LongSoft/UEFITool
https://github.com/theopolis/uefi-firmware-parser
http://sasag.org/
UEFITool is useful, so I was looking into OZMTool, a fork of UEFITool, and was wondering what new features it has, what Ozmosis BIOSes were, and how I might be able to use this tool. For me, some of the additional features beyond UEFITool are interesting, but so far I don’t see them as being general-purpose, they require this OEM hw/fw target, so I am not sure that I can use OZMTool.
OZMTool was created to make the process of creating an Ozmosis patched BIOS easier. It is based on UEFITool (awesome application!) by CodeRush. It includes the following useful tools to help you in this process:
–dsdtextract Extracts DSDT from BIOS
–dsdtinject Injects DSDT into BIOS
–ozmupdate Updates clean BIOS with files from old OZM-flavoured one
–ozmextract Extracts Ozmosis files (ffs) from BIOS
–ozmcreate Patches Original BIOS with Ozmosis
–kext2ffs Converts kext-directories to FFS
–dsdt2bios Injects (bigger) DSDT into AmiBoardInfo
–help, -h Print usage (append command to print cmd-usage!)
See the full OSMTool readme for disclaimer.
OZMTool is a fork of UEFITool for us with Ozmosis BIOSes.
https://github.com/tuxuser/UEFITool/tree/OZM/OZMTool
Repo which holds Ozmosis binary BIOSes from Hermit Crab Labs
https://github.com/tuxuser/OzmosisBIOS
Wow, strange history behind this tool. I’m not into the firmware modding community, so didn’t know most of this. Quo Computers is (was?) a kickstarted hardware project with custom BIOS (that requires OZMTool), a Tor darknet-hosted IBV, “Hermit Crab Labs“, that builds special BIOS to use with MacOSX and other OSes. Quo Computer was created by Rashantha De Silva. I’m not sure of the current status of this project. It appears to have been active starting around 2013. The quecomputer.com web site is currently down. Yet Rashantha appears to have logged into the Kickstart page as of last week (“Last login Aug 13 2015”). OZMTool appears to be last updated around 2014. Comments on the kickstart page may indicate some fraud, I’m not sure. There appears to be deeper history pre-Quo, but I’m not digging that far down, I’m just curious about the OZMTool’s features…
Some history behind this BIOS and tool:
http://www.hackintoshosx.com/topic/20657-ozmosis/
http://www.insanelymac.com/forum/topic/291655-ozmosis/
https://www.facebook.com/QUOcomputer
http://quocomputer.com/
http://webcache.googleusercontent.com/search?q=cache:u9ZwLg1EwaUJ:quocomputer.com/+&cd=1&hl=en&ct=clnk&gl=us
http://webcache.googleusercontent.com/search?q=cache:OCVYFyoypvYJ:quocomputer.com/projectq/+&cd=2&hl=en&ct=clnk&gl=us
http://www.techspot.com /article/720-building-a-hackintosh/
http://www.techspot.com /news/51835-projectq-motherboard-promises-to-boot-any-os-in-under-10-seconds.html
Kickstart link with space in it, so you can see the link, else WordPress just converts it to a video:
https://www.kickstarter.com /projects/quo/projectq-run-any-os-the-unique-motherboard/comments
A few excerpts from the kickstart page and the Google web cache of the no-longer-available QuoComputer.com web site, some excerpts:
“509 backers pledged $189,451 to help bring this project to life.”
“Quo Computer: your computer. your configuration. your choice.”
“The first motherboard designed to run ANY Operating System {AOS(TM)} of your choice out of the box.”
projectQ – Run Any OS: The Unique Motherboard
The first motherboard designed to run any Operating System you choose out of the box.
Quo has stunned the computing world with the release of the unparalleled AOS motherboard. A world first, the Z77MX-QUO-AOS was built from the ground up to run any OS. Fitted with premium components, we include custom software and UEFI that initiates the booting of an OS in under 10 seconds. Exclusive to QUO, the AOS motherboard provides system builders worldwide a platform specifically engineered to meet their needs. QUO’s AOS motherboard is the only one in the industry with Firewire 400 and 800 (1394A and 1394B). The motherboard features Intel certified Thunderbolt, Intel LAN for high demand network sharing, and compatible audio in an expandable microATX form factor. Our unrivaled AOS motherboard comes with a 3 year warranty.
Excerpts from the TechSpot stories:
The company said they have perfected the motherboard and have tested the BIOS / UEFI with developers in China, England, Romania and the US. The team plans to continue to support the BIOS / UEFI after release and will ship with a three year warranty. A pledge of $219 will guarantee you’ll be one of the first to own a projectQ motherboard. As of writing, 90 backers have pledged more than $26,000 of the $87,000 needed to get the board into production. The campaign runs until April 1, 2013 so there’s still plenty of time to make it happen. The first 100 pledges will receive the first batch of boards within six weeks, we’re told. The Z77MX-QUO-AOS motherboard, otherwise known as projectQ, is manufactured by Gigabyte as an exclusive OEM project. The Taiwanese manufacturer had quietly embraced the Hackintosh community months before with their own Z77 boards, which feature special code in their UEFI that made booting into OS X much easier. But projectQ goes a step further by using specific Mac compatible components for everything from audio to networking. The board even uses the same Texas Instruments IEEE-1394b OHCI Controller as the Mac Pro for Firewire 400/800 and packs two Thunderbolt ports for good measure — which the outgoing model notably lacks. Add a custom open-source BIOS and you have the workings for a zero effort Hackintosh. Or so is the goal. Now, I’m not really sure what exactly is the back story here and Quo is not telling. The BIOS is credited to a group called HermitCrab Labs and hosted off the public web inside the Tor network. There’s no official affiliation between Quo and HermitCrab Labs — at least none that either party would openly admit to for obvious reasons — but it appears to be an integral part of the hassle-free Hackintosh promise. After you’ve flashed it onto your projectQ motherboard there’s no need for additional third party tools in order to install OS X. You’ll need to download a modified BIOS designed specifically for this board. After you’ve flashed it there’s no need for additional third party tools in order to install OS X.
Last week Damien DeVille posted a long article on how to use VMware Fusion with LLDB to do remote kenel debugging, on a Mac system:
https://twitter.com/revskills/status/632984441565134848
http://ddeville.me/2015/08/kernel-debugging-with-lldb-and-vmware-fusion/
The CE Workgroup of the Linux Foundation occasionally does bids for research or work for related projects. One of the projects they’re interested in is supporting meta-Debian, a Yocto project that integrates with Debian. Earlier this week Tim Bird, Architecture Group Chair, CE Workgroup of the Linux Foundation, announced their proposals, exerpted here to focus on the Debian/Yocto project:
The CE Workgroup of the Linux Foundation occasionally solicits contractors for projects they are considering. The following projects is currently under consideration for funding this year, and the CE Workgroup would be interested in hearing from you if you would like to work on them (and be paid for it!) For a while now, CEWG has been studying the feasibility of combining the Yocto Project with Debian, to create a system for using the Debian distribution for embedded projects. The first proposal above, intends to solicit (paid) contributions to extending CEWGs project to more hardware and to include more libraries in the target distribution. If you are interested and are willing to get paid to work on this (producing or enhancing open source software to benefit the entire embedded industry), then please contact Tim Bird.
http://elinux.org/Supporting_open-spec_development_board_and_libraries_on_meta-debian
For the full announcement, see posting by Tim Bird. I’ve excerpting Tim’s announcement to only mention the meta-Debian project: he also mentioned two other projects, see the full announcement for details on those.
http://lists.celinuxforum.org/pipermail/celinux-dev/2015-August/001074.html
IMO, it would be nice to have Intel contributing to Debian in this way, providing Yocto-based vendors with more opportunities to use Debian, and helping Debian with embedded BSP (and hopefully some QA).
A bit of background on meta-debian, and some related projects:
https://github.com/meta-debian/meta-debian
https://github.com/ystk/linux-poky-debian
https://github.com/ystk/poky-debian
http://pragmatux.org/
The recent Lenovo LSE blunder made most of the world aware of Windows WBPT ACPI table and how the firmware injects an executable into the OS, a feature of Windows that all OEMs are likely using. While the media is wondering about WBPT and why it’s not prominently displayed on many web sites, Xeno of LegbaCore pointed out that Alex Ionescu gave a talk at SyScan 2012 on this specific topic:
ACPI 5.0 Rootkit Attacks Againts Windows 8
Alex Ionescu
This talk will disclose certain new features of the ACPI 5.0 Specification which is now public and was primarily designed to support ACPI on ARM Embedded SoCs for the upcoming release of Windows 8. Some of these new features have important security considerations which have not been traditionally monitored by security products and/or users, specifically in the areas of covert code execution at Ring 0 privileges.
https://www.syscan.org/index.php/download/get/a722b1acb9396d82323da3a78235fdc0/SyScan12Slides.zip
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/program
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/speakers#004
https://www.syscan.org/index.php/download/previous
http://www.alex-ionescu.com/
Thanks for reminding us, Xeno!
HotChips 2015 is happening in Cupertino, California later this month, 23-25th. Today Krste Asanovic posted a message on the RISC-V blog:
RISC-V at HotChips: Analyst Kevin Krewell has posted a HotChips preview at EE Times, which mentions the RISC-V Raven-3 presentation to be made in the last session at HotChips by Yunsup Lee. UC Berkeley will again be sponsoring a table at HotChips to promote RISC-V, so please drop by if you’ll be there and want to chat about RISC-V uptake.
Hot Chips is a symposium on High Performance Chips, sponsored by the IEEE Technical Committee on Microprocessors and Microcomputers, in cooperation with ACM SIGARCH. The RISC-V presentation is on the “Raven” processor:
Raven: A 28nm RISC-V Vector Processor with Integrated Switched-Capacitor DC-DC Converters and Adaptive Clocking
by: Yunsup Lee, Brian Zimmer, Andrew Waterman, Alberto Puggelli, Jaehwa Kwak, Ruzica Jevtic, Ben Keller, Stevo Bailey, Milovan Blagojevic, Pi-Feng Chiu, Henry Cook, Rimas Avizienis, Brian Richards, Elad Alon, Borivoje Nikolic and Krste Asanovic, University of Berkeley
The EE Times blog article, by Kevin Krewell of Tirias Research, gives a good overview of all the vendors presenting at HotChips, focusing on the traditional ones (Intel, ARM, AMD, etc.), and calls RISC-V an “odd duck”. 🙂
The last session on Tuesday is traditionally the main “big” processor session. […] The odd duck in the session is an implementation of UC Berkeley RISC-V Vector Processor. Last year the Berkeley contingent showed off RISC-V instruction set in the break area, but now with a real chip, they made it to inside the auditorium. It’s not too often you see a chip design of this integration and complexity coming from academia. What started as a project to give universities a royalty-free and extendable CPU architecture to build on, has gained traction, especially in India and Asia for development purposes.”
RISC-V and Open Hardware aside, there are many other interesting presentations at Hot Chips 2015, including talks from Intel, ARM, AMD, and others. There are a handful of other Open Hardware/Maker-related talks, eg: Adapteva is talking about their Kickstarted chip, and Univerisity of Wisconson’s MIAOW project, an OpenGL API-compatible GPGPU.
http://www.hotchips.org/
https://blog.riscv.org/
http://www.eetimes.com/author.asp?section_id=36&doc_id=1327424
What: ORConf 2015
When: October 9-11, 2015
Where: Geneva, Switzerland
Who: Open Hardware OEMs/IHVs/ODMs/IBVs/ISVs
Why: NDAs, IP licensing fees, firmware blobs, non-ownership
Here’s the announcement from the lowRISC announcement mailing list:
Please join us October 9th-11th in Geneva, Switzerland for ORConf 2015 [1]. The event is kindly being hosted by CERN at the IdeaSquare. Last year’s ORConf was home to the first public talk on lowRISC and we’re pleased this year it will also be hosting a series of lowRISC and RISC-V discussions, serving as a European lowRISC and RISC-V workshop. ORConf has in recent years grown to cover a range of open source hardware topics beyond the original OpenRISC focus. Expect presentations and discussion on free and open source IP projects, implementations on FPGA and in silicon, verification, EDA tools, licensing and embedded software, to name a few. The event will run from 13:00 until 18:30 on Friday, 09:30 until 19:30 on Saturday, and from 09:30 until 15:30 on Sunday. Friday will consist primarily of breakout sessions, planning, and discussion regarding lowRISC. If you are already contributing or your are thinking of getting involved and want to learn more, you are very welcome to join us. If you would like to present, please do submit a proposal either via the link at the ORConf website or to me at asb@lowrisc.org. We hope to see many of you there – please register here: [2]. If you haven’t been to the blog for a while and are wondering what’s been going on in the world of RISC-V and lowRISC, you may be interested in our summary of the presentations at the second RISC-V workshop [3].
[1] http://openrisc.io/orconf/
[2] http://goo.gl/forms/KRZux8vnyO
[3] http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-one/
http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-two/
http://www.lowrisc.org/blog/2015/08/lowrisc-at-orconf-2015/
LowRISC is related to RISC-V, both are Open Source Hardware ISAs, which IMO is needed for Open Source Hardware (and Free Hardware), else we’ll always have to deal with NDAs, IP licensing fees, and — on most platforms — closed-source firmware blobs, and not knowing what the system is actually doing behind the scenes. I hope the Linux Foundation, FreeBSD Foundation, Open Source Hardware Foundation, the Free Software Foundation (for Free Hardware) and other related groups plan on using CrowdSupply — or other crowdfunding source — to fund lowRISC/RISC-V-based hardware. You can’t expect change from the top, Microsoft and Apple drive the ISAs and have zero incentive to reduce NDAs, IP licensing fees and firmware blobs. I hope that in a few years Purism starts using RISC-V (or lowRISC, or OpenRISC) for their systems!
http://lowrisc.org/
http://riscv.org/
OpenRISC is a “Free Hardware” ISA, a GPL-based instruction set that has been around for a while. This conference is apparently open to other topics beyond OpenRISC, such as the newer BSD-licensed lowRISC and RISV-V peers. I don’t know why, but I’m guessing that OpenRISC hasn’t gotten more traction is due to hardware’s community’s fear of GPL, or they were just too early to market. It might be nice for the FSF to help OpenRISC more than they have, since it is the only GPL ISA, pehaps the heart of their Free Hardware? Then again, BSD-based RISC-V/lowRISC can easily be GPL’ed.
http://openrisc.io/
Note that the Call for Papers is open, there’s time to submit a talk…
The other day I asked on the UEFI development list about hardware options for debugging UEFI, for security researchers (many UEFI debugging solutions only target OEMs/IBVs/IHVs). I was mainly thinking about Intel Tunnel Mountain, and related widgets like the Intel ITP-XDP, and other options in addition to AMI’s AMIdebug and Arium’s ITP products. It looks interesting; previously, all I knew of was Arium’s ITP and AMI’s AMIdebug products. Some of the commercial tools (eg, Arium) have new, expensive, closed-source debuggers, and don’t enable use of existing GDB/Windbg skills.
Zachary Gray of of the Intel System Studio debugger team replied with some answers:
Tunnel Mountain is OK but it is a bit old (by Intel standards) If you are looking for a small target for UEFI research purposes I *strongly* recommend the MinnowBoard Max. This target has a freely available firmware that is mostly public, you can compile the firmware with GCC or MSVC, it is debuggable using JTAG (Arium, or our Intel System Studio debugger with the ITP-XDP3 probe) and it is also debuggable using the Agent-based solution that is built into the image (cheap and easy!).
With regards to Intel System Studio vs Arium, I would say that the Arium JTAG debugger has a broader feature set that is proportional to their price, but the System Studio JTAG debugger also provides a useful feature set at a lower cost. We can debug all the UEFI code from reset to boot loader, and also into the OS if you have an interest there as well. With any of these debug tools you do not need a special compiler, you just use a standard debuggable build of the firmware.
Another even cheaper alternative would be to debug an Intel Galileo board using a low-cost FTDI probe such as an Olimex with the OpenOCD open-source JTAG debug server. The board + probe would be <$200 and the firmware is publicly available. For a front-end to the OpenOCD debug server you can use either the Intel System Studio debugger, or simply use GDB. Some google searches will lead you to some documentation on all this. The catch is that Galileo is not a “normal” Intel CPU so depending on your research interest the firmware may not present the concepts you are interested in.
Bruce Cran also replied with a lower-cost options:
Another even cheaper alternative, if you don’t need real hardware, is qemu+OVMF. It’s what I use to debug UEFI problems with the PCI driver I work on (using gdb).
Alternatively, if you don’t need an x86-based system, I believe the BeagleBone/BeagleBoard (with ARM CPU) can be reflashed to edk2 firmware and debugged with a Flyswatter2 – with the main problem likely being being surface-mounting the JTAG header!
I also received some more advice via private email, from a firmware security researcher. Paraphrasing, they felt that the MinnowboardMAX is not much better than the Galileo for UEFI debugging, because it has many more blobs in it’s “open source” BIOS, and the Minnow is harder to debug than Galileo, since modern Atom CPUs are complex. Their advice was low-cost debugging was Galileo over Minnow, $20 for JTAG probe, and free GDB.
Thanks for all the advice!!
Obviously, this post doesn’t cover ARM [much], just Intel and virtual solutions. I’m still learning the best options for ARM-based hardware and UEFI, and will post another article on ARM in the future.
More Information:
https://software.intel.com/en-us/articles/using-intel-system-debugger-with-openocd
https://communities.intel.com/docs/DOC-22203
https://communities.intel.com/message/220257
https://communities.intel.com/message/220383
https://communities.intel.com/thread/48127
https://software.intel.com/en-us/forums/topic/391211
https://software.intel.com/en-us/forums/topic/531765
https://designintools.intel.com/product_p/itpxdp3brext.htm
https://communities.intel.com/community/makers
http://openocd.org/
http://www.minnowboard.org/
https://www.olimex.com/Products/ARM/JTAG/_resources/OpenOCD/
https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/
http://www.tincantools.com/wiki/Compiling_OpenOCD
https://designintools.intel.com/product_p/itpxdp3brext.htm
http://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool#overlay-context=develop
https://software.intel.com/en-us/intel-system-studio
https://software.intel.com/en-us/intel-system-debugger
http://tunnelmountain.net/
http://www.dediprog.com/
There’s a LOT of UEFI firmware-centric stuff that could be added to Volatility. I hope some creative security researchers consider some of the ‘low-hanging fruit’, they are offering $$ as reward for the code. 🙂 Integration with CHIPSEC’s library for forensic examination. Tianocore’s GUIDs and structure signatures, TE image format (small tweaks to PE+), firmware volume and capsule and related container formats. I wonder if Volatility can be ported to UEFI’s CPython 2.7x, so it can be used inside UEFI, and have much more access to the system? If not ported, then a bridge to an OS-level Volatility talking to CPython inside an OVMF? There’s a lot of existing Python code on exising Github projects that could be refactored, as well.
http://www.volatilityfoundation.org/#!2015/c1qp0
Home of The Volatility Foundation | Volatility Memory Forensics
Alex Ionescu just created a new project to help with Visual Studio / EDK-II integration.
https://twitter.com/aionescu/status/632594173414129664
https://github.com/ionescu007/VisualUefi
Excerpting from it’s readme, VisualUEFI is 3 things:
1) a Solution and set of Visual Studio 2015 Project Files to allow building the official EDK-II without the use of inf files, Python and 50 other build tools, a custom dependency tracker and build system, and twenty other custom pieces of code. The EDK-II is present as a submodule, directly from the official TianoCore Tree, and no changes are done to it.
2) a Solution and couple of Visual Studio 2015 Project Files to show two UEFI sample components: A UEFI Application, and a UEFI Boot Driver. The code is 100% EDK-II compatible, but built with VisualUEFI instead.
3) a working copy of QEMU64 2.3 for Windows, with a fairly recent UEFI 2.5 OVMF Secure Boot ROM. These will updated on an ongoing basis as needed. This is integrated with the Visual Studio 2015 Sample Solution so that pressing F5 will spin up the instance for testing.
You should be able to open the EDK-II.SLN file and build without any issues in Visual Studio 2015. WDK or other 3rd party installations are not needed. Once the EDK-II libraries are built, you should be able to open the SAMPLES.SLN file and build the two samples, which will create UefiApplication.efi and UefiDriver.efi.
You can press F5 (Run/Debug) from within the Sample Solution, which should spin up the QEMU instance with 512MB of ram, and your release directory as a virtual file system accessible through “fs0:”. You can then try loading the driver with “Load fs0:\UefiDriver.efi”. You can verify its presence by using the Drivers or DevTree commands.
Visual UEFI looks like a nice improvement to Microsoft’s Visual Studio IDE. Thanks, Alex!
(This is the kind of thing I kept expecting the UEFI Forum to release, as an Eclipse plugin, like Yocto and some related projects have done.)
I’m new to Twitter, still don’t have an account. A while ago I started looking into the right Twitter feeds to read:
but I’ve not updated that list in a while. Luckily for me, Jacob Torrey, one of the firmware researchers on above list the helped me out by creating (and maintaining) an EXCELLENT list of Twitter feeds for firmware research:
https://twitter.com/JacobTorrey/lists/firmware-security/members
I’ve got a lot more OEM/IHV/etc Twitter feeds since 0.3, will be working on a 0.4 release, but I can’t match Jacob’s list. Check it out!
Yesterday Neil Versel of MedCityNews reported about an alleged firmware-based attack against a Hospira medical device was a sham, the ‘hacker’ staged it, at least that is the response from the medical device maker. Excerpt of Neil’s article:
“In the video, filmed during a live demonstration on stage at the recent BlackBerry Security Summit 2015 in New York, BlackBerry’s Graham Murphy physically connected a laptop to the pump’s Ethernet port, then took control of the medical device. He then did the same via Wi-Fi. In both cases, he relied on the fact that the FCC ID on the pump helped Murphy identify the specific, fixed IP address associated with the product. But Hospira said BlackBerry also did something the audience did not see. “Part of our investigation into the LifeCare PCA infusion pump demonstration included a conversation with one of the ‘hackers’ who admitted that they manipulated the firmware on the device by having physical access to it prior to their demonstration of the hack. This was not a remote or wireless ‘hack’ as the video implied and physical access to the device would be required to alter the settings as shown in the video,” the Hospira statement said. “These demonstrated hacks were done in non-clinical environments without the security protections and protocols typical of real patient care settings. For patient use, these devices are connected to hospital networks and any attempts to remotely attack an infusion device would require penetration of several layers of network security enforce by the hospital, including firewalls. These measures serve as the primary defense against tampering with a medical device.” At least let’s hope every hospital that uses one of these pumps has better security. If not, you probably should avoid treatment there just to be safe, and the CIO should be fired. Just sayin’.
Full article:
http://crackberry.com/blackberry-security-summit-2015-live-blog
There’s a lot of history here:
http://www.cvedetails.com/vulnerability-list/vendor_id-15332/product_id-32031/Hospira-Lifecare-Pcainfusion-Firmware.html
http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm446809.htm
http://www.wired.com/2015/06/hackers-can-send-fatal-doses-hospital-drug-pumps/
Security hole in Hospira hospital drug pumps could let through fatal doses
https://www.google.com/?gws_rd=ssl#q=hospira+firmware+security
Today, Jody Cloutier of Microsoft announced upcoming changes to Microsoft’s root certs.
Notice of Pending Microsoft Root Update: On August 18, 2015, Microsoft’s Trusted Root Certificate Program will release a scheduled update to the Trusted Root Store. This update will include the addition of EKUs to roots owned by two current partners of Microsoft’s Trusted Root Certificate Program: Guang Dong Certificate Authority, based out of China, and Government of India, CCA. Microsoft will be enabling Guang Dong’s root, GDCA TrustAUTH R5 ROOT, for EV (Extended Validation); Microsoft will be enabling the Government of India, CCA’s root, CCA India 2015, for Server Authentication and Code Signing. To download the new root package for testing, please visit http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/test
For the most-current list of Program participants and enrolled roots, please see
http://social.technet.microsoft.com/wiki/contents/articles/31634.microsoft-trusted-root-certificate-program-participants.aspx
http://aka.ms/rootcert
(The WindowsUpdate.com URL above doesn’ t work for me, perhaps I need to be running Windows, or be a member of the CA/Browser Forum?)
Anyway, this makes me wonder about the new PKI burned into silicon, at multiple levels, see the various PKI used by Intel these days:
firmwaresecurity.com/2015/08/01/book-review-platform-embedded-security-technology-revealed/
But specifically for UEFI, the Secure Boot PKI, any OEM/IHV signed drivers: how do consumers test — via OSCP, CRL, or other mechanisms — that their certs are valid/up-to-date? Same goes for PKI in coreboot used in Chrome, in Verified U-Boot, and most firmware security technologies. If you’re building UEFI with Secure Boot enabled for QEMU/OVMF from source, you can test the certs you’re building with. But once the consumer has a system with all the baked-in certs in the firmware, how does a system administrator test the certs? Most of the crypto-based security features in UEFI (and elsewhere) is only good if you can trust the certs, and you need to be able to check them in order to trust them, over time. I wish I knew the answer. If someone knows the answer, please email me, thanks!
(BTW: quick howto use this WordPress blog. Clicking on upper-left icon drops down a menu with a tag cloud, a search dialog, and a blogroll. I’ll fix the archives/history there eventually… If you click on the ‘firmware hacking logo’ in the top, that’ll email me. All this is stock WordPress.com defaults, I’m slowly learning how to customize and improve WordPress sites. Please email me if you have any serious usability issues that I can fix. Working on adding some static HTML files as Resources off top of main page via “menu”… Everything is in the “uncategorized” category, don’t bother looking for other categories; instead of categories, use the search or tag features, eventually the archives/history may become useful.)
[UPDATE: just confirmed that ACPI.info’s links page had the WPBT link since 2011. After posting below article, I wondered if the ACPI.info webmaster updated their links page in the last few days…)
https://web.archive.org/web/20111208014141/http://www.acpi.info/links.htm
While the media is currently blaming Lenovo for sloppy Windows QA, they’re also waking up to the reality that Windows has been using for the last few years. Initial Ars Technica and YCombinator posts on the topic quoted the abstract to the spec on a web page that was no longer available, so it sounds conspiratorial. But the doc has been online since 2011. Besides microsoft.com-based links, the ACPI.info web site maintains a good set of links, including a pointer to the WPBT spec, and other ACPI-related table specs.
http://www.acpi.info/links.htm
The ACPI specs — at least some of them? — are maintained by the UEFI Forum. The UEFI Forum’s web site does NOT have a link to the WPBT spec.
I’ll bet there’re a few other existing ‘unknown’ ACPI features hidden on the ACPI.info links page that’ll be ‘discovered’ in the next few months, due to another sloppy OEM or sharp security researcher… From above links URL, here’ s a partial list (I omitted multiple entries which’re specs for other hardware, and some of those might also include ACPI tables) of ACPI tables to attack:
Core System Resources Table, CSRT
Debug Port Table, DBGP
Debug Port Table 2, DBG2
DMA Remapping Table, DMAR
IA-PC High Precision Event Timer Table, HPET
I/O Virtualization Reporting Structure, IVRS
iSCSI Boot Firmware Table, IBFT
Management Controller Host Interface Table, MCHI
Microsoft Software Licensing Tables, MSDM, SLIC
Multiprocessor Startup for ARM Platforms
PCI SIG’s MCFG
Serial Port Console Redirection Table, SPCR
Server Platform Management Interface Table, SPMI
Simple Boot Flag Table, BOOT
Smart Battery System Components and SMBus Spec
Trusted Platform Module 2 Table, TPM2
Trusted Computing Platform Alliance Capabilities Table, TCPA
Watchdog Action Table, WDAT
Watchdog Timer Resource Table, WDRT
Windows ACPI Emulated Devices Table, WAET
Windows Platform Binary Table, WPBT
Quoting Wikipedia on ACPI security risks:
“Ubuntu Linux founder Mark Shuttleworth has likened ACPI to Trojan horses. He has described proprietary firmware (ACPI-related or any other firmware) as a security risk, saying that “firmware on your device is the NSA’s best friend” and calling firmware (ACPI or non-ACPI) “a Trojan horse of monumental proportions”. He has pointed out that low quality, closed source firmware is a major threat to system security: “Your biggest mistake is to assume that the NSA is the only institution abusing this position of trust — in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity, courtesy of incompetence of the highest degree from manufacturers, and competence of the highest degree from a very wide range of such agencies”. As a solution to this problem, he has called for declarative firmware (ACPI or non-ACPI). Firmware should be open-source so that the code can be checked and verified. Firmware should be declarative, meaning that it should describe “hardware linkage and dependencies” and should not include executable code.”
Vendors need to be disclosing a LOT MORE information about what they’ve included in their firmware, now that people are aware of this, thanks to Lenovo. It is easy to fix OEM’s mistakes at OS level, by reinstalling an open source OS, or installing vanilla Windows and then getting the drivers from the OEM/IHVs. But you can’t update your system’s firmware, and ACPI is the new dumping ground for OEM bloat. Well, not new, just newly-realized by some of us. I want a system with absolute minimail ACPI table bloat, and I want to KNOW what tables are shipped on the firmware. Linux OEMs: don’t ship COTS firmware that has Windows-centric ACPI blobs in them. If you look on #UEFI on G+ and Twitter, you’ll find more and more people demanding Open Hardware and fully-open source firmware, which is refreshing. 🙂
This week at the Flash Memory Summit, the Trusted Computing Group (TCG) and NVM Express (NVMe), put out a new joint white paper called “TCG Storage, Opal, and NVMe“. Opal is a set of specs from the TCG, designed to add TCG-style security to NVMe-based storage devices (‘self-encrypting drives’ (SED’), by adding new technology layers to manage encryption of user data, to enable features beyond ‘data at rest protection’. The ‘family’ of Opal specs include 3 levels: Opal, Opalite, and Pyrite, which provides a range of capabilities for vendors to choose from.
From their whitepaper’s summary, Oval offers these values to NVMe:
* Avoids the need to add security to NVM Express standard, or rely on proprietary functionality
* Leverages the existing storage security industry standard for a consistent set of requirements
* Commonly associated features enable a more consistent and secure overall solution
* Simplifies ecosystem enabling, validation, product identification, SKU management
* Reduces standardization to a more streamlined process
* Provides an extensible interface for additional value-adds to Opal/Opalite/Pyrite functionality, as well as other storage security features
I’m not sure if UEFI 2.5 has this ability or not. UEFI 2.5 did add some new NVMe and crypto storage interfaces, though.
https://www.trustedcomputinggroup.org/resources/tcg_data_security_architects_guide
https://www.trustedcomputinggroup.org/developers/storage
http://www.trustedcomputinggroup.org/media_room/events/190
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_and_nvme
http://www.trustedcomputinggroup.org/media_room/news/400
http://www.flashmemorysummit.com/
PS: Going off-topic(?) a bit, but for NVMe and Linux, check out this doc from June:
https://communities.intel.com/community/itpeernetwork/blog/2015/06/09/nvm-express-linux-driver-support-decoded
RW, aka RWEverything (Read and Write Everything) is a GUI Windows-based firmware utility, written by Jeff.
“This utility access almost all the computer hardware, including PCI (PCI Express), PCI Index/Data, Memory, Memory Index/Data, I/O Space, I/O Index/Data, Super I/O, Clock Generator, DIMM SPD, SMBus Device, CPU MSR Registers, ATA/ATAPI Identify Data, Disk Read Write, ACPI Tables Dump (include AML decode), Embedded Controller, USB Information, SMBIOS Structures, PCI Option ROMs, MP Configuration Table, E820, EDID and Remote Access. And also a Command Window is provided to access hardware manually. Powerful utility for hardware engineers, firmware (BIOS) engineers, driver developers, QA engineers, performance test engineers, diagnostic engineers, etc.”
“This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial products.”
RW supports multiple Super I/O devices (Winbond (18), ITE (12), SMSC (8), FinTek (4), Nuvoton (6)) and SMBus Controllers (Intel (9), SiS (6), VIA (4), ULi (4), ATI (3), nVidia (13)).
It is Windows-centric utility, shipping with Win32 or Win64 binaries. It has an extensive ChangeLog, spanning v1.6.8 from 8/6/2015 to v0.1 back around 2005, but does not ship with any documentation, just EXEs. If you use Windows, you might want to check this out. If you find the tool useful, the author has a Donate button on his home page, please consider donating to the program’s author. I wish the tool was open source, and supported multiple operating systems, …but I’ll take what I can get. Thanks Jeff!
Yesterday, Absolute announced that they’ve joined the RSA Ready Technology Partnership Program.
“Absolute announced today a new collaboration with RSA to offer enhanced endpoint data collection and remediation. As part of the RSA Ready Technology Partnership program, this effort is designed to deliver seamless interoperability between Absolute and RSA Security Analytics, an industry leading advanced threat detection and forensics platform. Using the Absolute SIEM connector, mutual customers can now get deeper visibility into their endpoint deployments by feeding vital Absolute endpoint data directly into the RSA Security Analytics monitoring platform. If an endpoint security alert is triggered, customers will be able to promptly investigate and respond to potential threats within the broader context of the RSA Security Analytics environment. Customers will also be able to correlate logs, packets, NetFlow, and endpoint data, all within the same platform.”
“Absolute’s Persistence(R) technology is embedded into the core of most devices at the factory. Once activated, it provides organizations with comprehensive visibility into all of their devices so they can confidently manage mobility, investigate potential threats, and take action if a security incident occurs. Most importantly, they can apply remote security measures to protect each device and the data it contains.”
See the full announcement for more details:
http://blogs.absolute.com/blog/absolute-joins-the-rsa-ready-technology-partnership-program/
Absolute’s CompuTrace is a unique security tool for firmware, it’s device is embedded into many (most?) modern systems, and the device checks if software support is disabled in the firmware, and re-enables it.
“Absolute Data & Device Security (DDS), formerly Absolute Computrace, is an adaptive endpoint security solution. It provides you with a persistent connection to all of your endpoints and the data they contain.”
“Our OEM partners embed Persistence technology into the BIOS or firmware of computers, netbooks, tablets, and smartphones during the manufacturing process. Once activated, customers who purchase these devices benefit from an extra level of security, persistence, and support.”
“Persistence technology from Absolute provides you with visibility and control over all of your devices, regardless of user or location. If an Absolute software client is removed from an endpoint, it will automatically reinstall so you can secure each device and the sensitive data it contains. No other technology can do this. Persistence technology is built into tens of millions of devices around the world and provides organizations with a trusted lifeline to each device in their deployment, regardless of user or location.”
You can use UEFITool to see if Absolute is in your firmware by searching for “computrace” Unicode string.
http://www.absolute.com/en/partners/compatibility
http://www.absolute.com/en/products/dds
https://lojack.absolute.com/en-gb/corporate/bios-compatibility
http://www.absolute.com/en/products/dds/requirements
The coreboot project has a Google Summer of Code (GSoC) going on, a few students have been contributing new features to coreboot over the Summer. One effort is Lukasz Dmitrowski and the GUI “End user flash tool”:
Main purpose of End user flash tool project is to provide an easy way to build and flash coreboot ROM. To achieve it there is a need to collect hardware specific data such as:
* lspci -nn output: information about all PCI buses and devices in the system, it is possible to recognize a graphic card, its vendor and device codes
* dump of factory BIOS: it is important to make a copy of factory BIOS in case something will go wrong, but not only in this case, very often there is a need to use a VGABIOS extracted from factory BIOS if particular graphic card or display panel is present in our system, it is the best to make dump two times and then check if files are the same (for example by comparing hashes)
The GSoC ends next week, and Lukasz needs some testing help, especially if you have a Lenovo T60 laptop:
GSoC ends in next week, application is almost done (but will be improved and extended also after GSoC), so this is time for some testing! I would be very grateful if some of you could help me with it. It would be the best if you have Lenovo T60 and external programmer. First there is a need to collect some hardware specific data and then it would be possible to check if application creates working coreboot image basing on this data. So it is not only about testing, but also about making white list of hardware configurations bigger to let more users flash their hardware with coreboot in easy way!
See the full blog post for contact info for Lukasz:
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.