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

Remote Access in Legacy BIOS

In this post I'm going to talk about Remote Access in Legacy BIOS via serial console. I aware some (or most) of you are aware that BIOS has provided management console via serial port for a long time. I have the opportunity to modify a customer custom Geode board BIOS to add support for Serial Console a few years ago. It's a quite nifty but rather buggy implementation though (I meant the serial console module). This one is from AMIBIOS Core8. This is the screen shot from minicom in Arch Linux.

As you can see, the terminal looks like how you would expect it when accessed via real keyboard. Unfortunately, some function keys are not working as expected. You can configure the serial port just like you'd expect on old BIOS with serial port support, i.e. the BAUD rate, flow control, bit-ness (8-bit), etc.. The Remote Access menu in the picture is where one would configure the serial port setting for the remote access (serial console).

I'm "dusting-off" this old board from storage because it's quite a nice board to tinker with. I almost forgot that it has remote BIOS access feature back then. Basically, it works like Linux serial terminal in most embedded Linux boards out there. But, this one is limited. I think many enterprise-class motherboard has this feature back in the day and also today because it's a very crucial feature for remote manageability especially if you have thousands of machine to work with. Keep watching this one guys ;-). It's gonna be interesting..

UEFI replacement for BIOS Int 15h AX=E820h Interface

Those who play with low level code are familiar with the BIOS Int 15h AX=E820h interface to query memory map of the system (x86/x64). In fact, it's probably the safest way to do that.

In EFI/UEFI, the interface is replaced by a new function call interface. The function name is GetMemoryMap() and it's part of EFI/UEFI boot services. The definition of this function as follows:

typedef
EFI_STATUS
GetMemoryMap (
    IN OUT UINTN *MemoryMapSize,
    IN OUT EFI_MEMORY_DESCRIPTOR *MemoryMap,
    OUT UINTN *MapKey,
    OUT UINTN *DescriptorSize,
    OUT UINT32 *DescriptorVersion
);

The meaning of the parameters as follows:

• MemoryMapSize; A pointer to the size, in bytes, of the MemoryMap buffer. On input, this is the size of the buffer allocated by the caller. On output, it is the size of the buffer returned by the firmware if the buffer was large enough, or the size of the buffer needed to contain the map if the buffer was too small.
• MemoryMap; A pointer to the buffer in which firmware places the current memory map. The map is an array of EFI_MEMORY_DESCRIPTORs.
• MapKey; A pointer to the location in which firmware returns the key for the current memory map.
• DescriptorSize; A pointer to the location in which firmware returns the size, in bytes, of an individual EFI_MEMORY_DESCRIPTOR.
• DescriptorVersion; A pointer to the location in which firmware returns the version number associated with the EFI_MEMORY_DESCRIPTOR. See “Related Definitions.”

The definition of the EFI_MEMORY_DESCRIPTOR structure as follows:

//*******************************************************
//EFI_MEMORY_DESCRIPTOR
//*******************************************************
typedef struct {
    UINT32 Type;
    EFI_PHYSICAL_ADDRESS PhysicalStart;
    EFI_VIRTUAL_ADDRESS VirtualStart;
    UINT64 NumberOfPages;
    UINT64 Attribute;
} EFI_MEMORY_DESCRIPTOR

The description above is based on UEFI Spec. v2.3.1 Errata C.

AMI Mega RAC XMS

Long time no posting here :-(.

We've got new stuff to look over now: AMI Mega RAC XMS.
This thing is an out-of-band communication "suite" by AMI. Here's the feature article:
http://www.datacenter-insider.de/themenbereiche/management-planung/system-management/articles/409996/
continued at: http://www.datacenter-insider.de/themenbereiche/management-planung/system-management/articles/409996/index2.html

DOS Protected Mode Interface (DPMI)

DPMI is outdated by today's standard of course. However, in certain situation it comes handy. I've been looking for documents/standards/specifications from my early days of BIOS reversing that could explain most of the 32-bit code I'd seen on the BIOS.

One of the most intriguing terms were the memory related terms, e.g. high memory, upper memory, etc. I came to think that there were no standard(s) at all which govern the use of the term. However, upon reading the DPMI specification, I finally realize that the "gaps" (in my knowledge) between the 16-bit code and 32-bit code on the BIOS are covered by the DPMI specification. Well, not all of them of course because there are still the voodoo mode. But, nonetheless, a large fraction of the missing link is in the DPMI.

For those interested on the spec. This is the link: http://homer.rice.edu/~sandmann/cwsdpmi/dpmispec1.pdf.

Have a nice weekend :-)

