AOP EXTENSION

FOR SECURITY TESTING OF PROGRAMS

Nadia BelblidiaCSL-CIISE,

Concordia UniversityMontreal, Quebec, Canadana bel@ciise.concordia.ca

Mourad DebbabiCSL-CIISE,

Concordia UniversityMontreal, Quebec, Canadadebbabi@ciise.concordia.ca

Aiman HannaComputer Science,

Concordia UniversityMontreal, Quebec, Canada

ahanna@cs.concordia.ca

Zhenrong YangCSL-CIISE,

Concordia UniversityMontreal, Quebec, Canadazhenr ya@cs.concordia.ca

Abstract

The purpose of this paper is to use the aspect-oriented programming(AOP) paradigm for security testing. AOP allows security expertsto develop and inject separate modules for conducting security test-ing on the applications independent of their business logic. After anappropriateness analysis of the mostly used approaches for AOP, weretain the pointcut-advice model. The pointcut-advice model is signif-icantly better than the other approaches for security testing. However,the current set of pointcuts is insufficient for the purpose of securitytesting and needs to be extended with new pointcuts.

Keywords— AOP, Security, Testing, Pointcut, Instru-mentation.

1 Introduction

Aspect Oriented Programming (AOP) [14] is a newparadigm that improves software modularity by allowingencapsulation of crosscutting concerns such as security, syn-chronization, etc. Thankful to a weaver mechanism, AOPlanguages allow merging codes in a natural and systematicway. AOP is ideal for conducting security testing on freeand open source software (FOSS) products. With free andopen source software, the code is available and ready tobe merged with appropriate security testing aspects. Thepurpose of this paper is to elaborate a framework for the se-curity testing of free and open source software using aspectoriented paradigm.

One of the security issues is poor memory management,which can lead immediately to security vulnerabilities. Forexample, by overflowing an internal buffer used by Linuxftpd’s SSL support, a user is able to open a shell on theremote host [2]. One way to test security problems re-lated to run-time memory errors is by instrumenting thesource code with monitoring routines in order to facilitatethe detection of these errors at runtime. The fact that thesource code of FOSS is available makes this instrumenta-tion feasible. In this paper, our purpose is to elaborate aframework for security testing, in particular, for memorymanagement of free and open source software using aspectoriented paradigm. More precisely, our objectives are:• Evaluate the appropriateness of existing aspect orientedtechniques for security testing.• Choose the most appropriate approach and extend it forexpressing and executing security testing practices.

The rest of the paper is organized as follows. Section 2presents the aspect oriented programming paradigm and its

most important approaches. Section 3 reports on securitytesting. Section 4 discusses the use of the AOP paradigmfor security testing and proposes an extension in supportof it. Section 5 summarizes the state of the art of worksdealing with our research topic. Finally, section 6 discussesthe future work and provides a conclusion.

2 AOP Approaches

AOP aims at avoiding scattering and tangling phenom-ena by separating the basic functionality of the softwarefrom other aspects like security, synchronization, etc. Ap-plying AOP leads to improved key software quality at-tributes as reusability and evolvability. AOP techniquesare based on the notion of weaving, which is the process ofcomposing core functionality modules with aspects into onesingle application. We present in the following the threemostly used AOP approaches: “Pointcut-advice model”,“multi-dimensional separation of concerns” and “adaptiveprogramming”.

The fundamental concepts of the pointcut-advice ap-proach are: join points, pointcuts and advices. A join pointis a point in the dynamic call graph of an application. Apointcut is a constructor that designates a set of join pointsand advices are pieces of code attached to pointcuts. Anadvice is executed when join points satisfying its pointcutare reached. Generally, three kinds of advices are available:before, after and around. The before advice and the afteradvice are executed before and after the intercepted joinpoint, respectively. The case for the around advice is moresubtle. Inside the around advice, we can choose to resumethe intercepted join point or skip it. AspectJ [15], an as-pect oriented extension of Java, is probably the most knownrepresentative of pointcut-advice languages and AOP lan-guages in general.

Multi-dimensional separation of concerns (MDSOC) al-lows simultaneous separation according to multiple, arbi-trary kinds (dimensions) of concerns [19]. MDSOC treatsall concerns as first-class and co-equal, including compo-nents and aspects, allowing them to be encapsulated andcomposed at will. One particular approach to MDSOC iscalled hyperspaces where the software is modelled as a setof units called hyperslices(concerns). HyperJ [19][24] is thesupport for hyperspaces in Java. In HyperJ , an hypersliceis a set of modules representing only one single concern and

1-4244-0038-4 2006IEEE CCECE/CCGEI, Ottawa, May 2006

647

could be composed with other hyperslices using matchingunits (e.g. method names).

