|
|
Automatic Identification
and Protection of
Security-Critical Data
|
Research Summary
Recent advances make attacks that corrupt program control-flow, often by
overwriting return addresses, difficult to execute. We believe attackers
will next exploit the easiest remaining flaws — by corrupting
critical non-control data.
We protect security-critical data by storing it in a secure store,
separate from other program data. The secure store is protected using
page-level access control with operating system mechanisms. The secure
store is only writeable for short periods when critical data is updated.
Security-critical data such as pathnames, user ids, and configuration
data is typically initialized once, and read many times during a program
execution, but rarely updated. The secure store is read-only, except
for short periods when the program is known to update critical data. If
an attacker attempts to modify critical data at any other time,
hardware-level page protection mechanisms protect the critical data.
Data that is not security-sensitive is stored in the standard store,
which need not be protected. This means non-critical data can be
updated without opening opportunities for corrupting critical data.
Identifying Critical Data and Updates
We focus on real programs by developing inference algorithms that take
as input un-annotated or partially-annotated programs and locate
critical data that must be protected. These techniques combine static
and dynamic inference techniques to minimize falsely identifying
non-critical data as critical.
Transforming Programs
To execute legacy programs in our framework, we need to transform the
program to place critical data in the secure store and to temporarily
make the secure store writable around legitimate updates. Our goal is to
minimize the window of vulnerability in terms of both time and space
when parts of the secure store are writable.
Responding to Attacks
When a process attempts to write to the secure store outside an update
region, page-level protection mechanisms prevent and detect the write
attempt. The process can recover since no critical data has been
compromised. The state of the process is available for analysis, and can
be used to develop an attack signature.
People
Principal Investigators:
David Evans
Westley Weimer
Reading Group
UVa's Security Reading
Group meets most weeks Wednesday afternoon at 3:30. See
http://www.cs.virginia.edu/srg/
for an updated schedule and information about joining.
Related Projects by the PIs
Dependability Research
Group
Disk-Level Malware
Detection and Response
Genesis: Security through Diversity
IPA — Inexpensive
Program Analysis
N-Variant Systems for
Secretless Security
