LKIM: the Linux Kernel Integrity Measurer
Total Page：16
File Type：pdf, Size：1020Kb
LKIM: The Linux Kernel Integrity Measurer J. Aaron Pendergrass and Kathleen N. McGill he Linux Kernel Integrity Measurer (LKIM) is a next-generation technology for the detection of malicious modifications to a running piece of software. Unlike traditional antivirus systems, LKIM does not rely on a database of known malware signatures; instead, LKIM uses a precise model of expected program behavior to verify the consistency of critical data structures at runtime. APL and the Research Directorate of the National Security Agency (NSA) developed the LKIM pro- totype and are now working to transition the technology to a variety of critical govern- ment applications. INTRODUCTION Despite the techniques available to increase confi- cuting software is behaving consistently with its static dence that software is correctly implemented and free definition. Although dynamic integrity measurement from exploitable vulnerabilities, running software is still cannot guarantee that software is trustworthy in the vulnerable to a variety of threats. Many of these threats sense of not being exploitable, it is able to establish that remain relevant to executing software because of inher- any assurance gained by static analysis is maintained by ent limitations of the static techniques, whereas others the executing software. arise from a lack of a trust in the environment in which The Linux Kernel Integrity Measurer (LKIM) is an software is run. For example, even an application that implementation of a dynamic measurement technique has been proved to be free of exploitable vulnerabili- targeting the Linux operating system kernel. Unlike ties may be subverted by a malicious operating system most other systems for malware detection, dynamic or hardware component. For this reason, solutions that integrity measurement systems (IMSs) such as LKIM provide confidence in the correct execution of software do not rely on a database of known malware signa- are an important component in the design of trustwor- tures. This means that LKIM is able to detect previ- thy systems. Dynamic integrity measurement is a tech- ously unknown “zero-day” malware. Although LKIM nique we developed in collaboration with the Research was originally developed to verify the integrity of the Directorate of the National Security Agency (NSA) for Linux kernel, researchers in the Asymmetric Operations periodically establishing confidence that a piece of exe- Department of APL have reconfigured LKIM to target JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013) 509 J. A. PENDERGRASS AND K. N. MCGILL other operating systems as well as application-level soft- the state of a piece of software (referred to as a target). ware. Recently, work on LKIM has shifted from proto- This evidence is presented to the DM in a process called typing activities to real-world deployments, including attestation that supports the trustworthy evaluation of use on APL’s enterprise network and a variety of critical the target’s state. The DM is responsible for evaluating government applications. the presented evidence to determine whether it was col- Traditionally, the arms race against cyber adversaries lected by a valid mechanism and represents a valid state has been reactive. As new attacks and malicious soft- of the target. In general, an IMS should provide the fol- ware are discovered “in the wild,” defensive tools are lowing properties to support a meaningful evaluation of enhanced to defend against these threats. Often, by the the target’s state:1 time these enhancements are deployed, the attackers • Complete results: An MA should be capable of pro- have moved on to new techniques that are once more ducing sufficient measurement data for the DM to invisible to the defender. Antivirus software is probably determine whether the target is in an expected state the best-known tool used to combat malicious software. for all attestation scenarios supported by the IMS. Most antivirus software relies on a set of signatures or “virus definitions” that precisely identify known mal- • Fresh results: An MA should be capable of produc- ware. These definitions must be updated frequently to ing measurement data that represent the target’s protect against the latest known threats. Because of its state recently enough that the DM considers the dependence on known signatures, antivirus software is represented state sufficiently close to the target’s cur- fundamentally unable to defend against novel threats. rent state. Dynamic integrity measurement follows a different approach: rather than attempt to recognize malicious • Flexible results: An MA should be capable of pro - software signatures, it characterizes how legitimate ducing measurement data with adaptability to fulfill software is expected to behave and identifies any devia- the requirements of all attestation scenarios sup- tion as malicious. This idea is not fundamentally new; ported by the IMS. “anomaly detection”-based systems have frequently tried to model legitimate system behavior to flag anything out • Usable results: An MA should be capable of pro - of the ordinary as malicious. LKIM differs from these ducing measurement data in a format that the DM systems in that it does not rely on statistical modeling; can easily evaluate to determine whether the repre- instead, it relies on the fact that software behaves in sented state is expected. very predictable ways according to its source code. The key insight behind LKIM is that malware often changes • Protection from the target: An MA should be pro- the kernel’s state in a way that is inconsistent with the tected from the target so the target cannot corrupt kernel’s source code. By detecting these inconsistencies, the measurement process or measurement data with- LKIM is able to detect previously unknown attacks. out the DM’s detection. We developed LKIM to identify modifications to • a running Linux kernel because malware capable of Minimal impact on the target: An MA should not making such modifications to the kernel, known as require modifications to the target, and execution “kernel-level rootkits,” has complete control over the of the MA should not diminish the target’s perfor- behavior of all software running on a system. Further, mance. because most detection software runs as a process con- In many cases, these properties represent trade-offs trolled by the kernel itself, these rootkits are notoriously between the assurance provided by the measurement difficult to reliably detect. LKIM uses virtualization and system and the impact the measurement system may a technique called virtual-machine (VM) introspection have on the target. For example, LKIM can be config- to analyze the state of the kernel when running outside ured to perform very extensive measurements; however, of that kernel’s direct control. Kernel-level rootkits for because LKIM is competing for computational resources other operating systems, such as Windows or Mac OS, with the running client, the processing time required to present a similar security threat. Although LKIM was compute these measurements may be an unreasonable not initially designed to target these systems, the same imposition on the target. techniques can be used to verify their integrity. LKIM can be run on demand and always produces results reflecting the state of the target at the time it is run; thus, its results are potentially very fresh. This MEASUREMENT PROPERTIES is in stark contrast to static or load-time IMSs, which LKIM is designed to serve as the measurement agent can only provide evidence of the state of the target at (MA) within an IMS capable of supporting a range of the time it was loaded into memory. However, running different decision makers (DMs). Within an IMS, the LKIM frequently may cause unacceptable performance MA is responsible for collecting evidence describing degradation, so caching results for some time may be 510 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013) LINUX KERNEL INTEGRITY MEASURER advantageous. The exact frequency with which to run legacy systems and does make it somewhat more difficult LKIM is still an open research question. Because LKIM’s for rootkits to hide. results represent only a moment in time, a long time It is impossible to develop a measurement system with period between measurements may allow an adversary no impact on the target. Any measurement engine run- to break into a system, accomplish his mission, and ning on the same hardware as the target will have to restore the kernel’s integrity without causing a failed compete for the finite computational resources avail- measurement. In some sense, any window is too long able, such as processor time or memory. We have made because some adversary missions, such as stealing cryp- efforts to minimize the impact LKIM poses on the target tographic keys, may be accomplished in microseconds. both by optimizing LKIM’s code to reduce its use of these A recommended practice is to perform a fresh LKIM resources and by leveraging architectural features such measurement as part of an access control decision such as VM snapshotting to avoid activities such as pausing as network access control. This scheme allows the access the target for long periods of time. Beyond these perfor- control policy to make its decision on the basis of fresh mance impacts, a measurement system may impact the evidence, without unduly burdening the target. development or deployment of updated targets. LKIM Integrity measurement data may be as complex as a requires a precise description of the data structures used complete image of the target’s memory state or as simple by the software it is measuring. This means that legiti- as a single bit indicating whether the target has integ- mate updates to the target may cause LKIM to become rity. These extremes capture the trade-off space between confused and generate false alarms. We partially address the flexibility and the usability of measurement results. this problem by separating the target-dependent aspects Although a complete memory image may be able to sat- of LKIM into a configuration file that should be deployed isfy a wide range of DM policies, it is exceedingly diffi- in sync with updates to the target software.