Adaptive programming(AP), proposed by Demeter group[10], has used the ideas of AOP several years before thename aspect oriented programming was coined. The Lawof Demeter is a programming style rule for loose couplingbetween the structure and behavior concerns. Followingthis law can result in a large number of small methodsscattered throughout the program. Adaptive programmingwith traversal strategies and adaptive visitors avoids thisproblem while even better supporting the loose coupling ofconcerns.

3 Security Testing

Security testing is about validating an application’s secu-rity services and identifying potential security flaws. Secu-rity testing may seem similar to traditional software testingin terms that testers select input scenarios to torment appli-cations in an attempt to force the software to fail. However,the two disciplines target different problems in a softwareapplication. Traditional software testing detects programfaults that do not implement the system requirements cor-rectly. On the contrary, security testing looks for “unin-tended, undocumented, or unknown functionalities”[11] ina software application. For instance, incorrect use of mem-ory such as the infamous format string vulnerability [22]may produce an unintended functionality of a software ap-plication such that attackers can execute arbitrary codesby inputting a malicious string. There are many otherC/C++ errors such as memory corruption, memory leaks,memory allocation errors, variable initialization errors thatmay lead to security flaws as well. These security flawsmay be exploited, ranging from crashing the application toan attacker inserting and executing malignant code in theapplication process.

We intend to leverage source code instrumentation in or-der to detect memory management faults. We inject anal-ysis code to a program and perform dynamic analysis, e.g.probing application context, to expose illegal pointer oper-ations and memory manipulations in the application.

4 AOP for Security Testing

In this paper, we propose to use the AOP paradigm tosystemize and automate the injection of analysis code. Inthe following section, we will choose the most appropriateAOP approach for this purpose.

4.1 AOP Approapriatness Analysis

In this section, we compare the appropriateness of theAOP approaches cited in Section 2 for security testing,more precisely for detecting memory management errors.

The multiple separation of concerns has a serious limi-tation that it works at the method granularity. It can notoperate within a method body. A very basic and simple ex-ample of security testing that we can not handle with such

approach is to pull apart of security testing code withinmethod bodies.

The adaptive programming is concerned with a loose cou-pling between structure and behavior and focuses on certainkinds of concerns. They include behavioral concerns thatdeal with groups of collaborating objects that offer newbehavior, the traversal concern and the object structureconcern [17]. With this approach, we can not for exampleprobe arguments to method calls.

The pointcut-advice model is the most popular model. Itoffers a better granularity than multiple separation of con-cerns approach and considers a more general kinds of con-cerns than the adaptive programming. Furthermore, thepointcut-advice model takes more of a “pull” approach. Itallows to track subtle points in the control flow of the ap-plication as for example points where methods are invoked,etc. For these reasons, we choose this approach to facilitatethe code instrumentation for security testing. Because oursecurity testing targets C and C++ codes, we decide to usethe AspectC++ language [1], which is an aspect-orientedextension for C/C++. However, it needs extension as wewill show in the next section.

4.2 AspectC++ Extension

AspectC++ [21] is an open source project of AOP exten-sion for C++. It supports two types of pointcuts: “codepointcuts” and “name pointcuts”. While name pointcutsdescribe known program entities, code pointcuts describecollection of points in the control flow of an applicationat runtime. Code pointcuts are created using name point-cuts because they require at least one name to be defined.For example, “int C::%(...)” is a name poinctut thatmatches all member functions of the class C that returnint and “call(int C::%(...))” is the code pointcut de-scribing the set of calls of these functions.

None of the code pointcuts given by AspectC++ allowsto target local/global variable accesses in C/C++ code.However, for monitoring memory management operations,there is a need to dynamically keep track of local variableat runtime as demonstrated in the following example.

4.2.1 Motivating Example

The example presented in Table I performs simple pointerand string manipulation. Although the code compiles andexecutes, data are written to unallocated memory as seenin line 12. An attacker may take advantage of this flawto inject malicious code. In order to detect such vulnera-bilities, we need to insert monitoring routines before andafter variable accesses. Using AspectC++, this implies thedefinition and implementation of new pointcuts.

4.2.2 New Pointcuts

We introduce a new name pointcut in order to matchvariables in C and C++ codes. After this, we define threenew code pointcuts declare(pointcut), get(pointcut) andset(pointcut) on this new name pointcut, in order to keep

648

1:#include <iostream>2:#include <string>3:using namespace std;4:int main()5:{6: char *ptr a, *ptr b;7: ptr b = new char[200];8: strcpy(ptr b, "Benign string.");9: cout << ptr b << endl;10: delete [ ] ptr b;11: ptr a = ptr b;12: strcpy(ptr a, "Malicious code.");13: cout << ptr a << endl;14: return 0;15:}