Thoughts on Memory Allocation in Firmware (Particularly BIOS/UEFI related)

Memory allocation in firmware is basically not the same as one we would find on applications running in an OS because it's an "OS-free" environment. Therefore, the the benefits of OS protection for "memory allocation gone wild" is virtually non-existent. This puts codes running as part of the firmware execution at more risk compared to code running inside an OS. I have yet to put more scrutiny on the TianoCore (UEFI) implementation for memory allocation functions. Probably, it's much better than those in legacy BIOS modules or other related firmware predating it.

I have particular notes on routines akin to C language malloc(), free() and circular buffer handling functions. Calls to malloc() function in firmware level code is usually quite safe because several malloc()  implementations that I read, implements a sort of rudimentary exception handling which would bail out one module execution if not enough space is found when code in the "requesting" module asks for heap memory. However, there are still lingering possible of error when the module lost a reference to allocated memory due to pointer reassignment. I have yet to see bad behaving code like this. But it seems, the assumption on the malloc() implementation is that these things never happened!

As for circular buffers, this kind of thing is in use mostly to talk to storage devices and other "block" devices which transfers quite large amount of bytes in "block"s. Circular buffer implementations could use contiguous memory space if the code that initialize it found one such an available area. However, it could also be implemented as circular linked-list of fragmented chunks which are not necessarily adjacent in the physical memory. This is where things get interesting. A logic bug in function calling the one of the circular buffer function could result to access in the wrong physical memory address. That could happen if a calling function assumes that the circular buffer is implemented as contiguous physical memory chunks instead of a linked memory chunks (not necessarily contiguous in physical memory addresses). In this case, the developer who code the function calling the circular buffer implementation should be blamed as he/she didn't foresee an impending chaos he/she created. Unfortunately, I have yet to see "exception handling" on firmware-level code dealing with such things.

Passing Parameter(s) to BIOS/UEFI SMI Handlers

There are two ways to pass parameter(s) to SMI handler(s) in BIOS/UEFI:

1. Via the Global Non-Volatile Storage (GNVS). This is a region in the non-volatile storage area. I'm not 100% sure about the physical implementation of the GNVS, but it's part of RAM reserved for Non-Volatile Storage by ACPI BIOS subsystem on the motherboard. [Thanks to Kun-Yi Chen for pointing out].
2. Via General Puupose Registers (GPRs). In this technique physical address pointer is passed via GPR to the SMI handler code. I've been thinking about giving some IDA Pro disassembly for this one. Maybe later. 

There you have it. Next time you encounter a suspicous code with one of the attributes above, it might just be one of them :-).

Desktop Management Interface (DMI) Access Interface

Well, I should make an article about this later because it doesn't make it to my first edition book. First, let me emphasize that we're looking at the DMI Access Interface from the BIOS execution context, not from within an OS context. The DMI v2.0 specification (www-pc.uni-regensburg.de/hardware/TECHDOK/BIOS_DMI_20.PDF) "vaguely" states that the interface to the DMI from the BIOS execution context as follows:

To prevent the proliferation of interfaces for accessing information embedded in the System BIOS, the Desktop Management BIOS Specification will follow the System Device Node model used by Plug and Play, and use Plug and Play BIOS functions to access DMI information. Plug and Play functions 50h-5Fh have been assigned to the DMI BIOS Interface.

Well, it's not immediately clear what does it mean by "Plug and Play functions 50h-5Fh". A closer look into the PnP BIOS spec v1.0A (www.osdever.net/documents/PNPBIOSSpecification-v1.0a.pdf) reveals the crux of the matter. When you read through the PnP BIOS spec v1.0A, what you will find in section 4.4 is a description to the PnP BIOS entry point. Furthermore, try to find function "number" higher than PnP function 43h and you're out of luck. Now, from the description in the DMI v2.0 spec snippet above it's now clear that the higher function "number" (above 43h) is relegated to another spec (presumably after the PnP BIOS spec was ratified). One of them is the DMI spec. PnP BIOS spec was published in 1994, while the DMI spec v2.0 was published in 1996. Therefore, accessing the DMI "services" in BIOS code (or ring-0 code in an OS) is carried-out via PnP BIOS interface at function 50h to 5Fh. It seems all of this past effort was part of the DMTF standardization (I'm not 100% sure).