The Journal of Systems and Software 86 (2013) 2654– 2674
Contents lists available at ScienceDirect
The Journal of Systems and Software
j our na l ho me p age: www.elsev ier .com/ locate / j ss
ommon weaving approach in mainstream languages for software securityardening�
ima Alhadidia,∗, Azzam Mouradb, Hakim Idrissi Kaitounia, Mourad Debbabia
Computer Security Laboratory (CSL), Concordia Institute for Information Systems Engineering, Concordia University, Montreal, Quebec, CanadaDepartment of Computer Science and Mathematics, Lebanese American University, Beirut, Lebanon
r t i c l e i n f o
rticle history:eceived 27 April 2012eceived in revised form 2 May 2013ccepted 4 May 2013vailable online 2 June 2013
In this paper, we propose a novel aspect-oriented approach based on GIMPLE, a language-independentand a tree-based representation generated by the GNU Compiler Collection (GCC), for the systemizationof application security hardening. The security solutions are woven into GIMPLE representations in asystematic way, eliminating the need for manual hardening that might generate a considerable numberof errors. To achieve this goal, we present a formal specification for GIMPLE weaving and the implemen-tation strategies of the proposed weaving semantics. Syntax for a common aspect-oriented language thatis abstract and multi-language support together with syntax for a core set for GIMPLE constructs are pre-sented to express the weaving semantics. GIMPLE weaving accompanied by a common aspect-orientedlanguage (1) allows security experts providing security solutions using this common language, (2) letsdevelopers focus on the main functionality of programs by relieving them from the burden of securityissues, (3) unifies the matching and the weaving processes for mainstream languages, and (4) facilitatesintroducing new security features in AOP languages. We handle the correctness and the completeness
of GIMPLE weaving in two different ways. In the first approach, we prove them according to the rulesand algorithms provided in this paper. In the second approach, we accommodate Kniesel’s discipline thatensures that security solutions specified by our approach are applied at all and only the required pointsin source code, taking into consideration weaving interactions and interferences. Finally, we explore theviability and the relevance of our propositions by applying the defined approach for systematic securityhardening to develop case studies.
. Introduction
Security takes an increasingly predominant role in today’s com-uting world. The computer industry faces challenges in publiconfidence as vulnerabilities are discovered, and customers arexpecting security to be delivered out of the box, even on programshat were not designed with security in mind. The challenge is evenreater when such systems must be adapted to networked/webnvironments, when they were not originally designed to fit into
uch high-risk environments. In some cases, and whenever theource code is available, as is the case for Free and Open-Sourceoftware (FOSS), a wide range of security improvements could be
� This research is the result of a fruitful collaboration between Computer Secu-ity Laboratory (CSL) of Concordia University, Defence Research and Developmentanada (DRDC) Valcartier and Bell Canada under the NSERC/DND Research Partner-hip Program.∗ Corresponding author. Tel.: +1 514 848 2424x7243.
applied once a focus on security is decided (Erlingsson, 2004; Baueret al., 2005; Schumacher, 2003; Bishop, 2002). As a result, inte-grating security into software is a very challenging and interestingdomain of research.
Securing software is a difficult and a critical procedure. If donemanually, it may require a lot of time and create other vulnerabil-ities. In fact, one should find all the code involved and change itconsistently everywhere. Moreover, it is always difficult to findsoftware engineers or developers who are specialized in both secu-rity solutions and software functionality. This is an open problemraised by managers of different companies (Bell Canada, 2009). Oneway to overcome these difficulties is by separating security con-cerns from the rest of the application so they can be addressedindependently and applied globally. A methodology that wouldencompass separation of security concerns and consistent imple-mentation of security solutions would pave the road towards secureapplications, enable a security expert to enforce security properties,
and facilitate the correctness verification of security solutions.
In this respect, aspect-oriented programming (AOP) (Kiczaleset al., 1997) is an appealing approach that allows the separa-tion of crosscutting concerns. There are many AOP languages
eveloped that are language-dependent. We distinguish from themspectJ (Kiczales et al., 2001), built on top of the Java program-ing language, AspectC (Coady et al., 2001), built on top of the
programming language, AspectC++(Spinczyk et al., 2002) builtn top of the C++programming language, AspectC# (Kim, 2002),uilt on top of the C# programming language, and the AOP ver-ion, addressed for the Smalltalk programming language (Böllert,999). The approach adopted by most of these languages is theointcut-advice model (Masuhara et al., 2003). The fundamentaloncepts of this model are: join points, pointcuts, and advice pieces.
join point is a location in the execution of a program. A point-ut is a concept that classifies join points in the same way a typelassifies values. Advice is a code fragment that is executed whenoin points satisfying a particular pointcut are reached. This exe-ution can be done before, after, or around a specific join point.inally, advice is composed and merged with the core functional-ty modules into one single program. The process of composition isalled weaving, and the tools that perform such a process are calledeavers.
More recently, several proposals have been advanced for codenjection via AOP into source code for improving its securityBodkin, 2013; DeWin, 2004; Huang et al., 2013; Shah, 2003). How-ver, AOP has not been initially engineered with security in mind.onsequently, new security-related constructs and primitives haveeen proposed as AOP extensions, e.g., pointcuts for dataflowMasuhara and Kawauchi, 2003), integer overflow (Alhadidi et al.,008), loop (Harbulot and Gurd, 2006), local variable setting andetting (Alhadidi et al., 2006), and synchronized block (Alhadidit al., 2006). Extending each AOP language with new security fea-ures addresses time waste and effort repetition. In this paper, weresent new contributions towards developing a practical and aormal framework for systematic security hardening of software.he defined approach allows application of the hardening on theIMPLE representation of software (GNU, 2012). GIMPLE is an inter-ediate representation of programs. It is a language-independent
nd a tree-based representation generated by the GNU Compilerollection (GCC) (GCC—the GNU Compiler Collection, 2009) duringompilation. GCC is a compiler system supporting various program-ing languages, e.g., C, C++, Objective-C, Fortran, Java, and Ada. In
ransforming the source code to GIMPLE, complex expressions areplit into three-address forms using temporary variables.
Exploiting the intermediate representation of GIMPLE enabless to define common weaving semantics that supports the main-tream languages and facilitates introducing new security-relatedOP extensions. The importance of this stems from the fact thatspect-oriented languages are language-dependent. Accordingly,IMPLE weaving allows defining common weaving semantics and
mplementation for all programming languages supported by theCC compiler instead of defining them for each AOP language. Forxample, instead of having a specific compiler for every aspect-riented programming language that tries to match join points inode and then does the weaving, the matching and the weaving areone on GIMPLE trees without focusing on a specific programming
anguage.The defined approach in this paper is based on the secu-
ity hardening language (SHL) that is defined in Mourad et al.2007a,b). This language is expressive, human-readable, and inter-
ediate between English and programming languages. Moreover,t is aspect-oriented and supports multiple languages. The authorsMourad et al., 2007a,b) have performed systematic security hard-ning of software by applying well-defined solutions that areefined by security experts using SHL. Afterward, developers refine
hese security solutions manually into one of the existing AOP lan-uages. To bypass this manual refinement and to facilitate futurextensions for new security features in AOP languages, the pro-osed approach in this paper allows applying the hardening on the
nd Software 86 (2013) 2654– 2674 2655
GIMPLE representation of software. The main contributions of thispaper can be summarized as follows:
– Semantics and algorithms for matching and weaving in GIMPLEare formalized. For this reason, syntax for a common aspect-oriented language that is abstract and multi-language supportand syntax for GIMPLE constructs are defined. Providing a for-mal framework for GIMPLE weaving helps to better understandthe underpinnings of this approach and capture its steps in a rig-orous way. This can serve both as a reference for programmerswishing to understand subtle points about the GIMPLE weavingand as a touchstone for implementers by providing a standardagainst which the correctness of an implementation may bejudged. Additionally, it establishes the theoretical properties ofthe approach and provides a foundation for mathematical proofs.
– Correctness and completeness of GIMPLE weaving are exploredfrom two different views. In the first approach, we address themaccording to the provided formal matching and weaving rulesand the defined algorithms in this paper. On the other hand,we accommodate in the second approach Kniesel’s discipline toprove that GIMPLE weaving is correct and complete only in somespecific cases because of behavior interactions and interferences.This ensures that security code is injected in all specified loca-tions and only at these specified locations. Accordingly, securityproperties that are represented by this code are satisfied afterweaving.
– Implementation strategies of the proposed semantics areintroduced. To explore the viability and the relevance of thedefined approach, case studies are developed. Case studies ofsmall programs are developed to solve the problems of unsafecreation of temporary files and use of deprecated functions.These problems are inspired from CERT coding rules (CERT CSecure Coding Standard, 2012; The CERT Sun MicrosystemsSecure Coding Standard for Java, 2009) and U.S. Department ofHomeland Security coding rules (US Department of HomelandSecurity Coding Rules, 2009) where they are representations ofknowledge gained from real-world experiences about potentialvulnerabilities that exist in programming languages. For scalabil-ity reasons, we target large-size software (gzip version 1.2.4) formonitoring purposes.
The remainder of this paper is organized as follows. Section 2provides an overview of the GCC compiler. In Section 3 we sum-marize the new proposition where weaving is performed on theGIMPLE representation of software by adopting an aspect-orientedstyle. In Section 4 we present SHL syntax and GIMPLE syntaxtogether with the weaving semantics for matching and weavingin GIMPLE trees. We analyze the correctness and the complete-ness of the GIMPLE weaving in Section 5. We explain in Section 6the implementation strategies of the GIMPLE weaving capabilitiesin the GCC compiler. We present in Section 7 security hardeningcase studies for validation and illustration purposes. The paper dis-cusses the related work in Section 8. Concluding remarks as well asa discussion of future work are represented in Section 9.
2. Overview of GCC
GCC is composed from three components: a front end, a backend, and a middle end (Machata, 2007; Callanan et al., 2006), asshown in Fig. 1. The compilation of a source file can be viewed asa pipeline that converts one program representation into another.
Source code enters the front end and flows through the pipeline,being converted at each stage into successively lower-level repre-sentation forms until final code generation in the form of assemblycode. There are two intermediate languages that are used on the
2656 D. Alhadidi et al. / The Journal of Systems a
iulRvtbpmfaw
iimilPuiloawewsC
Fig. 1. GCC architecture (Callanan et al., 2006).
nterfaces between the three “ends” of GCC. The higher level one,sed between front end and middle end, is called GENERIC. The
ower level one, used between middle end and back end, is calledegister Transfer Language (RTL). Both middle end and back end doarious optimizations on their intermediate representation beforehey turn it into a yet lower-level one. Each language supportedy GNU Compiler Collection (GCC) has its specific front end thatroduces the syntax tree abstraction of a given source code. Theeaning of a tree was somewhat different for different language
ront ends. This was simplified with the introduction of GENERICnd GIMPLE, two new forms of language-independent trees thatere introduced with the advent of GCC 4.0.
GENERIC provides a language-independent way of represent-ng an entire function in trees. For optimization purposes, GENERICs still a too high-level representation. At the GENERIC level,
any language-specific structures are preserved, e.g., loops. Dur-ng the compilation, it is lowered into GIMPLE. The process ofowering is called gimplification. In transforming code to GIM-LE, complex expressions are split into a three-address codesing temporary variables. GIMPLE is a subset of GENERIC and
t is the common language for a large number of new powerfulanguage- and architecture-independent global (function scope)ptimizations. Our approach in this paper is based on GIMPLE,
language-independent representation. Accordingly, the definedeaving approach in this paper is multi-language support. What-
ver the programming language used for software development,e can do the weaving as long as this programming language is
upported by the GCC compiler. These languages currently include, C++, Objective-C, Objective-C++, Java, Fortran, and Ada.
nd Software 86 (2013) 2654– 2674
3. GIMPLE weaving approach for security hardening
Software security hardening (Mourad et al., 2006) is defined asany process, methodology, product, or combination that is used toadd security functionalities, remove vulnerabilities, or prevent theirexploitation in existing software. Security hardening practices areusually manually applied by injecting security code into software(Bishop, 2005; Howard and LeBlanc, 2002; Seacord, 2005). In thispaper, we propose a novel and an aspect-oriented approach basedon the GIMPLE representation for the systemization of applicationsecurity hardening. The security solutions are woven into GIMPLErepresentations in a systematic way eliminating the need for man-ual hardening that may generate a considerable number of errors.GIMPLE (GNU, 2012) is a language-independent and an intermedi-ate representation generated by the GCC (GCC—the GNU CompilerCollection, 2009) compiler. It is based on a tree data structure. InGIMPLE, expressions are broken down into a three-address form,using temporary variables to hold intermediate values.
The proposed approach in this paper is based on the securityhardening language (SHL) that is defined in Mourad et al. (2007a,b).The authors have elaborated an aspect-oriented approach to per-form security hardening in a systematic way. In their approach,security experts provide security solutions using an abstract anda general aspect-oriented language called SHL that is expres-sive, human-readable, multi-language support and intermediatebetween English and programming languages. This relieves deve-lopers from the burden of security issues and allows them to focuson the main functionality of programs. The approach provides anabstraction over the actions that are required to improve the secu-rity of programs and adopts an aspect-oriented approach to buildand develop the required security solutions.
SHL is built on top of the current AOP technologies that arebased on the pointcut-advice model (Masuhara et al., 2003). Thesolutions elaborated in SHL are expressed by plans and patternsand can be refined into a selected AOP language. Security harden-ing patterns are high-level and well-defined solutions to knownsecurity problems, together with detailed information on how andwhere to inject each component of the solution into an application.A pattern includes a list of behaviors, each of which specifies theinsertion point and the code to be inserted at a specific location.Security hardening plans instantiate security hardening patternswith parameters regarding platforms, libraries, and languages. Thecombination of hardening plans and patterns constitutes a bridgethat allows security experts to provide the best solutions to partic-ular security problems and allows developers to use these solutionsto harden applications by developing security hardening patterns.The development implies manual refinement of solutions into oneof the existing AOP languages (e.g., AspectJ, AspectC++).
Fig. 2 illustrates the architecture of the GIMPLE weavingapproach presented in this paper together with the architec-ture presented in Mourad et al. (2007a,b). The GIMPLE weavingapproach bypasses the refinement step from patterns into AOPlanguages. This provides more systematization and automationbecause the refinement process in Mourad et al. (2007a,b) is per-formed manually by programmers. The hardening tasks specifiedin patterns are abstract and support multiple languages, whichmakes the GIMPLE representation a relevant target to apply thehardening. This is done by passing the SHL patterns and the orig-inal software to an extended version of the GCC compiler that inthe end generates the executable of the trusted software. For thispurpose, an additional pass is added to the GCC compiler in orderto interrupt the compilation once the GIMPLE representation of
code is completed. In parallel, the hardening pattern is compiledand a GIMPLE tree is built for each behavior using the routinesof the GCC compiler that are provided for this purpose. After-ward, the GIMPLE trees generated from the hardening patterns
D. Alhadidi et al. / The Journal of Systems a
attcpwptp
icalbtht
4
tsTcF
Fig. 2. Approach architecture.
re integrated in the GIMPLE tree of the original code with respecto the location(s) specified in each behavior of the hardening pat-ern. Finally, the resultant GIMPLE tree is passed again to the GCCompiler in order to continue the regular compilation process androduce the executable of the secure software. The extended GCCas originally implemented by our colleagues (Yang, 2007) for theurposes of dynamic vulnerability detection. We modify it in ordero inject the security functionalities specified in the hardeningatterns.
In the following, we present the formal specification of weav-ng an SHL pattern into the GIMPLE representation. In thisontext, we present GIMPLE and SHL syntax with matchingnd weaving semantics in GIMPLE. Providing such semanticseads to the implementation of the GIMPLE weaving capa-ilities. Moreover, it allows us establishing results regardinghe correctness and the completeness of weaving securityardening patterns into the GIMPLE representation of applica-ions.
. Formal weaving specification
In this section, we present SHL and GIMPLE syntax together withhe corresponding matching and weaving semantics. The GIMPLE
yntax covers the required constructs for the weaving semantics.he weaving semantics describes how to inject security-relatedode at specific locations in the GIMPLE representation of programs.irst, we need to introduce the following notation.
nd Software 86 (2013) 2654– 2674 2657
Notation
– The algorithms and notations are written with respect to theOCaml notations (OCaml for Scientists, 2012).
– Given a record space D = 〈f1 : D1, f2 : D2, . . ., fn : Dn〉 and an elemente of type D, the access to the field fi of an element e is written ase . fi.
– Given a type �, we write �-set to denote the type of sets havingelements of type �.
– Given a type �, we write �-list to denote the type of lists havingelements of type �.
– The type Identifier classifies identifiers.
4.1. SHL and GIMPLE syntax
In this subsection, we present SHL and GIMPLE syntax. We definean environment as the combination of a GIMPLE program and a SHLpattern. The syntax of SHL is presented in Fig. 3, where the mainpart is a pattern. A hardening pattern is based on the pointcut-advice model of AOP. A pattern includes a list of behaviors, each ofwhich specifies the insertion point and the code to be inserted at aspecific location. The insertion point of a behavior specifies wherethe code should be injected according to a specific location. It canhave the following three values: before, after or replace. Thevalue replace means remove the code at the identified locationand replace it with the new code, while the values before andafter mean keep the old code at the identified location and insertthe new code before and after it, respectively. A location identifiesjoint points in the program where behavior code should be applied.In the following, we present a list of constructs used in location. Thislist can be extended depending on the need for security hardeningsolutions.
– call: picks out the join points where we call a specific function.– execution: picks out the join points that refer to the entire code
segment of a specific function.– withincode: picks out the join points within a specific function.– set: picks out the join points where a variable is set.– get: picks out the join points where we a variable is gotten.– cflow: picks out the join points occurring in the dynamic execu-
tion context of the join points captured by a specific location.
The base locations can be combined using logical operators toproduce more complex ones. The code that is going to be woven isspecified by its name and its return type. Actually, this code couldbe provided as a library or left to be implemented by the user.
The GIMPLE syntax presented in Figs. 4 and 5 is based on the so-called rough GIMPLE grammar (Rough, 2012). A GIMPLE programconsists of the following main parts: a set of function declarations, aset of types, and a set of constants. A function declaration specifiesthe function name, the function type, the argument declarations,the result declaration, and the function block. The function blockrepresented by bind expr contains the declaration of the functionvariables and the function labels. In addition, multiple statementsat the same nesting level are collected into a list of statements asthe body of a block.
There are a variety of statements in GIMPLE. Most are assign-ment statements represented by modify expr, call statementsrepresented by call expr, and conditional statements repre-sented by cond expr. The modify statement has two parts: theleft-hand side and the right-hand side. The left-hand side can bea variable declaration, a parameter declaration, or an indirect ref-
erence, whereas the right-hand side can be one of the kinds ofthe left-hand side statements, a constant, a call statement, a unarystatement, a binary statement, a relational statement, or an addressexpression. We refer to the kind of unary statements as unary expr
2658 D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674
SHL s
tmt>usTgasatam
irvrptiavrbb
4
sr2
Fig. 3.
o represent !, ∼, etc., whereas we refer to the kind of binary state-ents as binary expr to represent +, -, *, etc. Similarly, we refer
o the kind of relational statements as rel expr to represent <,, etc. An indirect reference represents a pointer variable definedsing the indirect operator (*) in the C programming language andpecified by indirect ref and a variable declaration in GIMPLE.he address expression represents the operator (&) in the C pro-ramming language and specified by addr expr, a pointer type, and
variable declaration or a function declaration in GIMPLE. The calltatement has two parts: the address expression and the functionrguments. The conditional statement has three parts: the condi-ion and two statement lists. The condition can be either a constant,
variable declaration, a parameter declaration, or a relational state-ent.The considered base types are: integer type, represented by
nteger type; real type, represented by real type; boolean type,epresented by boolean type; and void type, represented byoid type. In addition there are two complex types: function type,epresented by function type, and pointer type, represented byointer type. Pointer type can specify a function type, which inurn specifies the function return type. Any declaration is spec-fied by a kind, a name, and a type. The following declarationsre considered: parameter declaration, represented by parm decl;ariable declaration, represented by var decl; result declaration,epresented by result decl; and label declaration, representedy label decl. Finally, constants are represented by natural num-ers.
.2. Matching and weaving semantics
In this subsection, we provide the matching and the weavingemantics. For information about GIMPLE semantics in general, weefer the reader to the contribution of Löding (Löding and Peleska,008).
yntax.
MatchingWe define the judgment fd, s � matchloc, which is used in the
matching rules presented in Fig. 6 to describe that a statement swithin the function declaration fd matches the location loc. A state-ment s can be a call statement cs, a modify statement ms, or eitherof the two statements cms. The rule (Call) describes the case wherethe current statement is a call statement, the current location is acall location, and the location signature equals the called functionspecified in the call statement. In such a case, the call statementmatches the call location.
The rule (Withincode) describes the case where the current state-ment is a call statement or an assignment statement, the currentlocation is a withincode location, and the location signature equalsthe name of the function where the call statement or the assign-ment statement exists. In such a case, the call statement or theassignment statement matches the withincode location.
The rule (Set) describes the case where the current statement isan assignment statement, the current location is a set location, andthe location signature equals the name of the variable being set. Insuch a case, the assignment statement matches the set location.
The rule (Get 1) describes the case where the current statementis an assignment statement, the current location is a get location,and the location signature equals the name of the variable being get.In such a case, the assignment statement matches the get location.The rule (Get 2) describes the case where the current statementis an assignment statement, the current location is a get location,and the location signature equals the name of the variable beingget by a unary operation. In such a case, the assignment statementmatches the get location. The rule (Get 3) describes the case wherethe current statement is an assignment statement, the current loca-
tion is a get location, and the location signature equals the name ofthe first variable being get by a binary operation. In such a case, theassignment statement matches the get location. The rule (Get 4)describes the case where the current statement is an assignment
D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674 2659
LE syn
ssbtcp
frcfaarmiE
Fig. 4. GIMP
tatement, the current location is a get location, and the locationignature equals the name of the second variable being get by ainary operation. In such a case, the assignment statement matcheshe get location. The rules (And), (Or 1), (Or 2), and (Not) describeases in which locations are combined using logical operators toroduce more complex ones.
WeavingTo accomplish the weaving, we should create a call statement
rom a given behavior to be woven in the specified locations. Theule (CreateWvStmt) presented in Fig. 7 describes how to do such areation where t is a type, fd, fd′, bfd are function declarations, ft is aunction type, pt is a pointer type, ae is an address expression, beh is
behavior, and E is an environment. The call statement represents call to the function specified in the behavior code. In addition, it
epresents the statement that is going to be woven into the state-ents that match the location of the behavior. The environment
s changed as a result of such a creation. We define the judgment, beh�buildE′, cs to represent that the call statement cs is built based
tax – Part 1.
on the behavior beh. The environment E′ reflects a modified versionof the environment E after creating the call statement cs. The fol-lowing steps are required to create a call statement from a givenbehavior:
– Build a result type for the weaved function and add it to thedefined types in the program.
– Build a function type for the weaved function and add it to thedefined types in the program.
– Build a function declaration for the weaved function and add itto the declared functions in the program.
– Build a pointer type for the weaved function and add it to the
defined types in the program.
– Build an address expression for the weaved function.– Build a call statement to the weaved function based on the
address expression.
2660 D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674
LE syn
–
rBtisi〈tb(ccmmtmamspte
Fig. 5. GIMP
Modify the environment to include all the new defined types andall the new defined constants together with the new functiondeclaration.
In the weaving rules presented in Fig. 8, the weaving process isepresented by the weaving configuration 〈Environment, FunDecl,ehavior − list, Stmt, State〉. The state State is a flag that representshe stage of the behavior weaving process, which is either weav-ng or end. The flag is equal to weaving when applicable behaviorstill have to be woven, whereas it becomes end when the weavings completed. Hence, the transformation 〈E, fd, behL, s, weaving〉 →E′, fd′, behL′, s′, end〉 means that the environment E′ and the func-ion declaration fd′ is the result of weaving all the applicableehaviors in the behavior list behL into the statement s. The ruleBefore) describes the case where a before location matches a spe-ific statement. The call statement created from the behavior thatontains the before location is inserted before the matched state-ent. The rule (After) describes the case where an after locationatches a specific statement. The call statement created from
he behavior that contains the after location is inserted after theatched statement. The rule (Replace) describes the case where
replace location matches a specific statement. The call state-ent created from the behavior that contains the replace location
upersedes the matched statement. Additionally, it is required toropagate the weaving changes that are done to a specific func-ion to higher levels in each weaving rule, i.e., the program and thenvironment where the corresponding function exists should be
tax – Part 2.
changed accordingly. The rule (NoMatch) describes the case wherethe location does not match a specific statement. In this case, theweaving process continues with the rest of the behaviors. Finally,the rule (End 1) and the rule (End 2) represent the cases wherethere are no more behaviors to check for weaving and where thebody of the function block contains no statements, respectively. Intheses cases, the weaving process is halted for the correspondingfunction declaration.
4.3. Utility functions
In this subsection, we define all the utility functions that areused to express the weaving semantics.
– The function buildRetType takes a behavior code and returns atype.
t = integer type if c.iRetType = integer type;t = real type if c.iRetType = real type;t = boolean type if c.iRetType = boolean type;t = void type if c.iRetType = void type.
– The function buildFunType takes a type and returns a function
type.
buildFunType: Type → FuncTypebuildFunType(t)=ft where (ft . kind = function type) ∧
(ft . type = t)
D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674 2661
Fig. 6. Matching rules.
state
–
–
Fig. 7. Weaved
The function buildCallStmt takes an address expression andreturns a call statement.
buildCallStmt: AddrExpr → CallStmt
buildCallStmt(ae)=cs where (cs . kind = call expr) ∧
(cs . addrExpr = ae) The function buildFunDecl takes a behavior code and a functiontype. It returns a function declaration.
ment creation.
buildFunDecl: Code × FuncType → FuncDeclbuildFunDecl(c, ft)=fd where (fd . kind = function decl) ∧
(fd . fname = c . iName) ∧ (fd . ftype = ft)
– The function extractConst takes a statement list and returns a
In this section we address the completeness and the correctnessof GIMPLE weaving from two different views. In the first approachwe present algorithms that implement the semantics reported inthe rules in Figs. 6–8. Then, we prove the correctness and thecompleteness of GIMPLE weaving algorithms with respect to theweaving semantics. In the second approach, we adapt Kniesel’sdiscipline (Kniesel, 2009) wherein a language-independent cor-rectness and completeness analysis is discussed.
5.1. First approach
We have three algorithms: WS in Fig. 9, M in Fig. 10, and W inFig. 11. The first, WS, is meant to create a call statement from a givenbehavior. It takes as arguments an environment E and a behav-ior beh and yields a modified environment E′ and a call statementcs. The second algorithm, M, is meant for matching. It takes threearguments: a function declaration fd, a location loc, and a state-ment s. It returns true if the statement s matches the location loc,and it returns false otherwise. The third algorithm, W, implementsthe weaving semantics reported in Fig. 8. It takes four arguments:an environment E, a function declaration fd, a behavior list behL,and a statement s. It yields an environment E′ and a function dec-
laration fd′. The environment E′ and the function declaration fd′
reflect a modified version of the environment E and the functiondeclaration fd, respectively, after the weaving process. In the fol-lowing, we state and prove results that establish the soundness and
D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674 2663
Fig. 9. Weaved statement creation algorithm.
tching
cs
Li
Tr
WLb
Tr
r
Ll
Fig. 10. Ma
ompleteness of the algorithms WS, M, and W with respect to theemantics reported in Figs. 6–8.
The following lemma states the soundness of the algorithm WS:
emma 1. (Soundness of WS). Given an environment E and a behav-or beh, if WS(E, beh) =(E′, cs) then E, beh�buildE′, cs.
he proof of Lemma 1 is straightforward since the algorithm WSesults from the rule (CreateWvStmt) presented in Fig. 7.
The following lemma states the completeness of the algorithmS:
emma 2. (Completness of WS). Given an environment E and aehavior beh, if E, beh�buildE′, cs then WS(E, beh) =(E′, cs).
he proof of Lemma 2 is straightforward since the algorithm WSesults from the rule (CreateWvStmt) presented in Fig. 7.
The following lemma states the soundness of the matching algo-
ithm M:
emma 3. (Soundness of M). Given a function declaration fd, aocation loc, and a statement s, if M(fd, loc, s) then fd, s � matchloc.
algorithm.
To establish this Lemma, we proceed by case analysis:
Proof.
– Case (call):From the algorithm, we have:
loc . kind = call
s . kind = call expr
s . addrExpr . op . fname = loc . signature
Since s . kind = call expr then s is cs statement.By the rule (Call):
fd, cs � matchloc
– Case (withincode):From the algorithm M, we have two possible scenarios for this
case. In the first one, we have:loc . kind = withincode
s . kind = call expr
fd . fname = loc . signature
Since s . kind = call expr then s is cs statement.By the rule (Withincode):
fd, cms � matchloc
2664 D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674
aving
–
–
Fig. 11. We
In the second scenario, we have:loc . kind = withincode
s . kind = modify expr
fd . fname = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Withincode):
fd, cms � matchloc
Case (set):From the algorithm M, we have:
loc . kind = set
s . kind = modify expr
s . lhs . kind = var decl
s . lhs . name = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Set):
fd, ms � matchloc
Case (get):From the algorithm M, we have four possible scenarios for this
case. In the first one, we have:loc . kind = get
s . kind = modify expr
s . rhs . kind = var decl
s . rhs . name = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Get 1):
fd, ms � matchloc
algorithm.
In the second scenario, we have:loc . kind = get
s . kind = modify expr
s . rhs . op . kind = var decl
s . rhs . op . name = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Get 2):
fd, ms � matchloc
In the third scenario, we have:loc . kind = get
s . kind = modify expr
s . rhs . op1 . kind = var decl
s . rhs . op1 . name = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Get 3):
fd, ms � matchloc
In the fourth scenario, we have:loc . kind = get
s . kind = modify expr
s . rhs . op2 . kind = var decl
s . rhs . op2 . name = loc . signature
Since s . kind = modify expr then s is ms statement.By the rule (Get 4):
fd, ms � matchloc
�
tems a
a
Ll
PtL
–
�
a
Tfm〈
PWF〈
–
–
D. Alhadidi et al. / The Journal of Sys
The following lemma states the completeness of the matchinglgorithm M.
emma 4. (Completeness of M). Given a function declaration fd, aocation loc, and a statement s, if fd, s � matchloc then M(fd, loc, s).
roof. The proof of Lemma 4 is straightforward by propagatinghe matching rules presented in Fig. 6 from conclusion to premises.et us take as example the following case:
Case (call):From the rule (Call):
loc . kind = call
cs . addrExpr . op . fname = loc . signature
Since s is a cs statement, then s . kind = call exprBy the algorithm M:
M(fd, loc, s)
The following theorem states the soundness of the weavinglgorithm W.
heorem 1. (Soundness of W). Given an environment E, aunction declaration fd, a behavior list behL, and a state-
ent s, if W(E, fd, behL, s)=(E′′′, fd′′′) then 〈E, fd, behL, s, weaving〉 →E′′′, fd′′′, [ ], s′, end〉.
roof. By the algorithm W, if fd . block . body = [], we have:(E, fd, behL, s)=(E, fd)
rom the rule (End 2), we conclude:E, fd, behL, s, weaving〉 → 〈E, fd, [ ], s, end〉
The rest of the proof is done by induction over the length of behL.
Induction basis (behL = []):By the algorithm W, we have:
W(E, fd, [ ], s)=(E, fd)
From the algorithm W, we conclude that behL = [].From the rule (End 1), we conclude:
We assume as induction hypothesis:If W(E, fd, behL′, s)=(E′′′, fd′′′) then 〈E, fd, behL′, s, weaving〉 →
〈E′′′, fd′′′, [ ], s′, end〉.Now, let us consider (behL = beh : : behL′):Since beh . location can be a:
– Case (before-location):From the algorithm W, we have:
beh . insertionPoint = before
M(fd, beh.location, s)fd . block . body = l @ (s : : l′)(E′′, cs) = WS(E, beh)funSet = E′′.program.funsfd′ = {fd with block . body = l @ (cs : : (s : : l′))}E′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the soundness of the algorithm M and the algorithm WS,we conclude:fd, s � matchlocE, beh�buildE′′, cs
From the rule (Before), we conclude:〈E, fd, beh :: behL′, s, weaving〉 → 〈E′, fd′, behL′, s, weaving〉By the hypothesis, we conclude:〈E′, fd′, behL′, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉
By the transitivity of →, we conclude:〈E, fd, behL, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉
– Case (after-location):From the algorithm W, we have:
nd Software 86 (2013) 2654– 2674 2665
beh . insertionPoint = after
M(fd, beh.location, s)fd . block . body = l @ (s : : l′)(E′′, cs) = WS(E, beh)funSet = E′′.program.funsfd′ = {fd with block . body = l @ (s : : (cs : : l′))}E′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the soundness of the algorithm M and the algorithm WS,we conclude:fd, s � matchlocE, beh�buildE′′, cs
From the rule (After), we conclude:〈E, fd, beh :: behL′, s, weaving〉 → 〈E′, fd′, behL′, s, weaving〉By the hypothesis, we conclude:〈E′, fd′, behL′, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉By the transitivity of →, we conclude:〈E, fd, behL, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉
– Case (replace-location):From the algorithm W, we have:
beh . insertionPoint = replace
M(fd, beh.location, s)fd . block . body = l @ (s : : l′)(E′′, cs) = WS(E, beh)funSet = E′′.program.funsfd′ = {fd with block . body = l @ (s : : l′)}E′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the soundness of the algorithm M and the algorithm WS,we conclude:fd, s � matchlocE, beh�buildE′′, cs
From the rule (Replace), we conclude:〈E, fd, beh :: behL′, s, weaving〉 → 〈E′, fd′, behL′, cs, weaving〉By the hypothesis, we conclude:〈E′, fd′, behL′, cs, weaving〉 → 〈E′′′, fd′′′, [ ], cs′, end〉By the transitivity of →, we conclude:〈E, fd, behL, s, weaving〉 → 〈E′′′, fd′′′, [ ], cs′, end〉
– Case (no match):From the algorithm W, we have:
fd . block . body = l @ (s : : l′)
By the soundness and the completeness of the algorithm M,we conclude:fd, s � matchnot loc
From the rule (NoMatch), we conclude:〈E, fd, beh :: behL′, s, weaving〉 → 〈E, fd, behL′, s, weaving〉By the hypothesis, we conclude:〈E, fd, behL′, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉By the transitivity of →, we conclude:〈E, fd, behL, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉
�
The following theorem states the completeness of the weavingalgorithm W.
Theorem 2. (Completeness of W). Given an environmentE, a function declaration fd, a behavior list behL, and astatement s, if 〈E, fd, behL, s, weaving〉 → 〈E′′, fd′′, [ ], s′′, end〉 thenW(E, fd, behL, s)=(E′′, fd′′).
Proof. By the rule (End 2), we have:〈E, fd, behL, s, weaving〉 → 〈E, fd, [ ], s, end〉From the rule (End 2), we conclude that fd . block . body = [].
From the algorithm W, we conclude:W(E, fd, behL, s)=(E, fd).
The rest of the proof is done by induction over the length of behL.
– Induction basis (behL = []):
By the rule (End 1), we have:
〈E, fd, behL, s, weaving〉 → 〈E, fd, [ ], s, end〉From the rule (End 1), we conclude that behL = [].
From the algorithm W, we conclude:
2 tems a
–
�
666 D. Alhadidi et al. / The Journal of Sys
W(E, fd, [ ], s)=(E, fd)
Induction step:We assume as induction hypothesis:If 〈E, fd, behL, s, weaving〉 → 〈E′′′, fd′′′, [ ], s′, end〉 then
W(E, fd, behL, s)=(E′′′, fd′′′).Now, let us consider (behL = beh : : behL′):Since beh . location can be a:
– Case (before-location):From the rule (Before), we conclude:
fd . block . body = l @ (s : : l′)fd, s � matchbeh . locationE, beh�buildE′′, csbeh . insertionPoint = before
fd′ = {fd with block . body = l @ (cs : : (s : : l′))}funSet = E′′.program.funsE′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the completeness of the algorithm M and the algorithmWS, we conclude:M(fd, beh.location, s)(E′′, cs) = WS(E, beh)From the algorithm W, we conclude:W(E, fd, beh :: behL′, s)=W(E′, fd′, behL′, s)
By the hypothesis, we conclude:W(E′, fd′, behL′, s)=(E′′′, fd′′′)
– Case (after-location):From the rule (After), we conclude:
fd . block . body = l @ (s : : l′)fd, s � matchbeh . locationE, beh�buildE′′, csbeh . insertionPoint = after
fd′ = {fd with block . body = l @ (s : : (cs : : l′))}funSet = E′′.program.funsE′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the completeness of the algorithm M and the algorithmWS, we conclude:M(fd, beh.location, s)(E′′, cs) = WS(E, beh)From the algorithm W, we conclude:W(E, fd, beh :: behL′, s)=W(E′, fd′, behL′, s)
By the hypothesis, we conclude:W(E′, fd′, behL′, s)=(E′′ ′, fd′′′)
– Case (replace-location):From the rule (Replace), we conclude:
fd . block . body = l @ (s : : l′)fd, s � matchbeh . locationE, beh�buildE′′, csbeh . insertionPoint = replace
fd′ = {fd with block . body = l @ (cs : : l′)}funSet = E′′.program.funsE′ = {E′′ with program.funs = (funSet\{fd}) ∪ {fd′}}By the completeness of the algorithm M and the algorithmWS, we conclude:M(fd, beh.location, s)(E′′, cs) = WS(E, beh)From the algorithm W, we conclude:W(E, fd, beh :: behL′, s)=W(E′, fd′, behL′, cs)
By the hypothesis, we conclude:W(E′, fd′, behL′, cs)=(E′′′, fd′′′)
– Case (no Match):From the rule (NoMatch), we conclude:
fd . block . body = l @ (s : : l′)fd, s � matchnot beh . location
By the soundness and the completeness of the algorithm M,we conclude:notM(fd, beh.location, s)
From the algorithm W, we conclude:W(E, fd, beh :: behL′, s)=W(E, fd, behL′, s)
By the hypothesis, we conclude:
W(E, fd, behL′, s)=(E′′′, fd′′′)
nd Software 86 (2013) 2654– 2674
5.2. Second view
The adopted discipline in this subsection is based on Kniesel’sproposal (Kniesel, 2009). In the following, we give an overview ofthis discipline wherein a language-independent correctness andcompleteness analysis is presented. The discipline of Kniesel doesnot require programmers to annotate their programs or writesemantic specifications of program actions. In addition, it is inde-pendent of the aspect language and the program language, and itis independent of the program to which the analyzed aspects areapplied. Consequently, it is a perfect fit for GIMPLE weaving. Whilegiving more details to this discipline, we apply the defined nota-tions in this paper to Kniesel’s approach, i.e., behavior, location,etc.
Weaving interactions can give rise to interferences that mayalter the correctness and the completeness of weaving in general.The completeness constraints state that in the weaving result everybehavior code must be applied at all the join points matched bythe associated location. On the other hand, the correctness con-straints state that in the weaving result every behavior code mustbe applied only at the join points matched by the associated loca-tion. This is exactly what we need to ensure in our case. Actually,every security property represented with a behavior can be sat-isfied by applying the corresponding behavior code at all the joinpoints and only the join points matched by the behavior location.Jointly deployed behaviors may interact with each other. If mul-tiple behaviors are used within the same program, correctness orcompleteness of weaving could be violated by two kinds of weavinginterferences:
– Missing behavior code that does not appear where it should have,e.g., behavior A could add a method m that contains field accesses,and behavior B might want to enforce that all field accesses arelogged. If the weaving process does not ensure that behavior B isexecuted after behavior A, logging code will not be added to thefield accesses of m.
– Erroneous behavior code that appears at the wrong join points,e.g., behavior A code is added at a time when its matching joinpoints have already been removed by a replace behavior B.
The definition of correct and complete weaving tells us whatis expected from a weaver but not yet how to achieve it. Toderive an algorithm that enforces correctness and completenessor otherwise diagnoses the cause of errors according to Kniesel’sapproach, it is necessary to understand the mechanisms that collab-orate in producing errors. Weaving candidates are code of behaviorsthat should be woven jointly. Selections generalize the notion ofselected join points. An element of a selection is a join point.Weaving interactions arise if weaving of a candidate adds, deletes,or modifies program elements, thus modifying the future or pastselections of other candidates. The candidate that performs suchactions is called the affecting candidate, whereas the one whoseselection is changed (extended or reduced) is called the affectedcandidate. Weaving interferences arise if the candidate affected bythe weaving interaction is executed before the affecting one. Thechange of a past selection invalidates the assumption made by theaffected candidate. The invalidated assumptions can be positive (itwas assumed that a particular program element existed) or neg-ative (it was assumed that an element did not exist). Invalidatedassumptions require corrective actions to be performed for theaffected candidates. If the selection is extended, correction impliesapplying their actions at the additional join points. If the selection
is reduced, correction undoes actions of the affected candidate atthe corresponding join points. Weaving errors, i.e., missing code anderroneous code, are caused by weaving interferences that are notrepaired. Existing weavers do not support repair. Consequently, it is
tems a
eisa
aaKiJTmamCoabttpwtoditpetitw
–
–
pipvcr((t
csctdotrc
etce
D. Alhadidi et al. / The Journal of Sys
ssential to prevent interferences. This can be achieved by detectingnteractions in advance and scheduling the execution of candidatesuch that the affected ones are always executed after those thatffect them.
Kniesel’s approach is based on a representation of programss logic fact bases and a representation of weaving candidatess conditional transformations (CT) (Kniesel and Koch, 2004;niesel, 2006) of fact bases. Conditional transformations can be
mplemented efficiently, as demonstrated by their incarnation inTransformer (JTransformer Framework, 2009) and the Conditionalransformation Core (CTC) system (ConTraCT, 2012). The imple-entation of the uniformly generic aspect language LogicAJ (Rho
nd Kniesel, 2004) demonstrates the effectiveness of CTs as a formalodel for aspects and a target language for aspect compilation. A
T consists of a precondition and a transformation that is executedn the program elements for which the precondition is true. Thessumptions of a CT about the transformed program are capturedy its precondition. From the precondition and the transforma-ion, it is possible to derive the CT’s postcondition, which captureshe state of the program after the CT execution. A comparison ofre- and postconditions suffices to detect all potential or concreteeaving interactions. Any modification of a CT’s assumptions by
he effects of another CT corresponds to a pair of unifiable literals:ne in the precondition of the affected CT and one in the postcon-ition of the affecting CT. If both unifiable literals are positive or
f both are negative the affecting CT’s postcondition contributeso making the affected CT’s precondition true on some additionalrogram elements. Thus, it potentially triggers the second one. Oth-rwise, the violating CT’s postcondition contributes to invalidatinghe violated CT’s precondition on some program elements. Thus,t potentially inhibits the second one. Accordingly, the followingwo kinds of weaving interactions can occur among any two jointlyoven candidates a and b:
Triggering: The candidate a triggers or enables b if it adds,removes, or modifies elements such that b’s predicate addition-ally succeeds for at least one previously unselected join point.
Inhibition: The candidate a inhibits or disables b if it adds,removes, or modifies elements such that b’s predicate becomesfalse for at least one previously selected join point.
The graph of triggering and inhibition relations provides arecise characterization of the interactions of different weav-
ng candidates. Kniesel shows that acyclic graphs correspond torograms whose interactions can be resolved automatically, pre-enting interferences. Graphs with cycles define different problemategories depending on the structure of the cycle. The problemsange from the need to use weavers that support interference repairrepairable interference), to the need for additional user inputincomplete program), and finally to the impossibility of weavinghis set of aspects correctly and completely (conflict).
To ensure correct and complete weaving, it is essential to con-entrate on the case of acyclic graphs where interferences can beolved using prevention. The main idea is to statically analyze theandidate set for potential triggering and inhibition relations ando order it such that each candidate is executed after all the candi-ates whose effects could trigger or inhibit it. The required weavingrder is a partial order on the candidates defined as: a before b ≡ ariggers b ∨ a inhibits b. Any total order that is consistent with theequired weaving order is guaranteed to ensure correctness andompleteness of weaving, as proved by Kniesel.
To adapt this algorithm to GIMPLE weaving, we need to gen-
rate the base facts of GIMPLE representations, and we need toranslate the aspectual constructs of SHL to CTs. The former issuean be achieved by adapting the algorithm described by Marponst al. (2008). The authors extracted, from GIMPLE representation,
nd Software 86 (2013) 2654– 2674 2667
program information as Prolog facts that describe structural prop-erties of software. They distinguished between global and localentities. Global entities can appear outside a function or a methoddefinition. For each global entity either declared or defined, a factis generated stating that this entity exists. Following the identi-fication, a Prolog predicate exists for every relevant property ofglobal entities, and terms are generated for every occurrence of theproperty. Additionally, relations among global entities exist. Localentities can appear inside a function or a method and are not globalentities. A Prolog term is generated for local entities such as localvariables and function arguments.
On the other hand, the translation of aspectual constructs ofSHL to CTs can be achieved by describing how to convert SHL con-structs into CTs. Basic SHL constructs can be converted to LogicAJ(Rho and Kniesel, 2004) constructs, which in turn compiles themto CT sets. LogicAJ (Rho and Kniesel, 2004) is a uniformly genericaspect language. It replaces wildcards by explicit meta-variablesthat can be uniformly used in pointcuts, introductions, and adviceas placeholders for (almost) arbitrary base program elements. Thus,it goes beyond type genericity and can express heterogeneous,context-dependent actions. LogicAJ has call, execution, set, get, andwithincode pointcuts. SHL constructs can be converted to thesepointcuts by specifying the targeted name of a method or a vari-able. For example, the SHL base location call f is converted to theLogicAJ pointcut call * *.f(..).
6. Implementation of GIMPLE weaving capabilities into GCC
We implement into the GCC compiler the weaving featuresinspired by the defined semantics. This implementation allowsweaving patterns into the GIMPLE representation of programsbefore generating the corresponding executables. We handlebefore, after, and replace behaviors. In addition, we target call, set,get, and withincode locations.
Three input files are needed by the extended compiler to per-form the weaving: a source code, a configuration file, and a librarycontaining the subroutines to be woven. To enable our GCC exten-sion to do code weaving, we use command-line options. Theimplementation methodology that is adopted consists of the fol-lowing steps: First, we generate a configuration file from the SHLfile. The configuration file contains all the information needed forthe weaving using our extended GCC. A line in the configuration fileis a string composed of five fields delimited by spaces. The struc-ture of this file is shown in Table 1. To generate the configurationfile, the specification of SHL is designed and implemented usingANTLR V3 Beta 6 and its associated ANTLRWorks 1.1.7 GUI devel-opment environment (ANTLR Parser Generator, 2012). Using thistool, Java code is generated to parse hardening patterns, to checkthe correctness of their syntax, and consequently to populate theconfiguration file. The name of this configuration file is included asa command-line option to be used with an extended version of theGCC compiler version 4.2.0. In order to invoke this extension, thefollowing option should be included at the command line:
-ftree-security-weaving=weaving configuration filewhere -ftree-security-weaving signals the extended
GCC to enable the weaving functionality and weav-ing configuration file is the configuration file. In addition tothe above option, the library that contains the code to be wovenmust be specified. This is done through GCC’s options -l and -L.An example of a complete command that performs the weavingusing our extended GCC is:
2668 D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674
Table 1Configuration file structure.
Order Purpose Value and meaning
1 Weaving position 0: before1: after2: replace
2 Location kind 0: call1: set2: get3: withincode
3 Name of a concerned functionor variable
A string of function name or astring of a variable name
4 Name of the function to bewoven
A string of a function name
5 Returned type of the weavedfunction
0: void
1: integer
Ttdccm
7
tbsvocTCSc2rpww
7
mSnpm
Fig. 13. Vulnerable code – umask function.
2: real3: boolean
hen, a GIMPLE tree is built for the code of each behavior in a pat-ern. Afterward, each generated tree is injected in the program treeepending on the insertion point and the location specified in theonfiguration file. Once this weaving procedure is done, the GCCompiler takes over and continues the classical compilation of theodified tree to generate the executable of the hardened program.
. Case studies
In this section, we detail the experiments conducted to explorehe correctness of the security hardening process and the feasi-ility of our propositions. We conduct various experiments overmall programs as well as large-sized software, in particular gzipersion 1.2.4 (96 files totaling 24,247 lines of code). Case studiesf small programs are developed to solve problems: the unsafereation of temporary files and the use of deprecated functions.hese problems are inspired from CERT coding rules (CERT C Secureoding Standard, 2012; The CERT Sun Microsystems Secure Codingtandard for Java, 2009) and U.S. Department of Homeland Securityoding rules (US Department of Homeland Security Coding Rules,009), where they are representations of knowledge gained fromeal-world experiences about potential vulnerabilities that exist inrogramming languages. For scalability, we target large-sized soft-are (gzip version 1.2.4) for monitoring purposes. In the following,e detail the experiments.
.1. Unsafe temporary file creation
Temporary files are created for different purposes such as infor-ation sharing, temporary data storage, and computation speed.
ince temporary files are usually created in shared folders, it isecessary to set appropriate permissions to these files to ensurerotection against attackers. The function umask() sets the per-ission modes for newly created files. We should set the umask
Fig. 12. SHL hardening patte
Fig. 14. Vulnerable code execution – umask.
to the most restrictive value possible so the group or world is notallowed to read, write, or execute before creating any new file. TheCERT rule that appears in the C Secure Coding Standard and targetsthis issue is:
FIO43-C: Do not create temporary files in shared directoriesThis vulnerability exists in well-known packages such as:
– The package openssh-5.0p1, which encrypts all traffic to effec-tively eliminate eavesdropping, connection hijacking, and otherattacks. Additionally, openssh-5.0p1 provides secure tunnelingcapabilities and several authentication methods.
– The package shadow-4.1.1, which contains programs for handlingpasswords in a secure way.
– The package patchutils-0.1.5, which is a small collection of pro-grams that operate on patch files.
– The package kstart-3.14, which is a daemon version of kinit.– The package inn-2.4.6, which is a full-featured, flexible, and con-
figurable news server.– The package binutils-2.19.1, which is a collection of programming
tools for the manipulation of object code in various object fileformats.
Fig. 12 presents the pattern elaborated in SHL to solve thisproblem. The pattern sets the umask to the most restrictive valuepossible using the function umask (S IRWXG | S IRWXO) before anycall for the function fopen. The function umask (S IRWXG | S IRWXO)represents the Code in SHL syntax. We inline the code part inside thepattern to facilitate reading. The function fopen opens a file for read-ing, writing, or updating. In Fig. 13, fopen creates a file for writing.Fig. 14 shows the run of the code presented in Fig. 13 without hard-ening, whereas Fig. 15 shows the run of the same code hardenedby the GIMPLE weaving capabilities using the pattern presented inFig. 12. The execution of the vulnerable code shows that the cre-ated temporary file has (rw - r - -r - -) permissions, whereas the
execution of the hardened code shows that the temporary file cre-ated has (rw - - - - - - -) permissions, the most restrictive.
rn for umask function.
D. Alhadidi et al. / The Journal of Systems and Software 86 (2013) 2654– 2674 2669
Fig. 15. Hardened code execution – umask.
7
ntebr
–
–
–
–
T
–
–
lcb
Fig. 18. Vulnerable code execution – rand.
Fig. 16. SHL hardening pattern for rand function.
.2. Use of deprecated function
The C library rand() function is a deprecated one, and it doesot have good random number properties. It produces numbershat can be easily guessed by attackers and should never be usedspecially for cryptographic purposes. The CERT coding rules for-id the usage of this function and recommend using the functionandom() instead. The CERT rules that target this issue are:
This rule appears in the C Secure Coding Standard as MSC30-C.Do not use the rand() function for generating pseudorandomnumbers.
This rule appears in the C++Secure Coding Standard asMSC30-CPP. Do not use the rand() function for generating pseu-dorandom numbers.
This rule appears in the C Secure Coding Standard as MSC32-C.Ensure your random number generator is properly seeded.
This rule appears in the C++Secure Coding Standard as MSC32-CPP. Ensure your random number generator is properly seeded.
his vulnerability exists in well-known packages such as:
The package apache-1.3.41, which is used for password genera-tion.
The package pzebra-0.95a and the package emacs-22.3, which areused for time synchronization purposes.
Fig. 16 presents the pattern elaborated in SHL to solve this prob-em. The pattern replaces any call to the function rand() with twoonsecutive instructions. The first instruction creates a new seedased on the current time whereas the second one executes the
Fig. 17. Vulnerable cod
Fig. 19. Hardened code execution – rand.
random() function using the generated seed by the first instruc-tion. The lines 7–14 in Fig. 16 represent the Code in SHL syntax. Thecode in Fig. 17 prints a random number using the function rand().Fig. 18 shows multiple executions of the code presented in Fig. 17without hardening, whereas Fig. 19 shows executions of the samecode hardened by the GIMPLE weaving capabilities using the pat-tern in Fig. 16. The execution of the vulnerable code several timesgenerates the same pseudorandom number using the rand() func-tion. When rand() is not seeded, it uses 1 as a default seed. Nomatter how many times this code is executed, it always producesthe same pseudorandom number. Even if the rand() function isproperly seeded, this solution does not work because the numbersgenerated by rand() have a comparatively short cycle and maybe predictable. On the other hand, the execution of the hardenedcode produces different random number sequences at differentcalls exploring the correctness of the security hardening processand the feasibility of our propositions.
7.3. Monitoring
Many dynamic program analysis tools need to observe programexecution and gather information in order to analyze the testeeprograms’ runtime behavior. This task can be carried out by mon-itoring tools. Program monitoring can be performed at differentlevels. At a low level, hardware monitors extend the target systemwith specialized hardware architecture. For example, researchers
have included counters in their microprocessor’s hardware to pro-file the execution of some predefined events. The advantage ofhardware monitoring is its low overhead. The major drawback ofthis approach is that monitors can only observe low-level data at
e – rand function.
2 tems a
rmiagvtngiCnTIa
7
wrlmTailt
7
ocStmmppt
7
gmitftm
–
–
7
coa
670 D. Alhadidi et al. / The Journal of Sys
estricted types of observation points. Software monitoring is aore widely-used approach to observe a program’s runtime behav-
or. In contrast to hardware monitors, software monitors can easilyccess high-level data, e.g., objects and structures in modern pro-ramming languages. Additionally, they can be designed to observearious program points such as function calls and to access par-icular variables. Implementing software monitoring techniquesecessitates program instrumentation. In this case study, we targetzip version 1.2.4 (96 files totaling to 24,247 lines of code) for mon-toring purposes. The experiment picks out calls to the standard
library functions for memory management and instruments theeeded code to help detect memory management vulnerabilities.here are various instrumentation techniques to achieve this goal.n the following we discuss these techniques with their advantagesnd disadvantages.
.3.1. Library replacement instrumentationThe simplest application to program instrumentation is realized
ithout transforming the program. The technique involves onlyeplacing the library used by the program. For example, the dmal-oc memory debugging library replaces the standard C library to
onitor memory management behavior of the monitored program.he monitoring functionality is included in the dmalloc library. Thispproach is clean and efficient. However, it prevents us from mon-toring program behaviors that are not associated with externalibraries. Therefore, it can only be used in very dedicated applica-ions.
.3.2. Preprocessor macros instrumentationC and C++compilers call the preprocessor during the first phase
f compilation to include external files into the compiled sourceode and perform textual substitutions that are defined by macros.imple code instrumentation can be implemented by utilizinghe code transformation functionality of the preprocessor. Using
acro-assisted source code transformation to perform code instru-entation is easy to implement. However, only a few program
oints can be effectively instrumented with this approach becausereprocessors cannot access the lexical structure and semantics ofhe instrumented program.
.3.3. Parser-assisted source code instrumentationParser builds the parse tree and abstract syntax tree of the pro-
ram after source code is preprocessed. Therefore, it can accessore information than can the preprocessor. The information
ncludes the full syntactical structure. Parser-assisted source coderansformation can be very powerful. For example, the Puma libraryrom AspectC++project (Spinczyk et al., 2002) can perform sophis-icated source code transformation at various program points. Two
ain disadvantages of source code weaving are:
Language dependency: Source code weaving is written explicitlyfor the syntax of the input language.
Limited expressiveness: Aspects are limited to the expressivepower of the source language. For example, it is not possible toadd multiple-inheritance to a single-inheritance language. Addi-tionally, AspectC++intentionally does not implement the fieldaccess pointcuts such as field set and get because of the existenceof free pointers. Field access through pointers is quite common inC/C++and implies a danger of “surprising” side effects for advice.
.3.4. Bytecode instrumentation
Instead of targeting the source code for instrumentation, byte-
ode has been chosen to inject the required monitoring code. Basedn bytecode instrumentation, aspect weaving tools, such as AspectJ,llow insertion of code at well-defined points in Java programs
nd Software 86 (2013) 2654– 2674
without resorting to source code manipulation. The main disad-vantages of bytecode weaving are:
– Bytecode dependency: Bytecode weaving is written explicitly forJava bytecode instruction sets and accordingly the source codeshould be written in Java.
– Bytecode is not a structured language. Structured programmingis a programming paradigm aimed at improving the clarity, qual-ity, and development time of a computer program by makingextensive use of subroutines and block structures.
– Compared to GIMPLE representation, bytecode representationneeds more instructions per one line in the source code. Thismeans more time is needed to pick out the required points in aprogram (Vasseur and Dahlstedt, 2012).
– In order to know whether a class/method/field should be consid-ered for weaving, the weaver needs to do matching on metadatafor this class or member. Most AOP frameworks and AOP-appliedproducts have some sort of high-level expression language(pointcut expressions) to define where (at which join points) acode block (advice) should be weaved into. These expression lan-guages can, for example, let you pick out all methods that havea return type that implements an interface of type T. This infor-mation is not available in the bytecode instructions representingthe call to a specific method M. The only way of knowing if thisspecific method M should be weaved or not is to look it up insome sort of class database, query its return type, and check ifits return type implements the given interface T (Vasseur andDahlstedt, 2012).
– Lack of a program’s semantic information, such as control flowand dataflow.
7.3.5. GIMPLE instrumentationWith GCC’s internal APIs, it is easy to manipulate the GIMPLE
representation. The advantages of GIMPLE weaving over the afore-mentioned approaches are:
– GIMPLE is an intermediate representation produced by the GCCcompiler to represent programs written in C, C++, Objective C,Fortran, Java, and Ada. GIMPLE instrumentation allows defininga common monitoring implementation for all programming lan-guages supported by the GCC compiler. For example, instead ofhaving a specific compiler for every aspect-oriented program-ming language that tries to match join points for monitoringpurposes depending on source code or bytecode, the matchingand the weaving are done on GIMPLE trees without focusing onspecific source code or bytecode.
– GCC is a well-developed and -tested multi-platform compiler. Itcan cross compile code for various hardware chips and operatingsystems.
– GIMPLE has a structured grammar (Rough, 2012). With GCC’sinternal APIs, it is easy to manipulate the GIMPLE representation(GNU, 2012).
– GIMPLE three-address code provides a common infrastructurefor control flow and dataflow analysis and optimization. Togetherwith its associated APIs, GIMPLE helps provide a platform notonly for the development of high-level code-optimization tech-niques, but also for new static-analysis tools, applicable to all ofGCC’s input languages.
– The existing optimization techniques can apply to the instru-mented code, resulting in efficient executable file. Optimizationof the instrumented program is crucial to dynamic analysis. For
sounder analysis results, the instrumented program is usuallyexecuted as many times as needed to explore different executionpaths of the program. Therefore, a better optimized program canreduce analysis time.
tems a
–
–
wtiRidtmtwPrlmMowiafiwnt(fiAmseciamps
8
t
8
iesSoew
D. Alhadidi et al. / The Journal of Sys
GIMPLE weaving allows efficient aspect interactions detection, asexplained in Section 5.2. If we do not depend on GIMPLE, we needto define a separate base facts generator for each programminglanguage and a separate CT generator for each aspect-orientedlanguage.
GIMPLE weaving can deal with many security hardening trans-formations that are language-dependent. These transformationscan be written using SHL using the same language of the sourcecode. Both the source code and the transformations are trans-formed to GIMPLE to be weaved together to produce the securecode.
We evaluate the scalability and the usability of our approachith gzip version 1.2.4. We enable code instrumentation targeting
he standard C library functions for memory management. The codenstrumentation is performed successfully and without difficulties.egarding overhead, compile-time performance is generally worse
n aspect weavers than in their traditional compiler counterpartsue to the additional work necessary for picking out joint pointshat match the specified pointcuts. Since bytecode weaving is the
ost comparable approach to GIMPLE weaving, it is reasonableo conduct a comparison between bytecode weaving and GIMPLEeaving from a performance perspective. We can say that GIM-
LE weaving outperforms the bytecode weaving for the followingeasons: Bytecode representation needs more instructions per oneine in the source code (Vasseur and Dahlstedt, 2012). This means
ore time is needed to pick out the required points in a program.ost AOP frameworks and AOP-applied products have some sort
f high-level expression language (pointcut expressions) to definehere (at which join points) a code block (advice) should be weaved
n. These expression languages can, for example, let you pick outll methods that have a return type which implements an inter-ace of type “T”. This information is not available in the bytecodenstructions representing the call to a specific method “M”. The only
ay of knowing if this specific method “M” should be weaved orot is to look it up in some sort of class database, query its returnype, and check if its return type implements the given interface “T”Vasseur and Dahlstedt, 2012). In contrast, this information is speci-ed in GIMPLE grammar and can be extracted easily by the internalPIs. GIMPLE helps provide a platform not only for the develop-ent of high-level code-optimization techniques, but also for new
tatic-analysis tools, applicable to all of GCC’s input languages. Thexisting optimization techniques can apply to the instrumentedode, resulting in an efficient executable file. Optimization of thenstrumented program is crucial to dynamic analysis. For soundernalysis results, the instrumented program is usually executed asany times as needed to explore different execution paths of the
rogram. Therefore, a better optimized program can reduce analy-is time.
. Related work
In this section, we discuss some relevant contributions relatedo the defined framework in this paper.
.1. General approaches for security injection
Application wrappers are software containers that control thenteractions between untrusted programs and their executionnvironments. Accordingly, they have been used to enhance theecurity of applications (Fraser et al., 2000; Fetzer and Xiao, 2003;
usskraut and Fetzer, 2007). Current software wrapper technol-gy revolves around interception of exported functions. Frasert al. (Fraser et al., 2000) presented techniques for developingrappers to augment security in Commercial Off-The-Self (COTS)
nd Software 86 (2013) 2654– 2674 2671
applications. This approach works well with interception at ker-nel level Application Programming Interfaces (API), which areinterfaces between applications and operating systems. HEALERS(Fetzer and Xiao, 2003) is a fault-containment wrapper that hasbeen designed to improve the security and robustness of applica-tions. For any shared C library, it can find all functions defined inthat library and automatically derive properties for those functions.Through automated fault injection experiments, it can detect argu-ments that cause the library to crash and derive safe argument typesfor each function. The toolkit can prevent heap and stack bufferoverflows that are a common cause of security breaches. HEAL-ERS can protect existing applications without access to the sourcecode. Susskraut and Fetzer (Susskraut and Fetzer, 2007) have pro-posed a novel approach to harden software libraries to improvetheir robustness and security. Their approach, which is automated,general, and extensible, consists of the following stages: First, theyhave used a static analysis to prepare and guide the following faultinjection. In the dynamic analysis stage, fault injection experimentsexecute the library functions with both usual and extreme inputvalues. The experiments are used to derive and verify one protec-tion hypothesis per function. In the hardening stage, a protectionwrapper is generated from these hypothesis to reject unrobustinput values of library functions. In some cases, aspects take theform of method wrappers (Baker and Hsieh, 2002), which allowaspect code to be inserted around method bodies like advice inAspectJ.
Welch and Stroud (Welch and Stroud, 2002; Welch and Lu,2006) have proposed an approach using Kava, which is a portablereflective Java implementation for enforcing security policies oncompiled code. Kava binds Java classes to metaobject classes atloadtime. Kava does not require the source code of the target classand this makes it suitable for use with compiled code such as mobilecode, compiled programs, or software components. The metaobjectapproach traps invocations sent from an object and specify beforeand after behavior that invokes required security mechanisms.
Type-qualifier inference is a static analysis that can be used tostatically find many classes of bugs. Type qualifiers (Shankar et al.,2001; Zhang et al., 2002; Fraser and Petroni, 2006) are used toperform taint analysis, which finds security vulnerabilities such asSQL injection and format string vulnerabilities. Fraser and Petroni(Fraser and Petroni, 2006) used type qualifiers to check the autho-rization properties in C programs. This involves introducing typequalifiers for arguments to sensitive operations, and the systemchecks these properties using type qualifier inference. They havedemonstrated their work over large code bases such as the MINIXkernels. However, their approach assumes that there are variablesthat are common to sensitive operations and security checks; inseveral instances in Java code base this assumption does not hold.
A security pattern describes a particular recurring security prob-lem that arises in a specific context and presents a well-provengeneric scheme for a security solution. The current research in thedomain of security patterns is characterized by various publications(Braga et al., 1999; Brown and DeVietri, 1999). However, there isno core reference in this area because most of these contributionstarget specific domains.
Several other tools, such as PoET/PSLang (Erlingsson, 2004)and Polymer (Bauer et al., 2005) follow an aspect-orientedapproach to enforce authorization policies on legacy code. Inall these tools, a security analyst provides a description oflocations to be protected (join points) as well as the policycheck at each location (advice). These tools then weave callsto a reference monitor at each of these locations. However,
when legacy servers manage their own resources, identify-ing locations where policy checks must be weaved becomesa challenge. By adopting an aspect-oriented approach at thedesign level, Montrieux et al. (Montrieux et al., 2010) specified
2 tems a
s(oA
8
egtW
gTpcotwattt
ecaimatJegoarprt
dcTtnMtfowi
oJpiIaoawIwi
672 D. Alhadidi et al. / The Journal of Sys
ecurity hardening solutions using Aspect-oriented ModelingAOM). The secure code is generated afterward by producing eithernly Java code, or Java code for the functional model as well asspectJ code for enforcing the security solutions.
.2. AOP approaches for security injection
Most of the contributions (Bodkin, 2013; DeWin, 2004; Huangt al., 2013; Shah, 2003) that explore the usability of AOP for inte-rating security code into applications are presented as case studieshat show the relevance of AOP languages for application security.
e present in the following an overview of these contributions.Cigital labs proposed an aspect-oriented extension to the C pro-
ramming language called CSAW (Shah, 2003; Viega et al., 2001).heir work is primarily dedicated to improving the security of Crograms. They presented typical aspects that defend against spe-ific types of attacks and addressed local problems such as bufferverflow and data logging. By means of an example of access con-rol, DeWin (DeWin, 2004) investigated how well AOP could dealith the separation of security from an application. They suggested
bstraction of the relevant pointcuts out of the aspect implemen-ation in order to construct a more generic solution. Additionally,he feasibility of building a security aspect framework has beenouched upon.
Bodkin (Bodkin, 2013) surveyed the security requirements fornterprise applications and described examples of security cross-utting concerns. His main focus has been on authentication anduthorization. He discussed cases and scenarios for these securityssues and he explored how their security rules could be imple-
ented using AspectJ. He also outlined several of the problemsnd opportunities in applying aspects to secure web applicationshat are written in Java. Another contribution in AOP security is theava Security Aspect Library (JSAL), in which Huang et al. (Huangt al., 2013) introduced and implemented in AspectJ a reusable andeneric aspect library that provides security functions. It is basedn the Java Cryptography Extension (JCE) and Java Authenticationnd Authorization Service (JAAS) packages. To make their aspectseusable, they left the responsibility to specify and implement theointcut to the programmer. This approach targets defining secu-ity libraries that can be used with Java code in particular. Its goal iso prove the feasibility of reusing and integrating pre-built aspects.
Slowikowski and Zielinski (Slowikowski and Zielinski, 2003)iscussed security solutions based on J2EE architecture, JBoss appli-ation server, JAAS, and Resource Access Decision Facility (RAD).hese solutions are implemented in AspectJ. They explored inheir paper how the code of the aforementioned security tech-ologies could be injected and woven in the original application.asuhara and Kawauchi (Masuhara and Kawauchi, 2003) defined
he dataflow pointcut but have not provided a formal frameworkor this pointcut. The pointcut identifies join points based on therigins of values using dataflow tags and picks out many famouseb application vulnerabilities such as cross-site scripting and SQL
njection.JBoss (Community Driven Open Source Middleware, 2012) is
ne of the most popular Java application servers in the industry.Boss includes full support for J2EE-based APIs, but, beyond that, itrovides many new and novel features for enterprise development,
ncluding a powerful framework for aspect-oriented programming.n JBoss, simple Java objects can leverage features such as trans-ctions and security that are usually reserved for J2EE (e.g., EJB)bjects. These features are provided as a collection of predefinedspects, and can be applied to application objects via dynamic
eaving without requiring the application itself to be recompiled.
n other words, the JBoss AOP framework allows developers torite plain Java objects and apply enterprise-type services later
n the development cycle without changing a line of Java code.
nd Software 86 (2013) 2654– 2674
JBoss AOP framework allows software developers to build, apply,and deploy aspects into their applications. The set of aspects thatcome with JBoss are aspects for remoteness, acidity, transactions,security, asynchronous invocations, and replicated/transactionalcaching. Spring AOP (SpringSource.org, 2009) introduces a simpleand powerful way of writing custom aspects using either a schema-based approach or the AspectJ annotation style. Both of these stylesoffer fully typed advice and use of the AspectJ pointcut language,while still using Spring AOP for weaving. Spring AOP currently sup-ports only method execution join points (advising the execution ofmethods on Spring beans). Field interception is not implemented,although support for field interception could be added withoutbreaking the core Spring AOP APIs. The AspectBench Compiler forAspect (abc) (Avgustinov et al., 2005) is an alternative compilerfor the AspectJ language. It is set up as a compiler frameworkthat allows for extensions, thus aiming to facilitate the implemen-tation of experimental language features. The project focuses onextending the AspectJ language, as well as providing optimizedimplementations of the language. In addition, it works by weavingon JIMPLE, which is a 3-address intermediate representation of Javaprograms. Moreover, the JIMPLE representation is typed and stack-less code. As compared to our approach, JBoss AOP, Spring AOP, andabc do not try to address multiple target languages or platforms.
Aspicere2 (Aspicere2, 2009) is an aspect language for C whereadvice code is written in normal C. Its pointcut language is basedon Prolog and can pick out call, execution, and local continua-tion join points. Aspicere2 weaver is based on Low-Level VirtualMachine (LLVM), which is very similar to GIMPLE, but GCC cangenerate code for far more targets than can LLVM. Padayacheeand Eloff (Padayachee and Eloff, 2007) demonstrated that aspect-orientation may be used to monitor the information flows betweenobjects in a system for the purposes of misuse detection. Misusedetection involves identifying behavior that is close to some pre-viously defined pattern signature of a known intrusion. Jones andHamlen (Jones and Hamlen, 2010) demonstrated that restrictingaspectual policy specifications to purely declarative (but stateful)advice, and strengthening the pointcut language to include declar-ative predicates over runtime values, improves the feasibility ofaspectual policy analysis yet remains expressive enough to encodelarge classes of important security properties. Such policies can beeffectively enforced as in-lined reference monitors that target onlyJava bytecode binaries.
8.3. Semantics for AOP weaving
The related work that addresses AOP weaving semantics is pre-sented in this subsection. None of these works defined a semanticsthat demonstrates how to weave in GIMPLE trees. There has beena contribution by Adam (Adam, 2005) attempting AOP for GIMPLErepresentation. The contribution in this paper over Adam’s work isa new general aspect-oriented language together with the formalsemantics for advice weaving in GIMPLE trees. The most prominentresearch proposals in this area are the contribution of Walker et al.(Walker et al., 2003), wherein the authors defined the semantics ofMinAML, an aspect-oriented language, and the contribution of Dan-tas et al. (Dantas et al., 2005) wherein the authors defined PolyAML,a typed functional, aspect-oriented language. They used labels tomark points where advice pieces were to be injected. Advice piecesare applied to the argument or to the result of a function.
Masuhara et al. (Masuhara et al., 2005) implemented an aspect-oriented version of core O’Caml called Aspectual Caml. AspectualCaml carries out type inference on advice pieces without consulting
the types of the functions designated by the pointcuts. In addition,there are no formal definitions for Aspectual Caml.
Wand et al. (Wand et al., 2004) presented a denotational seman-tics for pointcuts and advice pieces of an AOP language defined
tems a
ilia
ttt
wlaigs
buik
tMowfaef
9
bhshtPwapbhiatKoaaimarobpnataaao
D. Alhadidi et al. / The Journal of Sys
n the Aspect Sand Box (ASB) project (Dutchyn et al., 2002). Theanguage is untyped. The language of the pointcuts includes des-gnators for procedure calls and control flows, but not for variableccess or update.
Wang et al. (Wang et al., 2006) provided seamless integra-ion of the AOP paradigm and strongly-typed functional languageshrough a static weaving process that deals with advice pieces andype-scoped pointcuts in the presence of higher-order functions.
It is noticeable that all the previous contributions target AOPith functional programming. As a new idea, a name-based calcu-
us �ABC (Bruns et al., 2004) has been introduced in which aspectsre the primitive computational entity. The authors demonstratedts expressiveness by presenting encodings of various other lan-uages into �ABC. In �ABC, computational events are messagesent from a source to a target.
Belblidia and Debbabi (Belblidia and Debbabi, 2006) scrutinizedoth the source code of programs and the corresponding compilednits in AspectJ in order to determine how the basic primitives were
nterpreted by the compiler. As a second step, they transformed thisnowledge into formal semantics.
Jürjens (Jürjens, 2005) aimed to develop security-critical sys-ems in a formally-based approach using the notation of the Unified
odeling Language (UML). He presented the extension UMLsecf UML that allows one to express security-relevant informationithin the diagrams in a system specification. UMLsec is defined in
orm of a UML profile using the standard UML extension mech-nisms. In particular, the associated constraints give criteria tovaluate the security aspects of a system design by referring toormal semantics of a simplified fragment of UML.
. Conclusion
We have presented in this paper an aspect-oriented approachased on GIMPLE for the systemization of application securityardening. The security solutions are woven into GIMPLE repre-entations in a systematic way, eliminating the need for manualardening that may generate a considerable number of errors. Inhis respect, we have presented a formal specification for GIM-LE weaving and the implementation strategies of the proposedeaving semantics. To achieve this goal, syntax for a common
spect-oriented language that is abstract and multi-language sup-ort together with syntax for a core set for GIMPLE constructs haveeen presented to express the weaving semantics. Afterward, weave handled the correctness and completeness of GIMPLE weaving
n two different ways. In the first approach, we have proved themccording to the rules and algorithms provided in this paper. Onhe other hand, we have accommodated in the second approachniesel’s discipline to explore the correctness and completenessf GIMPLE weaving. At the end, we have explored the viabilitynd the relevance of our propositions by applying the definedpproach for systematic security hardening to develop case stud-es. The main advantage of the defined solution is that it supports
ultiple languages. GIMPLE weaving accompanied by a commonspect-oriented language allows security experts providing secu-ity solutions using this common language, lets developers focusn the main functionality of programs by relieving them from theurden of security issues, unifies the matching and the weavingrocesses for mainstream languages, and facilitates introducingew security features in AOP languages. Regarding future work, were currently working on extending the GIMPLE weaving seman-ics to include other defined constructs, such as the cflow pointcut,
nd their implementation into GCC. Moreover, we are focused onpplying this approach using other programming languages suchs Java to prove the multi-language support claim. GIMPLE is notbject-oriented, thus object-oriented features are transformed to
nd Software 86 (2013) 2654– 2674 2673
imperative equivalents during the translation to GIMPLE. There isa need to understand all these transformations to identify all thenew possible pointcuts that can pick out points related to theseobject-oriented features.
References
Adam, B., 2005. Language-independent aspect weaving. In: Generative and Trans-formational Techniques in Software Engineering, GTTSE 2005, InternationalSummer School.
Alhadidi, D., Belblidia, N., Debbabi, M., 2006. Security crosscutting concerns andAspectJ. In: Proceedings of the International Conference on Privacy, Securityand Trust, McGraw-Hill, Markham, Ontario, Canada.
Alhadidi, D., Debbabi, M., Bhattacharya, P., 2008. New AspectJ pointcuts for inte-ger overflow and underflow detection. Information Security Journal: A GlobalPerspective 17 (5&6), 278–287.
ANTLR Parser Generator. Available at http://www.antlr.org/ (accessed in December2012).
Aspicere2, more AOP for C. Available at http://users.ugent.be/badams/aspicere2/(accessed in February 2009).
Avgustinov, P., Christensen, A., Hendren, L., Kuzins, S., Lhoták, J., Lhoták, O., de Moor,O., Sereni, D., Sittampalam, G., Tibble, J., 2005. abc: an extensible AspectJ com-piler. In: Proceedings of the 4th International Conference on Aspect-orientedSoftware Development, AOSD ’05, ACM, pp. 87–98.
Böllert, K., 1999. On weaving aspects. In: Proceedings of the Workshop on Object-Oriented Technology, Springer-Verlag, pp. 301–302.
Baker, J., Hsieh, W., 2002. Runtime aspect weaving through metaprogramming. In:Proceedings of the 1st International Conference on Aspect-oriented SoftwareDevelopment, AOSD’02, ACM, pp. 86–95.
Bauer, L., Ligatti, J., Walker, D., 2005. Composing security policies with polymer.SIGPLAN Notices 40 (6), 305–314.
Belblidia, N., Debbabi, M., 2006. Formalizing AspectJ weaving for static pointcuts.In: Proceedings of the Fourth IEEE International Conference on Software Engi-neering and Formal Methods, IEEE, pp. 50–59.
Bell Canada. Available at http://bell.ca/home/ (accessed in June 2009).Bishop, M., 2002. Computer Security: Art and Science. Addison-Wesley Professional.Bishop, M., 2005. How Attackers Break Programs, and How to Write More
Secure Programs. Available at http://nob.cs.ucdavis.edu/bishop/secprog/sans2002/index.html (accessed in November 2011).
Bodkin, R. Enterprise Security Aspects. http://www.cs.kuleuven.ac.be/distrinet/events/aosdsec/AOSDSEC04 Ron Bodkin.pdf
Braga, A.M., Dahab, C.M.F.R., Tropyc, R., 1999. A pattern language for cryprographicsoftware. In: Tech. Rep. IC-99-03, Institute of Computing, UNICAMP.
Brown, F.L., DeVietri, J.G.D.E.B.F., 1999. The authenticator pattern. In: Proceedingsof Pattern Language of Programs (PloP’99), Chicago, IL, USA.
Bruns, G., Jagadeesan, R., Jeffrey, A., Riely, J., 2004. muABC: a minimal aspect calculus.In: Proceedings of the Fifteenth International Conference on Concurrency Theory(CONCUR 2004). Lecture Notes in Computer Science, vol. 3170, Springer-Verlaghttp://cm.bell-labs.com/who/ajeffrey/papers/concur04.pdf
Callanan, S., Grosu, R., Huang, X., Smolka, S.A., Zadok, E., 2006. Compiler-assisted soft-ware verification using plug-ins. In: Proceedings of the Conference on Paralleland Distributed Processing, IPDPS’06, IEEE, p. 285.
CERT C Secure Coding Standard. Available at http://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard (accessed inDecember 2012).
CERT C++Secure Coding Standard. Available at http://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637 (accessed in December 2012).
Coady, Y., Kiczales, G., Feeley, M., Smolyn, G., 2001. Using AspectC to improvethe modularity of path-specific customization in operating system code. In:Proceedings of the 8th European Software Engineering Conference held jointlywith 9th ACM SIGSOFT International Symposium on Foundations of SoftwareEngineering, ESEC/FSE-9, ACM, pp. 88–98.
Community Driven Open Source Middleware. Available at http://www.jboss.org/(accessed in December 2012).
ConTraCT. Available at http://roots.iai.uni-bonn.de/research/contract/ (accessed inDecember 2012).
Dantas, D.S., Walker, D., Washburn, G., Weirich, S., 2005. Polyaml: a polymorphicaspect-oriented functional programming language. In: Proceedings of the TenthACM SIGPLAN International Conference on Functional Programming, ICFP ’05,ACM, pp. 306–319.
Dutchyn, C., Kiczales, G., Masuhara, H., 2002. Aspect Sand Box Project. Available athttp://www.cs.ubc.ca/labs/spl/projects/asb.html (accessed in November 2008).
Erlingsson, U., 2004. The inlined reference monitor approach to security policyenforcement. Cornell University, Ithaca, NY, USA, Ph.D. thesis.
Fetzer, C., Xiao, Z., 2003. HEALERS: a toolkit for enhancing the robustness and secu-
rity of existing applications. International Conference on Dependable Systemsand Networks 0 317.
Fraser, T., Petroni, N.J.W.A., 2006. Applying flow-sensitive CQUAL to verify MINIXauthorization check placement. In: Proceedings of the 2006 Workshop on Pro-gramming Languages and Analysis for Security, ACM, pp. 3–6.
raser, T., Badger, L., Feldman, M., 2000. Hardening COTS software with generic soft-ware wrappers. DARPA Information Survivability Conference and Exposition 2,1323.
CC—the GNU Compiler Collection. Available at http://gcc.gnu.org/ (accessed in June2009).
NU Compiler Collection (GCC) Internals. Available at http://idlebox.net/2011/apidocs/gcc-4.6.0.zip/gccint-4.6.0/gccint 12.html (accessed in December2012).
arbulot, B., Gurd, J.R., 2006. A join point for loops in AspectJ. In: AOSD ’06:Proceedings of the 5th International Conference on Aspect-oriented SoftwareDevelopment, ACM, New York, NY, USA, pp. 63–74.
oward, M., LeBlanc, D.E., 2002. Writing Secure Code. Microsoft, Redmond, WA, USA.uang, M., Wang, C., Zhang, L., 2013. Toward a Reusable and Generic
ürjens, J., 2005. Model-based security engineering with UML: introducing securityaspects. In: de Boer, F.S., Bonsangue, M.M., Graf, S., de Roever, W.P. (Eds.), For-mal Methods for Components and Objects, 4th International Symposium, FMCO.Lecture Notes in Computer Science, vol. 4111. Springer-Verlag, pp. 64–87.
ones, M., Hamlen, K.W., 2010. Disambiguating aspect-oriented security policies.In: Proceedings of the International Conference on Aspect-Oriented SoftwareDevelopment, AOSD’10, ACM, pp. 193–204.
Transformer Framework. Available at http://roots.iai.uni-bonn.de/research/jtransformer/ (accessed in February 2009).
iczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J.M.,Irwin, J., 1997. Aspect-oriented programming. In: Aks it, M., Matsuoka, S. (Eds.),Proceedings European Conference on Object-Oriented Programming, vol. 1241.Springer-Verlag, Berlin, Heidelberg, New York, pp. 220–242.
iczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G., 2001. Anoverview of AspectJ. In: Proceedings of the 15th European Conference on Object-Oriented Programming, ECOOP’01, Springer-Verlag, pp. 327–353.
im, H., 2002. An AOSD implementation for C#. In: Tech. Re TCD-CS2002-55, Depart-ment of Computer Science, Trinity College, Dublin.
niesel, G., Koch, H., 2004. Static composition of refactorings. Science of ComputerProgramming 52 (1–3), 9–51.
niesel, G., 2006. A logic foundation for conditional program transformations. In:Tech. Re IAI-TR-2006-01, CS Dept. III, University of Bonn, Germany.
niesel, G., 2009. Detection and resolution of weaving interactions. Transactions onAspect-Oriented Software Development 5, 135–186.
öding, H., Peleska, J., 2008. Symbolic and abstract interpretation for C/C++programs.Electronic Notes Theoretical Computer Science 217, 113–131.
achata, P., 2007. Construction of GNU Compiler Collection Front End. Availableat http://www.feec.vutbr.cz/EEICT/2007/sbornik/02-magisterske projekty/07-informacni systemy/09-pmachata.pdf (accessed in November 2012).
arpons, G., Marino, J., Polo, A., 2008. Adding coding rule checking capabilities tothe GCC toolchain. In: Hutton, A., Ross, C., Lockhart, J. (Eds.), Proceedings of theGCC Developers’ Summit 2008. Ottawa, Canada, June 17–19 2008, pp. 43–54.
asuhara, H., Kawauchi, K., 2003. Dataflow pointcut in aspect-oriented pro-gramming. In: Ohori, A. (Ed.), Programming Languages and Systems, FirstAsian Symposium, APLAS 2003. Lecture Notes in Computer Science, vol. 2895.Springer-Verlag, Beijing, China, pp. 105–121.
asuhara, H., Kiczales, G., Dutchyn, C., 2003. A compilation and optimization modelfor aspect-oriented programs. In: Hedin, G. (Ed.), Compiler Construction, CC2003, Held as Part of the Joint European Conferences on Theory and Practice ofSoftware, ETAPS 2003. Lecture Notes in Computer Science, vol. 2622. Springer-Verlag, Warsaw, Poland, pp. 46–60.
asuhara, H., Tatsuzawa, H., Yonezawa, A., 2005. Aspectual Caml: an aspect-oriented functional language. In: ICFP05: Proceedings of the Tenth ACM SIGPLANInternational Conference on Functional Programming, ACM.
ontrieux, L., Jürjens, J., Haley, Ch.B., Yu, Y., Schobbens, P., Toussaint, H., 2010. Toolsupport for code generation from a UMLsec property. In: Proceedings of theInternational Conference on Automated Software Engineering, ASE’10, ACM, pp.357–358.
ourad, A., Laverdière, M.A., Debbabi, M., 2006. Security hardening of open sourcesoftware. In: Proceedings of the 2006 International Conference on Privacy, Secu-rity and Trust (PST 2006), McGraw-Hill/ACM.
ourad, A., Laverdière, M.A., Debbabi, M., 2007a. A high-level aspect-orientedbased language for software security hardening. In: Proceedings of theInternational Conference on Security and Cryptography (Secrypt), Barcelona,Spain.
ourad, A., Laverdiere, M.A., Debbabi, M., 2007b. Towards an aspect orientedapproach for the security hardening of code. In: Proceedings of the 21st Inter-national Conference on Advanced Information Networking and ApplicationsWorkshops, AINAW’07, IEEE, pp. 595–600.
Caml for Scientists. Available at http://www.ffconsultancy.com/products/ocaml forscientists/chapter1.html (accessed in December 2012).
adayachee, K., Eloff, J.H.P., 2007. An aspect-oriented model to monitor misuse. In:Proceedings of Innovations and Advanced Techniques in Computer and Informa-tion Sciences and Engineering, AINAW’07, Springer, Netherlands, pp. 273–278.
ho, T., Kniesel, G., 2004. Uniform genericity for aspect languages. In: Tech. Re IAI-TR-2004-4, CS Dept. III, University of Bonn, Germany.
ough GIMPLE Grammar – GNU Compiler Collection. Available athttp://gcc.gnu.org/onlinedocs/gcc-4.3.2/gccint/Rough-GIMPLE-Grammar.html(accessed in December 2012).
chumacher, M., 2003. Security Engineering with Patterns: Origins, TheoreticalModels, and New Applications. Springer.
nd Software 86 (2013) 2654– 2674
Seacord, R.C., 2005. Secure Coding in C and C++. SEI Series. Addison-Wesley.Shah, V., 2003. An aspect-oriented security assurance solution. In: Tech. Re AFRL-IF-
RS-TR-2003-254, Cigital Labs.Shankar, U., Talwar, K., Foster, J.S., Wagner, D., 2001. Detecting format string vul-
nerabilities with type qualifiers. In: Proceedings of the 10th Conference onUSENIX Security Symposium, SSYM’01, USENIX Association, Berkeley, CA, USA,p. 16.
Slowikowski, P., Zielinski, K., 2003. Comparison study of aspect-oriented and con-tainer managed security. In: Proceedings of the ECCOP Workshop on Analysis ofAspect-Oriented Software.
Spinczyk, O., Gal, A., Schröder-Preikschat, W., 2002. AspectC++: An aspect-orientedextension to the C++programming language. In: Proceedings of the FortiethInternational Conference on Tools Pacific, CRPIT’02, ACM, pp. 53–60.
SpringSource.org. Available at http://www.springsource.org/ (accessed in February2009).
Susskraut, M., Fetzer, C., 2007. Robustness and security hardening of COTS softwarelibraries. In: Proceedings of the 37th Annual IEEE/IFIP International Conferenceon Dependable Systems and Networks, IEEE, pp. 61–71.
The CERT Sun Microsystems Secure Coding Standard for Java. Available athttp://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java (accessed in December 2009).
US Department of Homeland Security Coding Rules. Available athttp://buildsecurityin.us-cert.gov/daisy/bsi-rules/home.html (accessed inSeptember 2009).
Vasseur, A., Dahlstedt, J. BEA Systems: Java Virtual Machine Support forAspect-Oriented Programming. http://jonasboner.com/publications/JVMAOP AOSD2006.pdf (accessed in November 2012).
Viega, J., Bloch, J., Chandra, P., 2001. Applying aspect-oriented programming to secu-rity. Cutter IT Journal 14 (2), 31–39.
Walker, D., Zdancewic, S., Ligatti, J., 2003. A theory of aspects. In: Proceedings ofthe Eighth ACM SIGPLAN International Conference on Functional Programming,ICFP’03, ACM, pp. 127–139.
Wand, M., Kiczales, G., Dutchyn, C., 2004. A semantics for advice and dynamic joinpoints in aspect-oriented programming. ACM Transactions on ProgrammingLanguages and Systems 26 (5), 890–910.
Wang, M., Chen, K., Khoo, S.C., 2006. Type-directed weaving of aspects forhigher-order functional languages. In: Proceedings of the 2006 ACM SIGPLANSymposium on Partial Evaluation and Semantics-based Program Manipulation,PEPM’06, ACM, pp. 78–87.
Welch, I., Lu, F., 2006. Policy-driven reflective enforcement of security policies. In:Proceedings of the 2006 ACM Symposium on Applied Computing, ACM, pp.1580–1584.
Welch, I., Stroud, R.J., 2002. Using reflection as a mechanism for enforcingsecurity policies on compiled code. Journal of Computer Security 10 (4),399–432.
Yang, Z., 2007. On Building A Dynamic Vulnerability Detection System. ConcordiaUniversity, Master’s thesis.
Zhang, X., Edwards, A., Jaeger, T., 2002. Using CQUAL for static analysis of authoriza-tion hook placement. In: Proceedings of the 11th USENIX Security Symposium,USENIX Association, Berkeley, CA, USA, pp. 33–48.
Dima Alhadidi received the Ph.D. degree in computer science and software engi-neering from Concordia University, Canada.She is currently a Research Associateat Concordia University. Her research interests include computer security, aspect-oriented programming, software engineering, secure distributed computing andcloud computing.
Azzam Mourad is an Aassistant Professor in the department of computer scienceand mathematics at the Lebanese American University (LAU). He holds Ph.D. degreein electrical and computer engineering from Concordia University, Canada and M.Sc.degree in computer science from Laval University, Canada. The main topics of his cur-rent research activities are web services security, web services engineering, cloudcomputing, aspect-oriented programming, ad-hoc network security, informationsecurity, software security and security engineering. Dr. Mourad is currently servingas a program chair, a TPC member and a reviewer of several international confer-ences and journals. In the past, he served as a Postdoctoral fellow at ConcordiaUniversity.
Hakim Idrissi Kaitouni is a Key Account Manager at Omnidata. In the past, hewas an IT security consultant at Deloitte & Touche. He holds a Master in Informa-tion Systems Security and a Bachelor in Electrical Engineering with an option inTelecommunications from Concordia University.
Mourad Debbabi received the Ph.D. and M.Sc. degrees in computer science fromParis-XI Orsay, University, France. He is currently a Full Professor and the Presidentof the National Cyber Forensics Training Alliance (NCFTA Canada). He holds the Con-cordia Research Chair Tier I in Information Systems Security. He is the founder andone of the leaders of the Computer Security Laboratory (CSL) at Concordia Univer-sity. In the past, he served as Senior Scientist at the Panasonic Information andNetwork Technologies Laboratory, Princeton, New Jersey, USA; Associate Professorat the Computer Science Department of Laval University, Quebec, Canada; Senior Sci-entist at General Electric Research Center, New York, USA; Research Associate at the
Computer Science Department of Stanford University, California, USA; and Perma-nent Researcher at the Bull Corporate Research Center, Paris, France. He publishedmore than 170 research papers in journals and conferences on computer security,digital forensics, Java security, cryptographic protocols, malicious code detectionand network security.