TABLE I: Motivating Exampletable

1:aspect PointerTracker {2:3: static MemoryTrackingList mtl;4: static PointerTrackingList ptl;5:6: pointcut declared() = declare("%* %");7: pointcut write() = set("%* %");8: pointcut writeToContent() = set("* (%* %)");9: pointcut readToContent() = get("* (%* %)");10:11: advice declared() : after() {12: // register pointer variable in ptl13: }14: advice write() : after() {15: // update pointer’s rvalue in ptl16: // detach pointer from old memory space17: // attach it to new memory space or NULL18: }19: advice writeToContent() : before() {20: // report error if pointer attaches to NULL21: }22: advice readContent() : before() {23: // report error if pointer attaches to NULL24: }25:}

TABLE III: Usage Exampletable

track the declaration, read, and write of variables. The newpointcuts are defined in Table II.

4.2.3 Example Usage

To illustrate how the combination of these newly definedpointcuts can help us with detecting run-time memory man-agement problem, we will work with a simplified scenarioas seen in Table I. We define our aspect for monitoringpointer operation in Table III.

As seen in Table III, MemoryTrackingList and Pointer-TrackingList are our implementation for tracking allocatedmemory space and declared pointer variables respectively.Line 6 and 7 defines the pointcuts for pointer declarationand assignment respectively. Line 8 and 9 defines the point-cuts of writing to and reading the content in the memoryspace references by a pointer. From Line 11 to 24, we definethe actions to be taken at these pointcuts in four advices.For all pointer declarations, the weaved code registers thenew pointer variable to a PointerTrackingList. When the

right-hand value (rvalue) of a pointer variable is changed,this change is progagated to MemoryTrackingList, whichkeeps track of the application’s memory spaces and point-ers pointing to them. If the pointer doesn’t point to anymemory space, it is associated with a special NULL recordin the list. After this aspect is weaved to the core applica-tion in Table I, the weaved application reports error uponany attempt to read or write to a NULL pointer at runtime.

5 Related Work

The most relevant related work are those using AOP forsecurity. However, research results are rare. Among the at-tempts that have been made to use AOP for security we cancite the Darpa-Funded project of Cigital Labs [16][20][27]that applies AOP to enforce secure code practices. Themain outcomes of this project are a security dedicated as-pect extension of C called CSAW [16] and a weaving tool.CSAW addresses local, small-sized problems as buffer over-flows and data logging. De Win et al [4][6][8][25][26] ex-plored the use of AOP to integrate security aspects withinapplications. In [7], De Win et al applied AspectJ to en-force access control and in his thesis [5], De Win modular-ized the auditing and access control features of the FTPserver. Another contribution in the use of security aspectsis the security aspect library JSAL [12], which is imple-mented in AspectJ and provides security functions. Thereis another kind of contribution in the field of AOP for en-riching the expressiveness of pointcuts for some goals. In asecurity perspective, Masuhara and Kawauchi [18] present anew pointcut called dataflow pointcut. They show in theirpapers, that some security concerns, such as secrecy andintegrity, are sensitive to flow of information in a programexecution.

None of those previous works dealt with the issue of mem-ory management flaws that we address here.

6 Future Work and Conclusion

In this paper, we study the possibility of using AOP forsecurity testing. It appears that the pointcut advice modelis the most appropriate one. However, we have shown thatthis model still needs extension. We propose new pointcutsto keep track of variable accesses. We plan in near futureto finish the implementation of the extension and use theextended AspectC++ to conduct security testing on FOSSapplications.

References

[1] AspectC++ documentation. http://www.aspectc.org/Documentation.5.0.html.

[2] Linux ftpd SSL Buffer Overflow (Exploit).http://www.securiteam.com/exploits/6F0021PEKC.html.

[3] K. Bollert. On weaving aspects. In Interna-tional Workshop on Aspect-Oriented Programming atECOOP99.

649

<VariablePointcut> ::= <NameVariablePointcut> | <CodeVariablePointcut><CodeVariablePointcut> ::= get(<NameVariablePointcut>) | set(<NameVariablePointcut>)

declare(<NameVariablePointcut>)<NameVariablePointcut> ::= <Type> [<NameSpace>][<Class>|<Struct>]::[<Function>]::<VariableName>

TABLE II: New AspectC++ Pointcutstable

[4] B. DeWin. AOSD is an Enabler for Good Enough Se-curity. http://citeseer.ist.psu.edu/728786.html, 2003.

[5] B. DeWin. Engineering Application Level Secu-rity through Aspect Oriented Software Development.http://www.cs.kuleuven.ac.be/cwis/research/distrinet/resources/publications/41140.pdf, 2004.

[6] B. DeWin, F. Piessens, W. Joosen, and T. Verhan-neman. On the Importance of the Separation-of-Concerns Principle in Secure Software Engineering.Workshop on the Application of Engineering Princi-ples to System Security Design, Boston, MA, USA,November 6–8, 2002, Applied Computer Security As-sociates (ACSA), 2002.

[7] B. DeWin, B. Vanhaute, and B. De Decker. Se-curity Through Aspect-Oriented Programming. InB. De Decker, F. Piessens, J. Smits, and Van Her-reweghen, editors, Advances in Network and Dis-tributed Systems Security, pages 125–138, 2001.

[8] B. DeWin, B. Vanhaute, and B. De Decker. HowAspect-Oriented Programming Can Help to Build Se-cure Software. Informatica, 26(2):141–149, 2002.

[9] D. Orleans for K. Lieberherr. AdaptiveProgramming with Traversals and Visitors.www.ccs.neu.edu/research/demeter/posters/ in-troDemeterJava/poster.html.

[10] Demeter Group. Home page.http://www.ccs.neu.edu/research/demeter/.

[11] Greg Hoglund. Exploiting software : how to break code.Addison-Wesley, Boston, 2004. Includes bibliographi-cal references (p. 449-451) and index.

[12] M. Huang, C. Wang, and L. Zhang. Towarda Reusable and Generic Security Aspect Library.In AOSD:AOSDSEC 04: AOSD Technology forApplication-level Security, March 2004.

[13] Parasoft Insure++. Home page.http://www.parasoft.com/jsp/products/home.jsp?product=Insure.

[14] G. Kiczales, J. Irwin, J. Lamping, J. M. Loingtier,C.V. Lopes, C. Maeda, and A. Menhdhekar. Aspect-Oriented Programming. In Mehmet Aksit and SatoshiMatsuoka, editors, ECOOP ’97 — Object-OrientedProgramming 11th European Conference, Jyvaskyla,Finland, volume 1241, pages 220–242. Springer-Verlag,New York, NY, 1997.

[15] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, MikKersten, Jeffrey Palm, and William Griswold. AnOverview of AspectJ. Budapest, 2001. Springer Ver-lag.

[16] Cigital Labs. An Aspect-Oriented Security AssuranceSolution. Technical Report AFRL-IF-RS-TR-2003-254, Cigital Labs, Dulles, Virginia, USA, 2003.

[17] K. Lieberherr, D. Orleans, and J. Ovlinger. Aspect-Oriented Programming with Adaptive Methods. Com-munications of the ACM, 44(10):39–41, 2001.

[18] H. Masuhara and K. Kawauchi. Dataflow Pointcutin Aspect-Oriented Programming. In APLAS, pages105–121, 2003.

[19] H. Ossher and P. Tarr. Multi-Dimensional Separationof Concerns and the Hyperspace Approach. In Pro-ceedings of the Symposium on Software Architecturesand Component Technology: The State of the Art inSoftware Development. Kluwer, 2000.

[20] V. Shah and F. Hill. Using Aspect-Oriented Pro-gramming for Addressing Security Concerns. In IS-SRE2002.

[21] Olaf Spinczyk, Andreas Gal, and Wolfgang Schroder-Preikschat. AspectC++: An Aspect-Oriented Ex-tension to C++. In Proceedings of the 40th Inter-national Conference on Technology of Object-OrientedLanguages and Systems, Sydney, Australia, February2002.

[22] Peter Szor. The art of computer virus research anddefense. Addison-Wesley, Upper Saddle River, NJ,2005. Includes bibliographical references and index.;ALT TITLE: Computer virus research and defense.

[23] P. Tarr, H. Ossher, and S. M. Sutton. T2: Hy-per/j: Multi-dimensional separation of concerns forjava. http://trese.cs.utwente.nl/aosd2002/index.php?content=hyperj, 2002.

[24] Peri Tarr and Harold Ossher. Hyper/J User and In-stallation Manual. IBM T. J. Watson Research Center,Yorktown Heights, NY, USA, 2000.

[25] B. Vanhaute and B. DeWin. AOP, Security and Gener-icity. 1st Belgian AOSD Workshop, Vrije UniversiteitBrussel, Brussels, Belgium, November 8, 2001, 2001.

[26] B. Vanhaute, B. DeWin, and Bart B. De Decker.Building Frameworks in AspectJ. Workshop on Ad-vanced Separation of Concerns, ECOOP2001.

[27] J. Viega, J. T. Bloch, and C. Pravir. Applying Aspect-Oriented Programming to Security. Cutter IT Journal,14(2):31–39, 2001.

650