Separation of Concerns for Security
John Viega
Reliable Software Technologies
David Evans
University of Virginia
Department of Computer Science
Abstract software written by develop ers who know a lot ab out
this problem, including which functions in common
Writing secure code is something most developers
libraries are p otentially dangerous.
know little about. As a result, software vulnerabili-
ties are quite common. We postulate that, by isolating
We think it should b e easier to design securityinto
security as a separate concern, this problem can be al-
an application, instead of relying on the \p enetrate
leviated.
and patch" approach to security, where problems are
addressed in an ad ho c manner, generally as aws
1 Intro duction
are revealed in the eld. Unfortunately, the \p ene-
We prop ose to solve some of the problems with de-
trate and patch" approach to security is widespread,
veloping secure software by separating out securityas
as opp osed to the alternative of designing software
1
a concern. Doing so will allow security p olicies to b e
with security in mind. There are two primary rea-
separate from the co de, allowing develop ers to write
sons why this problem is so prevalent. The rst is
the main application, and a security exp ert to sp ecify
that no coherent design time metho dologies or to ols
security prop erties. Also, we b elieve that a well de-
are widely available. In fact, there are no comprehen-
signed p olicy language can abstract awaymuchofthe
sive resources available to help write secure programs;
exp ert knowlege currently required for writing secure,
develop ers do not know what the problems are. As a
allowing develop ers to reasonably secure their co de,
result, develop ers continue to write insecure co de and
even if a security exp ert is not available to assist.
to x security problems when someone happ ens to no-
Our approach is general enough to be applied to
tice them. The second problem is that designing and
any language, and in the future weanticipate exp eri-
implementing secure systems currently requires a lot
menting with versions for several di erent languages.
of exp ert knowledge. Even with go o d metho dologies,
At present, we fo cus on C b ecause its security vul-
go o d to ols are still critical to alleviating this problem,
nerabilities are well known and it is a relatively small
as the average develop er is likely to b e either unwill-
and simple language. Further, despite its aws, even
ing or unable to use the metho dology e ectively if no
to day C is still widely used to write security-critical
to ols are available.
applications.
Another large part of the problem is the state of
programming languages from a security p oint of view.
2 Motivation
A few languages have given signi cant thought to se-
Exp erience has shown that develop ers aren't very
curity primitives that should b e presentto help pro-
go o d at writing secure software. Part of the problem
grammers write b etter co de. However, two of the most
is a lack of education; few classes cover this material,
widely used programming languages present signi -
and no b o oks cover it well. However, education isn't
cant security risks sp eci cally, C and C++ . This
the entire issue, as evidenced by the fact that bu er
is b ecause many of their standard features can easily
over ow exploits in C co de are quite common, even in
b e used in suchaway to inadvertently leave a security
1
aw in a program. Even languages with signi cant se-
Our work is b eing funded under the DARPA IASET
curity architectures such as Java leave something to program.
is a bigger challenge for C than for most other lan- be desired; we have found in practice while lo oking
guages, since the language and standard libraries at many commercial pro ducts that a large p ercent-
contain so many unsafe op erations. Bu er over- age of applications have signi cant security problems
ows are one well known problem. Others include that are present in the design phase, and will p ersist
le access calls that are susceptible to security- through to implementation despite the language used.
critical race conditions, as well as most uses of Some of the more common problems include misuse
the popen and system library calls. of security proto cols and an unrealistic view of what
a system should consider trusted. Languages haveyet
5. Currently, if a security consideration is omitted
to make signi cant inroads in this area.
in just one place, it can easily lead to a aw. It
3 Goals
should b e easy to express p olicies ab out the pro-
gram that apply generically to a consideration,
In talking with many develop ers ab out security,we
and then have the p olicy b e applied through the
have noticed that even security-aware p eople nd it
program automatically. For example, it should b e
much easier to write their program, and then later go
p ossible to say that no secret information is ever
back and try to \b olt-on" security as an afterthought.
sentover the network unencrypted p erhaps the
In our exp erience, this approach do esn't work; secu-
actual implementation maycho ose to encrypt all
rity currently generally needs to be designed into an
data to satisfy this prop erty .
application from the b eginning. There is a fundamen-
tal con ict here b etween what works well in practice,
6. Legacy source co de with known or p otential secu-
and the way develop ers work, even when they are well
rity problems should b e able to b ene t from such
educated on security matters.
a to ol; the amount of new co de necessary should
All to ols we have encountered to help prevent se-
b e minimized.
curity vulnerabilities in general-purp ose programming
languages are after the fact to ols, such as vulnerabil-
7. When it makes sense to do so, security p olicies
ity analysis to ols that lo ok for common programming
should b e reusable across di erent applications.
and con guration errors. They do not address howa
develop er should design and implement software in a
4 An Asp ect-Oriented security ap-
security conscious manner. We b elieve that a more
proach
proactive approach is appropriate. A good to ol for
Sep eration of concerns can help meet all of the
solving these problems would meet the following goals:
ab ove goals. A sp eci cation language can b e de ned
that will be woven with a C application, separating
1. The amount of exp ert knowlege necessary to se-
security co de from the rest of the program. This lan-
cure source co de should b e minimized. It should
guage could have reasonable defaults that can b e over-
not be easy for a develop er to accidentally in-
ridden, and could have some degree of p olymorphism
tro duce security problems into a program just
e.g., the programmer should b e able to de ne classes
b ecause the language and the concepts of se-
of variables, place variables in those classes on a case
cure programming haven't b een mastered. Com-
by case basis and sp ecify what kind of bu er over ow
mon language pitfalls should b e averted, and the
protection each class should b e a orded . Such p oly-
programmer should be protected from common
morphism would also help a ord reuse of sp eci cations
paradigms of failure that are not language sp e-
across applications; the security asp ect language could
ci c.
allowtwotyp es of sp eci cations: those that map vari-
ables to symb olic names program sp eci c , and those
2. The security-related elements in a program
that de ne security p olicies based on symb olic names.
should b e abstracted out of the program prop er,
We are in the pro cess of designing and building
for the sake of clarity, maintainability and reuse.
a sp eci cation language intended to meet the ab ove
3. Security p olicies should b e de ned using a general
goals. Sp eci cations written in this language will be
enough language that it is p ossible to create new
woven together with C programs to pro duce secure
p olicies to deal with application-sp eci c issues or
programs. Our approach will b e to take the security
previously unknown security vulnerabilities.
sp eci cation and the C source, and \weave" the two
into a single C program.
4. An emphasis should b e placed on \securityby de-
some of the problems we are addressing include:
fault", so that the level of e ort for developing se-
1. Bu er over ows. cure C and C++ applications is minimized. This
need to authenticate itself with a remote server. The 2. Environmental attacks Tro jan environmentvari-
programmer would have to sp ecify the typ e of au- ables .
thentication exp ected by the remote server, and a
3. File-based race conditions.
means by which to read the authentication data e.g.,
a passphrase . The second option is that the program
4. Randomness attacks guessing security-critical
is exp ecting remote authentication. In this case, the
\random" numb ers .
programmer sp eci es the typ e of authentication, and
5. System call failures.
also sp eci es a database suchasakeystore against
which the remote connection should b e authenticated.
As an example of our approach, we will discuss sys-
The actual implementation will just add approppriate
tem call failures. Some attacks exploit system calls
co de surrounding those calls that establish a network
failing in ways not anticipated by the programmer.
connection. The implementation of encrypted network
When those calls fail in an unexp ected way, default
connections will be quite similar, except that reads
handlers should b e called that p erform reasonable ac-
and writes to a network connection will also need to
tions. We will assume that the return values for indi-
b e mo di ed to actually encrypt and decrypt.
vidual calls are not checked in the program prop er, un-
less a static analysis can determine otherwise. In the
5 Related work
sp eci cation language, programmers should b e able to
The space of available software security assurance
sp ecify a p olicy for all such calls, for single calls, and
is currently inhabited primarily by small, op en source
for classes of calls. For example, one should be able
to ols that only address a fraction of the actual prob-
to say, \for every memory allo cation call that fails,
lem. There are multiple patches for the gcc compiler
ab ort". It should b e p ossible to override this b ehav-
that implement array b ounds checking. There are sev-
ior at individual sites, as well. The actual weaving is
eral to ols that provide some sort of security against
a simple transformation. For example, consider the
bu er over ow attacks, including StackGuard[2] and
following co de that allo cates 256 characters:
FIST[5]. However, most of these to ols are solely inter-
ested in bu er over ows.
char *p;
Another typ e of to ol in the security assurance do-
p = char * malloc 256*sizeof char ;
main is the \secure data- ow" to ol. Examples of this
A typical security sp eci cation would direct the
to ol are the \taint" version of Perl, and the JFlow
weaver to convert this co de to the following:
programming language a Java extension [7]. In such
to ols data are lab eled either \untrusted" or \trusted".
char *p;
\Untrusted" data cannot be passed to trusted items
p = char * malloc 256*sizeof char ;
without the programmer explicitly allowing it. Simi-
if p == NULL {
larly, \trusted" data cannot b e passed to \untrusted"
log "Out of memory." ;
items for fear of leaking secret information, unless ex-
abort ;
plicitly declassi ed by the programmer.
}
All of the capabilities of the ab ove to ols could be
describ ed in a security sp eci cation and woven into a
We estimate that these kinds of problems cover at
program using our asp ect-oriented security approach.
least 90 of all security incidents in C programs over
We hop e to incorp orate existing to ols as o the shelf
the past 3 years Bu er over ows alone account for
technology whenever p ossible. For example, the afore-
50 of the problem [10] .
mentioned to ols for preventing bu er over ows can
Wewould also like to build features that ease the
p otentially b e leveraged in the implementation of our
burden of using other security primitives, such as:
approach. We hop e to provide a uniform and general
1. Automatic logging.
purp ose interface to these to ols, while adding a large
amount of exibility and extensibility; only a few of
2. Sp ecifying critical sections.
the many problems we seek to handle are addressed
by current to ols.
3. Authentication and Encryption.
Commercial to ols in the security assurance space
are almost universally general-purp ose, and not For example, network connections can be authen-
security-sp eci c. For example, there are many to ols ticated and encrypted automatically via co de instru-
such as Rational's Purify that can help nd and x mentation. In the case of authentication, we antic-
bu er over ow problems, even though the to ol is not ipate two options. In one option, the program will
[3] D. Evans, J. Guttag, J. Horning, and Y. Meng sp eci cally a security to ol[6].
Tan. LCLint: A to ol for using sp eci cations to Another class of to ols are after-the-fact to ols that
check co de. In Proceedings of the SIGSOFT Sym- supp ort the \p enetrate and patch" mo del. These to ols
posium on the Foundations of Software Engineer- generally are concerned with taking preexisting source
ing, Decemb er 1994. co de, and identifying p otentially dangerous constructs
based on a database and some static analysis. Cur-
[4] D. Evans and A. Twyman. Flexible p olicy-
rently, the only publicly available to ol for source co de
directed co de safety. In Proceedings of the 1999
analysis is ITS4, which scans C and C++ co de for
IEEE Symposium on Security and Privacy, May
over 100 p otential problems[9]. Wagner has a bu er-
1999.
over ow scanner that p erforms a more sophisticated
analysis; however it is not publically available, and
[5] A. Ghosh, T. O'Connor, and G. McGraw. An
is limited in scop e[10]. Similar to ols exist that are
automated approach for identifying p otential vul-
general purp ose, and may catch some security bugs,
nerabilities in software. In Proceedings of the 1998
including lint to ols such as LCLint[3].
IEEE Symposium on Security and Privacy, May
Previous work has also b een done in p olicy lan-
1998.
guages for security. Most such languages sp ecify le
[6] R. Hastings and B. Joyce. Purify: Fast detection access control, allowing the programmer to give ex-
of memory leaks and access errors. In Proceedings plicit p olicies stating what a program can and can-
of the Winter USENIX Conference, 1992. not do to les. Examples of such systems include
Naccio[4], Ariel[8] and PolicyMaker[1]. Weanticipate
[7] A. Myers. Practical mostly-static information
incorp orating this sort of to ol as a small part of our
ow control. In Proceedings of ACM SIGPLAN-
total functionality.
SIGACT Symposium on Principles of Program-
6 Conclusion
ming Languages, San Antonio, TX, January 1999.
We have identi ed some of the ma jor problems
[8] R. Pandey and B. Hashii. Providing ne-grained
plaguing software security, and discussed how sepa-
access control for mobile programs through bi-
rating security from a program prop er might help al-
nary editing. Technical Rep ort CSE-98-8, Uni-
leviate these problems. We are currently working on
versity of California, Davis, 1998.
designing a language for de ning security concerns and
implementing a weaver that generates and integrates
[9] J. Viega, J.T. Blo ch, T. Kohno, and G. McGraw.
co de into C programs. There are many currently op en
Its4: A static vulnerability scanner for C and
questions we plan to address in our work, including:
C++ co de. In Submitted to USENIX Security,
1. What prop erties are required of a language for
2000.
describing security p olicies that can b e woven into
[10] D. Wagner, J. Foster, E. Brewer, and A. Aiken. A
a program?
rst step towards automated detection of bu er
2. What class of security p olicies can b e enforce us-
overrun vulnerabilities. In Proceedings of the Year
ing a separation of concerns approach?
2000 Network and Distributed System Security
Symposium NDSS , pages 3{17, San Diego, CA,
3. What opp ortunities will there b e to analyze secu-
2000.
rity sp eci cations to make claims ab out programs
that have b een woven into a single program?
References
[1] M. Blaze, J. Feigenbaum, and J. Lacy. Decen-
tralized trust management. In Proceedings of the
17th IEEE Symposium on Security and Privacy,
May 1996.
[2] C. Cowan et. al. Stackguard: Automatic adap-
tive detection and prevention of bu er-over ow
attacks. In Proceedings of the Seventh USENIX
Security Symposium, pages 63{77, San Antonio, TX, 1998.