The authors are research scientists and engineers for Intel Labs. They can be contacted at [email protected], [email protected], and [email protected], respectively. Copyright (c) 2009 Intel Corporation. All rights reserved.
Regular reports from security vendors reveal that malware is becoming increasingly stealthier and more polymorphic. Most malware countermeasures are reactive, such as anti-virus scanning. These measures are no longer very effective in today's computing environment. Intrusion prevention systems address some threats, but also are susceptible to attacks themselves, since these software systems operate at the same privilege level as that of the attacks. Our approach to mitigating this present-day scourge is to protect the critical user applications, such that malware, while still continuing to execute, will not have any negative impact on the security of the application.
The threat vector we address with this research is software-based, automated malware attacks. Malware can install itself on the platform via any of the following vectors:
- Internet downloads. Unsuspecting users can be motivated into installing user-space or kernel-space malware on their platforms under the pretext of other useful software. An example of such malware is scare-ware. Scareware can spoof anti-malware software, software that masquerades as a custom codec for custom video formats. This type of malware is typically downloaded from the Internet. Web drive-by attacks are a subset of this attack vector where an infected web server can infect a client that visits it.
- Buffer overflow. A buffer overflow can be used to execute malware in the context of a supervisor or user process. The root cause of this infection vector is software vulnerabilities.
- Network-based infection. Automated worms propagate malware payloads via instant messaging, peer-to-peer networks, shared drives, and e-mail services.
- Dropped by other malware. Malware toolkits allow malware to extend its behavior by allowing the installation of variants or other malware payloads on an already infected computer.
Note that once malware is installed on the platform, it can use a combination of the following methods to attack PCs:
- Code tampering. Malicious software can tamper with application code thus changing the behavior of the application; for example, not encrypting sensitive data before sending them to the network.
- Unauthorized data access. Malware can snoop data from the application's memory or may modify data without authorization.
- Screen scraping. Malware can read the application screen buffer, extracting information from it.
- Key logging. Malware can hook kernel keyboard handlers thus allowing it to access user input.
- Man-in-the-middle. Malware can replace a valid application or a valid library with a malicious version thereby launching a man-in-the-middle between the user and a remote server.
- Circumvention attacks. Malware can obfuscate an application's resources thus ensuring the application does not run securely. This class of attack is called a circumvention attack, since the attack does not tamper with the application directly, but instead it attacks the environment the application interacts with.
- DOS attacks. Malware can prevent an application from running at all, or can prevent access to key resources the application may need, such as network I/O.
In this article, we describe P-MAPS, a processor-measured service layer that dynamically reduces the trusted computing base (TCB) and verifiably improves the runtime security of user's applications, without interrupting the typical operation of the user OS. We describe the P-MAPS architecture that was built using current Intel processors. Our dynamic usage approach reduces the execution footprint of P-MAPS, making it feasible to protect critical applications on power-sensitive mobile platforms. We also discuss some security usages that can benefit from P-MAPS.
Our goal is to protect applications from software-based attacks that may originate from the infection vectors just listed. The types of attacks that P-MAPS can mitigate are application code tampering, unauthorized access of application data, screen scraping (protected in a limited manner where the application renders the screen buffer itself ), and man-in-the-middle (for example, by running a secure network connection from the protected application). P-MAPS can address circumvention attacks if the library used by the application is also protected. Any use of untrusted libraries by an application are not protected by P-MAPS. Note that P-MAPS does not address DOS attacks on the application. Malware can prevent a P-MAPS-protected application from running, but the unprotected application will not be able to access the resources that P-MAPS has control over; for example, the unprotected application will not have access to secrets provisioned on the platform by a trusted third party (TTP).
Our security goals center on the following activities being carried out:
- Runtime authentication of applications. To ensure that only valid (authenticated) applications are protected, we perform runtime measurement of the application to verify its integrity before affording it any protection. This goal is not specific to the application being protected but it ensures that the P-MAPS capability cannot be used by rogue software.
- Runtime, in-place protection of applications. Once the application is authenticated, we protect its code and data memory in-place within the OS. This approach is in contrast to approaches that isolate the applications into a separate OS or virtual machine .
- Reduction of trusted computing base (TCB). The OS is a general-purpose environment where users can install unknown and potentially malicious kernel modules that can attack a user's applications. Hence, we reduce the large TCB  that trusted third parties depend on by a significant factor by removing the OS services from the protected application's TCB. The applications that can restrict their use of system services to memory allocation and de-allocation benefit the most from this TCB reduction.
- Remote verification of protected execution. The platform should be able to report the state of protected applications. An independent remote verifier should be able to verify the authenticity of the attestation report and its contents.
Any security capability that conflicts with usability is typically not used. Hence, we have the following set of usability goals:
- The existing programming model should not be changed. It should be possible to use P-MAPS on existing applications making only minor changes to the application.
- Low-power and performance impact when protection is active. In order to use P-MAPS on low-power platforms, such as notebooks and mobile Internet devices (MIDs), the expected power overhead of P-MAPS must be minimal and must not impact the power performance of the device when protection is not active.
- No impact on application interaction with the OS. P-MAPS should not impact the OS-scheduled execution of protected and unprotected applications that are executing on the OS. Note that protected applications can still use system services, and the services will have access to only the data that the protected application exposes. However it is important to note that such interaction should be limited to operations that are expected to be untrusted.
- Co-existence with other hardware-based security solutions. P-MAPS can co-exist with other software components that use the hardware capabilities it uses -- Intel Virtualization Technology (Intel VT) and Intel Trusted Execution Technology (Intel TXT). P-MAPS uses these capabilities in a dynamic manner: it uses Intel VT controls while an application is being protected, and it relinquishes Intel VT controls when the application is turned off.