Separation of Concerns for Security John Viega Reliable Software Technologies [email protected] David Evans University of Virginia Department of Computer Science [email protected] 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.