Published in Proceedings of the 2006 IEEE Symposium on Security and Privacy, Oakland, California, May 2006Retrofitting Legacy Code for Authorization Policy EnforcementVinod GanapathyUniversity of WisconsinMadison, [email protected] JaegerPennsylvania State UniversityUniversity Park, [email protected] JhaUniversity of WisconsinMadison, [email protected] have argued that the best way to constructa secure system is to proactively integrate security into thedesign of the system. However, this tenet is rarely fol-lowed because of economic and practical conside rations.Instead, security mechanisms are added as the need arises,by retrofitting legacy code. Existing techniques to do so aremanual and ad hoc, and often result in security holes.We present program analysis techniqu es to assist the pro-cess of retrofitting legacy code fo r authorization policy en-forcement. These techniques can be used to retrofit legacyservers, such as X window, web, proxy, and cache servers.Because such servers manage multiple clients simultane-ously, and offer shared resources to clients, they must havethe ability to enforce authorization policies. A developercan use our techniq ues to identify security-sensitive loca -tions in legacy servers, and place referenc e monitor calls tomediate these locations. We demonstrate our techniqu es byretrofitting the X11 server to enforce authorization policieson its X clien ts.1. IntroductionResearchers have traditionally argued that the best wayto construct secu re systems is to proactively de sig n themfor security. While this is unquestionably the best way toconstruct secur e systems, economic and practical conside r-ations force developers to choose functionality and perfor-mance over security. As a result, commodity systems oftenship with inade quate security mechanisms built in, and se-curity is retroactively added, as the need arises. For exam-ple, this was done in the case of the Linux Security Mod-ules (LSM) framework [39], where the Linux kernel wasretrofitted with mechanisms to enforce ma ndatory accesscontrol policies. Similarly, several popular ser ver applica-tions lack mechanisms to enforce authorization policies ontheir clien ts, and there is growing in te rest to retrofit theseservers to add such mechanisms [25, 33].Unfortu nately, existing techniqu e s to retrofit legacy codewith secur ity mechanisms, such as the ability to enforce au-thorization policies, are manual and ad ho c . Not surpris-ingly, security holes have been found in manua lly-retrofittedcode [22, 43]. Thus, it is desirable to have automated tech-niques to retrofit legacy code.In this paper, we address the problem of r e troactivelyadding security mechanisms to legacy software systems.We focus on techniques to retrofit a c la ss of legacy serversfor authoriz ation policy enforcement. Examples of serversto which our techniques are applicable include windowservers, such as the X server [4 1], middleware, web, proxy,cache, and database servers. Because these servers of-fer shared resources to their clients, and manage multipleclients simultaneously, they must have the ability to en-force authorization policies on their clients. For example,an X server must be able to prevent an unauthorized c lientfrom reading the contents of o ther client windows.The main c hallenge in retrofitting a legacy server is inidentifyin g locations where security-sensitive operations,i.e., primitive operations on critical server reso urces, areperformed. The idea is that having identified these lo-cations, authorization policy lookups can be added to theserver code so as to completely mediate these locations [32].We develop techniques to assist (1) id entification of loca-tions in server co de where security-sensitive operations areperformed, and (2) instrumentation of these locations, suchthat the operation is per formed only if allowed by a n autho-rization policy. We have prototyped these techniques in twotools, A and A, discussed below.1. A ( assistant for fing erprint identification) is a hybridstatic/dynam ic analysis tool, wh ich helps a developeridentify location s in ser ver code where security-sensitiveoperations are performed. The key idea behind A isthat each security -sensitive operation is typ ic a lly charac-terized by certain canonical code-patterns being executedby the server. We call these code-patterns the finger-print of the security-sensitive operation—just as a humanfingerpr int identifies an individual, these code-patternsidentify the security-sensitive opera tion. The challengeDraft: February 2 7, 2006is to find fingerprints for security-sen sitive operation s.We identify fingerprints using a novel observation:security-sensitive operations are typica lly associatedwith tangible side-effects. Thus, by tracing th e server asit perf orms a side-effect, and analyzing code- patterns inthe trace, we can extrac t fingerprints of security-sen sitiveoperations associated with the side- e ffect.For examp le , consider the X ser ver: the security-sensitive opera tion Window Create creates a window(window creation is a tangible side-effect) for anX client. By analyzing the trace generated by theX server as it opens a client window on the screen, Aidentifies that a call to the function CreateWindow, wh ic his imp le mented in the X server, is the fingerprint of Win-dowCreate. Indeed , this fu nction allocates memo ry for,and initializes, a variable of ty pe Window in response toa client requ e st. Thus, each call to CreateWindow in theX server r esults in WindowCreate.A is a two-ph a se tool. In the first phase, it traces theserver and identifies fingerprints for security-sensitiveoperations, as discussed above. In the second phase, itstatically identifies locations in the code of the serverwhere th ese fingerprints occur; each of these loc ationsis deemed to perform the security-sensitive operation.2. A (assistant for reference monitoring) is a tool to in-strument locations discovered by A. In particular, Aadds calls to a reference monitor, which encapsulates theauthorization policy to be en forced. These calls, whichperform authorization policy lookups, complete ly me-diate security-sensitive locations, thus ensuring that asecurity-sensitive operation is performed only if allowedby the authorization policy.While A a nd A a re not yet fully automatic, wefeel that they ar e an
View Full Document
Unlocking...