Penetration Test Report (Matasano): Matasano SourceT Security Evaluation Report

Secure 64 SourceT OS
Security Evaluation Report
Matasano Security, LLC
November 20, 2007
Table of Contents
1. Executive Summary 1
1.1 Introduction 1
1.2 Summary of Findings 1
2. Methodology 2
3. Overview of Secure64 Technology 2
4. Areas of Analysis 3
4.1 Code Injection 3
4.1.1 Traditional Application Model Code Injection 3
4.1.2 Secure64 SourceT Application Code Injection 9
4.2 Privilege escalation 17
4.2.1 Traditional model privilege escalation 18
4.2.2 Secure64 SourceT Privilege Escalation 19
4.3 Boot Process 21
4.3.1 Traditional Boot process 21
4.3.2 Secure64 SourceT Boot process 22
5. Conclusions 24
6. Matasano Background 25
6.1 Corporate Overview 25
6.2 Locations 26
Secure64 SourceT OS Security Evaluation Report i
1. Executive Summary
1.1 Introduction
Matasano was tasked by Secure64 to evaluate critically the claim that, for remote attackers,
SourceT is ”immune to all forms of malware, including rootkits, Trojans, viruses and worms.” To
do this, Matasano evaluated SourceT against three areas of vulnerability: code injection,
privilege level escalation, and alteration or subversion of the trusted boot process. These areas
were selected as they comprise the strategy of typical malware such as worms, spyware or
trojan horse applications to introduce arbitrary code into a computing system.
1.2 Summary of Findings
No method for the injection of arbitrary code was identified in architectural analysis. By
eliminating any location an attacker can write executable code, it becomes very difficult for any
traditional form of attack to result in controllable execution by an attacker. While the potential
exists for exploits, they are of a decidedly application specific nature, depending on the presence
of certain elements arranged in a particular manner, such as function pointers that can be
overwritten via user supplied data, and cause the execution of functions already present in the
application that would grant some level of programatic control. Such a scenario, while possible,
can be avoided through sound application architecture and design methodology.
If an attacker was successful in inducing an application to deviate from its normal operating
behavior, and attempted to elevate privilege, there would be no direct method for doing so. As
currently implemented, SourceT may allow an attacker under very specific conditions to read and
write to portions of memory controlled by code running at higher privilege levels, resulting in the
potential for altering the expected behavior of that code. However, such attacks would be limited
to utilizing existing code present in the system, and would not allow for the introduction of
additional code in to the system.
Should attackers somehow manage to overcome these first two protections and attempt to install
a rootkit by altering system binaries or otherwise subverting the boot process, the attempt would
fail. Ignoring the sheer difficulty of accessing methods allowing access to the disk or boot loader
code, any alterations to system images will be caught by the bootloader at signature verification
time. As this verification takes place via a TPM, it is not possible to avoid checking the signature,
and the use of the TPM is required to gain access to the key required to decrypt the system
binary. Recovery of this value may be possible on a per-system basis, but would require debug
access to perform. This level of access is not available on production systems.
As such, the traditional methods used by malware to gain system access and obtain the
privileges necessary to install themselves for continued infection do not appear viable.
Secure64 SourceT OS Security Evaluation Report 1
2. Methodology
Matasano staff spent September 25th, and 26th, 2007 onsite at the Secure64 offices, getting an
overview of the key aspects of the SourceT operating system. Each aspect with security
relevance was covered, including topics not directly relevant to the goals of this paper. This was
done in order to achieve an understanding of the processes that went into the design of the
SourceT OS. Knowledge of the larger picture architecture, and not just aspects that were to be
analyzed helped identify both flaws and mitigation strategies that might not otherwise have been
obvious.
Following onsite meetings, code injection, privilege escalation, and the trusted boot process were
all examined in isolation, to determine what weaknesses, if any, were present. Traditional
operating system weaknesses and attack vectors were examined, and the defense techniques
employed by SourceT to combat them were studied for completeness. Where current
implementation differed from the specified architecture, both were examined, and any flaws
present in current implementation that were not the result of architectural design were noted.
Where non-architectural flaws were present, these were also noted. Where programming flaws
have and have not been architected out of the SourceT operating system, this was also noted.
3. Overview of Secure64 Technology
The SourceT operating system was designed from the ground up to be secure. By taking
advantage of the security features contained in the Itanium processor family, Secure64
architected a system that eliminates many of the flaws that plague modern operating systems.
Where general purpose operating systems have to provide generic services to meet a wide
variety of needs, SourceT provides a limited set of services and interfaces, designed for the
specific needs of the applications being deployed on it.
General purpose operating systems are designed to work against a lowest common denominator.
If a system can’t guarantee the presence of a TPM, specific MMU design, or a trusted boot
process, it is often the case that these advanced features go unused. By targeting a specific
processor architecture, with a known set of capabilities, SourceT takes advantage of modern
advances in the security space, with none of the baggage that other operating systems have to
contend with.
Secure64 SourceT OS Security Evaluation Report 2
4. Areas of Analysis
Matasano evaluated the SourceT architecture against three areas of security vulnerability: code
injection, privilege level escalation and alteration or subversion of the trusted boot process. In
many cases, the architecture specifies multiple layers of protection in order to achieve its
security goals. These layers were examined both in isolation, and in conjunction with each other.
4.1 Code Injection
The ability for an attacker to inject or otherwise manipulate the runtime of an application on the
system is the cornerstone of traditional attacks against operating systems. By taking advantage
of application structure or programming flaws, attacks inject executable code into networked
systems. The ability to execute code on a compromised system opens enormous possibilities for
an attacker. They exploit compromised systems to introduce spam relays, spy on system users,
or conduct further attacks to elevate their privilege, gaining additional access and further reach
in the kinds of activities they can conduct.
4.1.1 Traditional Application Model Code Injection
4.1.1.1 Traditional Application Layout
The traditional application model breaks the
accessible address space into a number of
discrete elements, a number of which can be stack locals
manipulated by an attacker with the goal of
subverting a system.
The stack, used for keeping information related to
the functions currently being executed by an
application, can be attacked through a variety of
methods. Attackers may attempt to exploit certain heap dynamic (malloc)
types of vulnerabilities to alter variables contained
in the stack, or alter the call chain itself, causing
data globals
the execution of arbitrary code upon a return from
a function.
text instructions
The heap contains dynamically allocated memory,
as well as any libraries that may be loaded. Attackers may attempt to alter variables, overwrite
function pointers, or alter