Base-board Management Controller (BMC) Firmware Security

The security of the BMC firmware is very important, as compromising it means unfettered remote access to the target machine. There has been research into this area in the not too distant past:

• Exploiting Hardware Management Subsystem, by Simon Clow.
• Reversing Firmware using Radare2, by Anton Kochkov.
• IPMI: Understanding Your Server's Remote Backdoor, by Anthony J. Bonkoski.

All of them are interesting in their own right. Perhaps, Bonkoski's one is the most comprehensive? I don't know. I haven't dig into all of the papers myself.

Anyway, one of the most interesting development in BMC is OpenBMC, see: https://github.com/facebook/openbmc and https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/. Is it going to grant you access to Facebook-class infrastructure (from afar) if you find a flaw in it? Well, I don't think so, as it must've been protected by giant "firewall" in front of it. But, doing a code review on OpenBMC for flaws certainly a good exercise.

As a side note, let's not forget about Fujitsu, one of the most "underrated" server producer on the market. As a parting gift, let's look at what Fujitsu has in store in its BMC:

Fujitsu integrated Remote Management Controller TCP/UDP ports

Firmware/BIOS-related Patent Filings

I don't know if security researchers are used to looking at patent filings--because I'm not officially one of them. However, I found that reading and trying to understand firmware/BIOS-related patent filings is enlightening. It is also interesting because the filings are related to each other via cross-referencing, which make the activity all the more interesting, given enough time to dig into it. Among other thing, it provides a view ahead in this cat and mouse game of protecting and breaking firmware. These are some of my picks (not necessarily new ones):

• Patent 2008/7392541
• Approaches for Ensuring Data Security
• A sort of BIOS Agent
• Pre-Boot Authentication System
• Sector-Based Protection to Flash ROM (Old one)
• HP Lights-Out-Management Patent Filing

The one that interest me the most is the last one because it's a sort of insight into Baseboard Management Controller (BMC) stuff. I hope you enjoy the patent filings as much as I do ;-)

UEFI Boot from Web

I think I've been living under a rock in these last few months and not exactly following UEFI development. Nonetheless, I managed to spot this stuff over at https://firmware.intel.com/develop/server-development-kit. What's interesting is the SDK supports "Firmware Boot from Web" so to speak. This is the relevant excerpt:

The Intel® Server Board S1200RP UEFI Development Kit supports Pre-Execution Environment (PXE) boot for IPV4 and IPV6 networking using on-board and add-in networking devices. Because of added initialization time, network boot for the four onboard networking devices is disabled by default in firmware setup. Users can enable PXE boot for on-board networking by enabling the ’EFI Network’ setting in the firmware setup menu.

EDKII Menu -> Advanced -> Network Configuration

As of SDV.RP.B6, the Intel® Server Board S1200RP UEFI Development Kit supports UEFI HTTP and HTTPS boot. These features are described in whitepapers located on the Tianocore github wiki: https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20White%20papers.

Well, it could be double-edged sword from security standpoint. It depends on who you ask and what it's being used for.

Anyway, this is my take on this:

• My "educated" guess is: This stuff emerge from Intel collaboration with the so-called Hyperscalers--Hyperscalers is what some people call them (http://www.nextplatform.com/category/hyperscale/). The Hyperscalers (Google, Facebook, Amazon, Azure, Alibaba, Baidu, Tencent) are running lots of web servers. Therefore, it makes sense for them to make it possible for their machines to boot just off of the webservers instead of preparing another "PXE Boot server" due to the prevalent web server in their bit barns. I think that Intel wants to trickle-down the same stuff into the masses, but as the first step, the Enterprise sector is what Intel targets.
• Present day flash (is it still Flash??) memory used for firmware storage is spacious enough to cram a (compressed?) HTTP/HTTPS client into it. It would hardly possible to do that just several years ago due to the space constraint in the firmware chip on the motherboard. I didn't say this is impossible years ago because I have worked with extremely limited firmware space in non-PC platform that somehow managed to cram HTTP server into space less than 1MB, along with hardware configuration software stuff. 
• This made it possible to boot from the cloud if anyone wants to implement such a stuff. But, it would entails a huge security "nightmare" if you ask me.

System Address Map Initialization in x86/x64 Architecture Part 1 - Article

New article explaining details of PCI-based system address map initialization is up: http://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/. This is part one of two articles. I started with PCI because the basic knowledge on the bus protocol is essential before moving to part two which covers present day PCIe systems.

AMBA-PCIe Interoperability

The native bus in ARM systems, Advanced Microcontroller Bus Architecture (AMBA)
[see: http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture] has been interoperable with
PCI Express (PCIe) for several years now. These are related documentation that helps understanding
how it works:
1. Designing an AMBA-based SoC with a PCI Express Interface,
   link: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=fcb3ebb3b4537c401230b3f3cd71e7895b7c5518

2. Building a Bridge from PCI Express to AMBA 3 AXI On-Chip Bus,
   link: http://www.synopsys.com/dw/dwtb.php?a=pcie_tb_axi
 
3. This one is even more interesting: Implementing a PCI-Express AMBA interface controller on a Spartan6 FPGA,   link: http://publications.lib.chalmers.se/records/fulltext/176608/176608.pdf
 
This shows how far the layered design of PCIe could interoperate with AMBA bus from ARM.

(First-Party) DMA Malware Paper

This paper is really interesting: http://www.stewin.org/papers/dimvap15-stewin.pdf
---------------------------------------------------
Abstract (excerpt): ... Modern computers contain dedicated hardware such as network and graphics cards. Such devices implement independent execution environments but have direct memory access (DMA) to the host runtime memory. In this work we introduce DMA malware, i. e., malware executed on dedicated hardware to launch stealthy attacks against the host using DMA. DMA malware goes beyond the capability to control DMA hardware.

We implemented DAGGER, a keylogger that attacks Linux and Windows platforms. Our evaluation conrms that DMA malware can efficiently attack kernel structures even if memory address randomization is in place. DMA malware is stealthy to a point where the host cannot detect its presence. We evaluate and discuss possible countermeasures and the (in)effectiveness of hardware extensions such as input/output memory management units (IOMMU).
---------------------------------------------------

For me, the very interesting finding on the paper is the presence of ARCtangent Microcontroller which (acts as the DMA "engine". The vendor of this "vague" MCU is quite hard to come by on G$$gle search. It turns out that ARC International is a subsidiary of Synopsys now. These are the relevant links:

http://en.wikipedia.org/wiki/ARC_International

http://www.synopsys.com/dw/ipdir.php?ds=arc_mpu (I think the paper probably talks about this chip)

http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/ARCEM/Pages/default.aspx

PS: "First Party" DMA is also known as Bus Mastering

Gizmo Board (AMD G-series APU)

Has anyone play with this thing: http://www.gizmosphere.org/why-gizmo/ ? It's very interesting because it uses Coreboot out of the box instead of Legacy-BIOS/UEFI. Well, I'm not sure whether it's possible to use UEFI as it's payload or not (Coreboot support UEFI as its payload).

But from embedded development point of view, just boot straight to Linux from Coreboot ;-). Linux drivers will take care of the rest of system initialization. The interesting thing is, the kit also provides an "explansion" board to tap into the I/O of the x64 system (the AMD G-Series APU), well, I exagerrated a bit, I meant you could hook directly to the I/O which very probably connects to the "southbridge" of the entire system.

Anyway, from pure raw performance point-of-view, this is a real raw power  monster to play with. But, I'm not sure how it compares to BeagleBoard when playing with signal processing. But surely for computer vision stuff, it's certainly very powerful given that OpenCV is tuned for x86 (x64?) architecture by default.

I think it's also an interesting platform to play with Coreboot and to understand the inner working of modern day x86/x64 processor.

Advanced Format HDD (HDD with 4KB Sectors)

Last week I migrated one of my machine to RAID 1 and for the first time using HDD supporting Advanced Format (4KB sectors). I wonder new BIOS/UEFIs implementation support these HDDs natively so that they can be used not in 512Byte sector emulation. Particularly, exposing the HDD capability to the operating system.

Well, of course, the support is very probably via new ATA Command in the ATA command set spec. So, BIOS/UEFI code emits ATA Command to the drive to get info on Advanced Format support and so on. I'm still digging into UEFI spec whether there are specific data structure exposed for that support.

Anyway, GNU parted have support to optimize sector aligning for Advanced Format HDDs. I have a write up on that at: https://sites.google.com/site/pinczakko/slackware-14-software-raid-installation-on-hdd-with-advanced-format-4kb-sectors.

Legacy BIOS Interrupt 13h Drive Numbering

I've been searching for drive numbering in legacy BIOS interrupt 13h for a couple of days when I finally stumbled on this Microsoft documentation: http://support.microsoft.com/kb/62571

This is the relevant excerpt:

The BIOS Interrupt 13H uses a zero-based number for floppy disk drives ("A"= 0, "B"= 1, and so on), and a zero-based number with the high bit (bit 7) set for hard disks ("C"= 80H, "D"= 81H, and so on).

Well, this info might have some use afterall ;-)

PCI Expansion ROM Execution Environment Peculiarity

This post is related to the x86 Segment Descriptor Cache stuff I posted a while ago. In my previous book, this fact is not included. So, what's the weird thing about the PCI Expansion ROM execution environment? Well, it runs in "big-real mode"/unreal mode. It may not sound obvious but this is the excerpt from a related specification:

"When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing."

 To put things in perspective, I plan to just combine it with the upcoming POST Memory Manager article on my website. I haven't had enough time to finish that one.

IOMMU Specification from Intel and AMD

This is just a dump of the links to download AMD and Intel IOMMU specification. For those of you new to IOMMU, a good introductory is at http://en.wikipedia.org/wiki/IOMMU.

Now, the specs:

AMD specs: http://support.amd.com/us/Processor_TechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf and http://support.amd.com/us/Processor_TechDocs/48882.pdf

Intel spec: http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf

Just a note that Intel calls the IOMMU as Virtualization Technology for Directed IO (VT for Directed I/O).