ISBN 978-952-5726-02-2 (Print), 978-952-5726-03-9 (CD-ROM)
Proceedings of the 2009 International Symposium on Information Processing (ISIP’09)
Huangshan, P. R. China, August 21-23, 2009, pp. 258-262
Advance and Development of Computer
Firmware Security Research
Zhenliu Zhou1, Jiapeng Fan1, Nan Zhang1, and Rongsheng Xu2
1
Department of Information Engineering, Shenyang Institute of Engineering, Shenyang, China
Email: {zhouzl, fanjp, zhangn}@sie.edu.cn
2
Computing Center, Institute of High Energy Physics, CAS, Beijing, China
Email: [email protected]
threatening affairs about BIOS which increased
gradually in recent years have confirmed this.
Security research on IBM PC’s legacy BIOS and
Open Firmware are performed by William A.Arbaugh,
Dexter Kozen and Frank Adelstein in 1997 to 2003
[1][2][3][4]. CIH Virus and its mutations during 1998 to
2002, ACPI rootkit [5] and PCI rootkit [6] announced by
John Heasman in 2006 to 2007, all of these caused
further concern to firmware security. Accompany with
development of trusted computing, it also becomes
necessary for designing and developing trusted firmware
[7][8]. Firmware is playing a more and more important
role in computer system security.
Abstract—Firmware is the important foundation for
computer security. The paper surveys threats to firmware,
methods of detecting vulnerability and malicious code in
firmware, and studies about secure firmware. Problems
and drawbacks existing in security detecting and secure
firmware are analyzed. Some fields worthy to be explored
are put forward including improvement of accuracy and
diversity about firmware security detection system,
standardization of evaluating procedure and result of
firmware security detecting, adding dynamic code
certification and validation to secure firmware, adding
data accessing protection to secure firmware.
Index Terms—Computer Firmware, Trusted Computing,
Code Validation, Secure Firmware
II. COMPUTER FIRMWARE TECHNIQUES
I. INTRODUCTION
A.
Legacy BIOS
Except the next generation of firmware – UEFI
firmware which Intel released in 2003, others firmware
used in computer are all called as legacy BIOS.
Development of legacy BIOS can be divided into two
phases.
The first phase is from early of 80’s to late of 90’s.
The main objective of legacy BIOS in this phase is to
provide an interface to the OS so that the system can
operate the devices such as CPU, chipset, buses,
controllers, and etc, including loading OS from disk. Few
other additional functions exist in this phase.
The second phase is from late of 90’s to nowadays. In
addition to preserving functions fulfilled in the first
phase, other functions such as intelligent device
management and power management that are defined as
APM (Advanced Power Management), PnP (Plug and
Play) and ACPI (Advanced Configuration and Power
Interface) specifications are added in for this phase
legacy BIOS. Applications, for example, system
recovery and U-key attestation tools, are also applied in
firmware. Patching and updating firmware offline or
online becomes ordinary.
Techniques of legacy BIOS is delay comparing with
hardware and OS, this makes legacy BIOS can not take
full advantages of capabilities of other hardware devices
and OS, especially for CPU. Flaws of legacy BIOS
include: (1) running in 16-bit real mode or 32-bit flat
mode, which is impractical for Intel 64 and IA-32
architecture-based platforms, (2) efficiency of
developing and debugging is low and cost to maintain is
Firmware is the low-level software or sequences of
instructions that are written onto programmable
read-only memory (ROM) or flash ROM in a computer
or peripheral device, enabling the device to determine its
capabilities, render them functional, and coordinate
operations. Computer firmware can execute in privileged
mode. In some cases, firmware provides an interface to
the rest of the operating system (OS) so that the system
can operate the device. In other instances, firmware is
executed during the computer’s boot process – for
example, the Basic Input/Output System (BIOS), which
executes before the OS is loaded. Other firmware called
as Option ROM (OPROM) resides on peripheral devices,
allowing the OS to use the devices effectively.
Main function of computer firmware includes: power
on self test (POST), initiating devices, providing boot
services and runtime services, set up and store
configuration data, loading OS.
Firmware attacks can undermine even the most
sophisticated application-level controls or security
mechanisms. Malicious firmware that has unrestricted
access to system components has considerable potential
to cause harm, introduce backdoor access, install new
software, or modify existing software. If the underlying
firmware cannot be trusted, then the OS and application
security mechanisms also cannot be trusted. Attacks and
This research is supported by the development fund for electronic
and information industry, granted by Ministry of Industry and
Information Technology of PR. China
© 2009 ACADEMY PUBLISHER
AP-PROC-CS-09CN002
258
CETC became the only two companies in P.R of China,
who was authorized to develop UEFI firmware product
by Intel, using Intel’s techniques.
TinyBIOS, OpenBIOS and LinuxBIOS are open
source projects or communities about legacy BIOS. Main
drawbacks of these projects include: supports of various
chipset are very limited, running only on some specific
platform, insufficient implement of PnP and ACPI
specification.
increasing for the sake of programming with assembly
language, (3) lack of uniform and open specification
about architecture, construction and services among
different vendor’s legacy BIOS product, (4) lack of
security design from the beginning.
B. UEFI
The Extensible Firmware Interface (EFI) [9], is the
layer between the Operating System and platform
firmware. EFI is the new model for the interface between
operating systems and the platform firmware running
them. The end result of EFI is a standards compliant
environment for running pre-boot applications and for
booting the operating system. In 2005 the Unified EFI
Forum (www.uefi.org) was formed. Using the EFI 1.10
specification as the starting point, this industry group is
now responsible for developing, managing and
promoting the ongoing evolution of the UEFI
specification [10]. The Intel Platform Innovation
Framework for EFI [11] is a product-strength
implementation of EFI and UEFI. The Framework is
Intel's recommended implementation of the EFI
Specification for platforms based on all members of the
Intel® Architecture (IA) family. Open sources of the
Framework is released and maintained in a community
called Tiano (www.tianocore.org).
UEFI and the Intel Platform Innovation Framework
solved those flaws existing in legacy BIOS successfully:
uniform EFI driver and EFI application mode are defined,
debugging tools and protocols at the level of firmware
are provided, unified boot and runtime service calls are
available to the OS and its loader, running in 32-bit
protected mode. So far UEFI has been accepted as
mainstream and factual specification for the next
generation platform firmware. Another firmware
innovation plan called CSS BIOS (Core System Software
BIOS), which is advocated by Phoenix and Microsoft, is
defeated by UEFI because of its inherent flaw in
technologies and safety.
Secure boot and protocols are mentioned in UEFI, but
no implementation in the Framework, and those are not
sufficient to assure firmware’s security. These problems
will be discussed later in the paper.
TABLE I.
DIFFERENCE BETWEEN LEGACY BIOS AND UEFI
UEFI
Firmware
32-bit
protected
mode
Graphics
No.
Characteristics
Legacy BIOS
1
Running mode
16-bit real
mode
2
User interface
3
Programming language
4
Language for Driver
Assembly
language
C language,
EFI Byte
Code
5
Support of TCP/IP
No
Yes
6
Security design
No
Part
No
YES,
EFI Driver
No
Yes,
EFI
Application
7
8
Support of loading
external driver, have
relevant specification
Support of loading
external application,
have relevant
specification
Text
Assembly
language
C language
Ⅲ. HACKING AND DEFENDING FIRMWARE
A. Risk and Threat against Firmware
Functions extended and enhanced gradually in
firmware make it more similar with an mini-OS, this lead
more and more vulnerabilities to come forth in firmware
that can be exploited to attack or access remote computer
through firmware layer. For requirements of patching
and updating firmware online, mainboard manufacturers
usually use flash chip to store firmware. Using of flash
chip makes firmware can be read and re-flashed just by
operation of software tools without any assistant
hardware device under operating system environment. So
the third spiteful party can implant malicious code such
as virus and trojan into firmware. And the increasing
capacity of flash chip also provides burrow for malicious
code.
Risk and threat against firmware can be outlined as
three categories: the first is vulnerabilities existing in
firmware system [12]. Some vulnerability is listed in
Common Vulnerabilities and Exposures List (CVE list).
The second is physical attack on firmware. In this case,
Intruders can juggle some bytes to destroy integrity of
firmware code. That is a kind of denial-of-service attack
and may lead the computer can not boot normally. The
representative of this kind of attack is CIH virus and its
mutation. The third is malicious code implanted into
flash chip, for example BIOS Trojan, ACPI rootkit [5],
C.
Comparison of Legacy BIOS and UEFI
Firmware compliant UEFI is not a simple succession
or improving of legacy BIOS, but an important
innovation in Firmware. Different characteristics of
legacy BIOS and UEFI are listed in Table 1.
D.
Computer Firmware Products
Phoenix Technologies, American Megatrends Inc.
(AMI) and Award Software Inc. are the three dominating
vendors of legacy BIOS during 1980 to 1998. Because of
dissension about copyright and patent, compatibility and
legalization of product are two serious problems the
vendors encountered who try to develop new firmware
product. Award Inc. is incorporated by Phoenix in 1998,
and a new corporation named Insyde is founded to
exploit legacy BIOS and UEFI firmware products
cooperating with Intel. In 2005, BYOSOFT and CISAR
259
PCI rootkit [6], BIOS rootkit [13], and etc. Flash chips
used to store firmware on mainboard can be read and
re-flashed using software tools during OS running, this
makes it feasible to add malicious code into flash chip
locally or remotely.
A kind of BIOS Trojan technique is illustrated as
Figure 1. BIOS Trojan is composed of two sections: shell
code being executed during BIOS running and stone
code being executed during OS running. When computer
is powered on, the shell code gets control of system after
devices and interrupts have been initiated, extracts stone
code, writes it into OS system directory on hard disk,
then modifies OS configuration file to make it can
auto-run after OS is running. Another method is to
allocate reserved memory for stone code applied by shell
code, and set interrupt vector or ACPI hook to the stone
code so as it can be triggered to execute at some time
when OS is running. Remote control and information
accessing through network are done by stone code, the
shell code just acts as a pusher.
theorems that relate the control flow safety, memory
safety, and stack safety of a running program to the block
structure of its compiled form. As a practical matter, the
technique relies on a certifying compiler that produces
particularly well-structured code, so that a verifier can
perform appropriate static checks just prior to runtime.
The user need only trust the verifier, which is a
particularly simple program that can be persuasively
validated by inspection [3]. Drawbacks to ECC include
platform-dependence and fragility with respect to
compiler optimization.
A computer BIOS security detection system is
implemented based on vulnerability scanning and
integrity validation [12]. But the detection system can
only dispose legacy BIOS, not including UEFI firmware.
Further more, integrity validation for modules of
firmware cannot judge if the module’s code is malicious
or not, and integrity validation result usually becomes
nonsensical because of the diversity and complicacy of
imperceptible distinction among BIOS code’s source,
release version, patching reversion, compiling
environment, and etc. Methods of comparing executable
objects with binary characteristic and structural signature
[14][15][16] will be useful for detecting malicious code
in firmware, it will be adopted in next version of that
detection system.
Ⅳ. SECURE FIRMWARE
In 1997, William A. Arbaugh put forward a kind of
computer security bootstrap architecture AEGIS [1].
AEGIS is based on the traditional BIOS of IBM PC, it
ensures the integrity of the code of the firmware BIOS
and improves the security of code at BIOS bootstrap
process by using authentication. But AEGIS lacks
hardware protection and trusted root of hardware. As a
firmware, AEGIS also can’t provide extent protection for
operating system. ECC put forward by Dexter Kozen
[2][3][4] can be used in developing secure firmware to
block part of insecure operations coming from malicious
code. But so far this method works poor in practice for
the sake of its rigid restriction in language security and
support demand to language compiler.
In 2006, Xincheng Wang proposed to save the system
BIOS into TPM (Trusted Platform Module) chip to
defend such attack as Hacks and virus [17]. This requires
not only to modify architecture of computer, CPU, or
mainboard, but also to invalidate the functions such as
patching and updating BIOS on line or off line. Concept
of trusted firmware is put forward and a kind of trusted
UEFI firmware based on Intel Platform Innovation
Framework is implemented by Zhou Zhenliu in 2007 [8].
Figure 1. Technique of BIOS Trojan.
B. Detecting Firmware Threats
There is a blind area for conventional detecting
products such as vulnerability scanner, virus or Trojan
scanner or killer: firmware. These products never detect
security of firmware before. However, it is also
necessary to detect firmware system following the
increasing of firmware hacking.
Security detection for firmware includes vulnerability
scanning and malicious code detection.
Vulnerabilities existing in legacy BIOS are analyzed
and verified systematically by Zhenliu Zhou[12].
Characteristics of vulnerabilities are extracted, and
unified format of vulnerability entry is defined.
Computer BIOS vulnerabilities database is built up
depending on above works.
Dexter Kozen proposed method of Efficient Code
Certification (ECC) to detect malicious code for Open
Firmware [2][3][4] in 2002. ECC guarantees certain
dynamic safety properties of compiled code by
performing efficient static checks. In particular, it
permits implementation of a module that, at boot time,
verifies the safety of the boot firmware before it is run.
This technique relies on certain general mathematical
Ⅴ. A KIND OF TRUSTED FIRMWARE
A. Firmware Act as CRTM
Trusted computing environment requires every
component from hardware level to software level in
whole system is trusted and excludes any component
from system that can not be proved as trusted, such as
malicious-codes, viruses, and Trojans etc. For building
260
CRTM is stored at the highest 64KB block of the flash
ROM, which is protected physically to avoid being
rewritten or re-flashed using software tools.
Digital signature and message digest are adopted for
trust measurement. In UTBIOS producing process,
vendors are required to bind each component together
with a digital signature of message digest of that
component. Trust measuring is done when UTBIOS is
running, digital signature is decrypted to get the message
digest being signed, and then message digest of the entity
being measured is calculated again and compared with
the decrypting result to verify integrity of the entity.
Public and private keys used in this procedure are
corresponding unique, so it is feasible to judge whether
the entity is come from trusted owner or not, and whether
the entity is juggled or not. SHA-1 hash algorithm and
RSA Verification using 2048bits key are used in
UTBIOS.
this trusted computing platform, we should enhance the
lower layers security of computer including hardware
and firmware [18].
Core Root of Trust for Measurement (CRTM) is a
trusted component which includes the first instruction
CPU picks up when power on. CRTM should be trusted
non-conditionally. According to existing computer
architecture, the first instruction picked and executed by
CPU after Power on is located at address 0xFFFFFFF0
(32bit CPU) in BIOS firmware, so taking initial part of
BIOS as CRTM is realizable.
B. Security Requirement for Trusted Firmware and
CRTM
Security Requirements for Trusted Firmware:
The first, Trust Measurement Trust measurement is
the process to verify integrity and authenticity of entities.
Trust measurement can prevent execution of illegal and
malicious Option ROMs, drivers or applications which
come from external to ensure bootstrap process only
executes the code from trusted BIOS manufactures,
devices driver manufactures, or trusted users. Trusted
firmware needs to measure the following three kinds of
code. The first is others code except CRTM in firmware.
The second includes OPROM code, EFI drivers and EFI
applications loaded from external. The third is OS
Loader Code.
The second, Trusted Self-recovery If integrity of
firmware code or data is juggled by unpredictable failure
or attack, the trusted firmware must support safe and
reliable failure self-recovery mechanism to deal with
denial-of-service attack. During the process of recovery,
the recovery contents integrity must be measured too.
The third, Trusted Updating and Patching.
Security Requirements of CRTM
To guarantee source of trust transiting can be safety,
CRTM should content with four preconditions:
The first, CRTM should be protected physically from
being re-flashed. If CRTM is destroyed, trustworthiness
of succeeding measurement would be incredible, and
mechanism of trusted self-recovery would be ruined.
The second, CRTM should have capability of trust
measuring for the next executable code.
The third, CRTM should have trusted self-recovery
mechanism when others component of trusted firmware
is juggled.
The fourth, Set of CRTM code should be minimum
enough to fulfill the functions of precondition 2 and 3 ,
including other essential codes for initiating CPU,
chipset, memory, and etc.
Host
Platform
Reset
Reset
PCR[0-15]
Reset
Vector
Initialize
Code
CRTM
PEI Core
TPM
Recovery
Code
TPM Driver
USB
Device
Hash Code
DXE
EFI
Driver
BDS
EFI
App
TSL
Option
ROM
TPM_Extend
OS Loader
Code
Figure 2. Architecture of UTBIOS.
Ⅵ. TREND AND CHALLENGE ABOUT FIRMWARE
SECURITY
Detection of threats against firmware and study of
secure firmware are the most important fields for
firmware security research. There are still some
problems need to be solved in these fields including
theory and technique.
A. Challenge for Firmware Risk Detecting
The computer BIOS security detection system
implemented by Zhenliu Zhou [12] is only faced to
legacy BIOS, it cannot dispose the next generation UEFI
firmware. So it is necessary to develop a detection
system that can dispose UEFI firmware. Another
problem about the detection system is that not all kinds
of legacy BIOS can be disposed by that system.
Implement of that detection system depends on analysis
results by reverse engineering, and different vendor’s
products of firmware are varied in structure and
C.
Architecture of Trusted Firmware
UTBIOS [12], which architecture is illustrated as
Figure 2, is a trusted firmware building on Intel Platform
Innovation Framework for EFI/UEFI. To fulfill trust
measuring, hash computing code and TPM driver are
embraced in CRTM. Here TPM must be driven as much
as early to satisfy demands of integrity verification and
event logging. USB driver is immigrating from DXE
phase into CRTM so that when self-recovery code is
invoked, the USB storage device can be accessed.
261
[2] Dexter Kozen. Efficient Code Certification. Technical
Report98-1661, Computer Science Department, Cornell
University, January 1998.
[3] Adelstein F, illerman M, Kozen D. Malicious Code
Detection for Open Firmware. Computer Security Applications
Conference, 2002, Proceedings 18th Annual 9-13
Dec.2002:403–412.
[4] Matt Stillerman, Dexter Kozen. Demonstration: Efficient
Code Certification for Open Firmware. Proceedings of the
DARPA Information Survivability Conference and Exposition,
IEEE, 2003.
[5] John Heasman. Implementing and Detecting an ACPI BIOS
Rootkit. Blackhat DC, 2006.
[6] John Heasman. Implementing and Detecting an PCI Rootkit.
Blackhat DC, 2007.
[7] TCG. TCG Specification Architecture Overview
Specification Revision 1.4. August 2007.
[8] Zhenliu Zhou, Rongsheng Xu. BIOS Security Analysis and
a kind of Trusted BIOS. ICICS 2007, Lecture Notes in
Computer Science 4861, pp427-437. Springer 2007.
[9] Intel. Extensible Firmware Interface Specification Version
1.10. December,2002
[10] UEFI Forum. Unified Extensible Firmware Interface
Specification Version 2.0. January, 2006.
[11] Intel. Intel Platform Innovation Framework for EFI
Architecture Specification Version 0.9. September 2003.
[12] Zhenliu Zhou, Baoxu Liu, Yaping Chi, Rongsheng Xu.
Research on Computer BIOS Security Risk Analysis Detection
System. Journal of Computer Engineering, 2007, 33(16),
114-116.
[13]
Icelord.BIOS
Rootkit:Welcome
home,
my
Lord[EB/OL].http://blog.csdn.net/icelord/archive/2007/05/11/1
604884.aspx.
[14] Sabin T. Comparing binaries with graph isomorphisms.
http://razor.bindview.corn/publish/papers/comparing-binaries.h
tml. 2004
[15] Halvar Flake. Structural comparison of executable objects.
In DIMVA, pages 161-173, 2004.
[16] Dullien T, Rolles R. Graph-based comparison of
executable
objects.
http://www.sabre-security.com/files/BinDiffSSTIC05.pdf. 2005
[17] Xincheng Wang, Sun Hong, Cai Ji-ren et al. TPM-Chip
Based Security Startup System Design. Application of
Electronic Technique, 2006,32(10),40-42,51.
[18] TCG. TCG PC Specific Implementation Specification
Version 1.1. August 2003.
[19] G. Morrisett, D. Tarditi, C. Stone, R. Harper, P. Lee. The
TIL/ML compiler: Performance and safety through types. In
1996 Workshop on Compiler Support for Systems Software,
1996.
[20] Greg Morrisett, David Walker, Karl Crary, Neal Glew.
From System F to typed assembly language. In 1998
Symposium on Principles of Programming Languages. IEEE,
January 1998.
[21] George C. Necula. Proof-carrying code. In Proc. 24th
Symp. Principles of Programming Languages. ACM, January
1997.
[22]Drew Dean, Ed Felten, and Dan Wallach. JAVA security:
From HotJava to Netscape and beyond. In Proc. Symp.
Security and Privacy. IEEE, May 1996.
algorithm. So functions should be enhanced and scope of
products being detected should be expanded for that
detection system.
Vulnerabilities in firmware system need to be
mined continuously and vulnerability database needs to
be tamped and standardized.
New methods and techniques to detect malicious
code in firmware still need to be invented. Drawback of
method of comparing executable objects with binary
character is that it depends on the amount of malicious
code samples. Technique of comparing binary code with
structural signature works well in distinguishing
semantic differences between executable codes, this can
be applied to identify tampers to code or changes of
module’s amount, but cannot be used to judge if the code
is malicious or not. Theorem and model about secure
behavior characteristics during firmware running is
deserved to study to improve performance of accuracy
and diversity about the detection system.
Works such as decomposition of firmware image file
and decompression of modules are done through reverse
engineering in the procedure of developing firmware
security detection system. There is neither open
reference material nor unified specification about legacy
BIOS products structure and compressing algorithm.
This makes it very difficult to analyze a new legacy
BIOS product. Another problem is lack of standards to
evaluate the procedure and result of firmware security
detecting.
B. Challenge of Secure Firmware
Trust measurement guarantees integrity and
authenticity of binary code, that is to say, the binary code
is thought as coming from trustworthy vendors or users,
and not being juggled afterwards. This method belongs
to static validation, and it cannot guarantee validity of
code’s behavior while code is running, so trusted binary
objects may damage computer system through improper
operating or accessing, and static relationship of
trustworthiness may be forged.
Dynamic validation and certification is sanguine of
solving above problem. Therefore, it’s still necessary to
study theory and technique about code behavior
verification or restriction. Code certification based on
compiling [19][20][21] and code validation based on
model about secure behavior characteristics [22] aimed
at firmware are two approaches reserved to study to
achieve that goal.
REFERENCES
[1] Arbaugh W.A, Farber D.J, Smith J.M. A Secure and
Reliable Bootstrap Architecture. Security and Privacy, 1997.
Procedings, 1997 IEEE Symposium on 4-7 May 1997: 65-71
262