TOWARDS LANGUAGE-INDEPENDENT APPROACH FOR

SECURITY CONCERNS WEAVING

Azzam Mourad, Dima Alhadidi and Mourad Debbabi

Computer Security Laboratory

Concordia Institute for Information Systems Engineering

Concordia University, Montreal (QC), Canada

Keywords:

Software Security, Aspect-Oriented Programming (AOP), AOP Weaving, Gimple Representation.

Abstract:

In this paper, we propose an approach for weaving security concerns in the Gimple representation of pro-

grams. Gimple is an intermediate, language-independent, and tree-based representation generated by GNU

Compiler Collection (GCC) during the compilation process. This proposition constitutes the ﬁrst attempt to-

wards adopting the aspect-oriented concept on Gimple and exploiting this intermediate representation to allow

advising an application written in a speciﬁc language with security code written in a different one. At the

same time, injecting security is applied in a systematic way in order not to alter the original functionalities

of the software. We explore the viability and the relevance of our proposition by: (1) implementing several

Gimple weaving capabilities into the GCC compiler (2) developing a case study for securing the connections

of a client application and (3) using the weaving features of the extended GCC to inject the security concerns

into the application.

1 INTRODUCTION

Security is taking an increasingly predominant role in

today’s computing world. The industry is facing chal-

lenges in public conﬁdence at the discovery of vulner-

abilities, and customers are expecting security to be

delivered out of the box, even on programs that have

not been designed with security in mind. The chal-

lenge is even greater when legacy systems must be

adapted to networked/web environments, while they

are not originally designed to ﬁt into such high-risk

environments. As a result, integrating security into

software becomes a very challenging and interesting

domain of research.

On the other hand, securing software is a difﬁ-

cult and a critical procedure. If it is applied man-

ually, it requires high security expertise and lot of

time to be tackled. It may also create other vulner-

abilities. One way of addressing such problems is

∗

This research is the result of a fruitful collaboration

between CSL (Computer Security Laboratory) of Concor-

dia University, DRDC (Defense Research and Develop-

ment Canada) Valcartier and Bell Canada under the NSERC

DND Research Partnership Program.

by separating out the security concerns from the rest

of the application, such that they can be addressed

independently and applied globally. More recently,

several proposals have been advanced for code injec-

tion, via an aspect-oriented computational style, into

source code for the purpose of improving its security

(Bodkin, 2004; DeWin, 2004; Huang et al., 2004;

Shah, 2003). Aspect-Oriented Programming (AOP)

is an appealing approach that allows the separation

of crosscutting concerns. This paradigm seems to

be very promising to integrate security into software.

The process of merging the security concerns into the

original program is called weaving. In this context,

we have presented previously in (Mourad et al., 2007;

Mourad et al., 2008) contributions towards elaborat-

ing methodologies and solutions to integrate system-

atically and consistently security models and compo-

nents into software.

In this paper, we have built on top of them and

introduced an AOP weaving approach for inject-

ing security concerns in the Gimple representation

of programs. Gimple is an intermediate, language-

independent, and tree-based representation generated

by GNU Compiler Collection (GCC) during the com-

460

Mourad A., Alhadidi D. and Debbabi M. (2008).

TOWARDS LANGUAGE-INDEPENDENT APPROACH FOR SECURITY CONCERNS WEAVING.

In Proceedings of the International Conference on Security and Cryptography, pages 460-465

DOI: 10.5220/0001925704600465

 SciTePress

pilation process. Our new proposition constitutes of

developing AOP weaving capabilities for Gimple to

be integrated into the GCC compiler. These features

allow to compile security concerns and inject them

into the Gimple tree of a program during the GCC

compilation procedures. Beside, this approach is

the ﬁrst attempt towards adopting the aspect-oriented

concept on Gimple and exploiting this intermediate

representation to allow advising an application writ-

ten in a speciﬁc language with security code written

in a different one.

The remainder of this paper is organized as fol-

lows. In Section 2, we review the contributions in the

ﬁeld of AOP and AOP for securing software. After-

wards, in Section 3, we describe the new approach

where weaving is performed on the Gimple represen-

tation of a software by adopting the aspect-oriented

style. In Section 4, we present the experimental re-

sults of developing a case study for securing the con-

nections of a client application and using the weaving

features implemented in the extended GCC for inject-

ing the required security concerns. Finally, we offer

concluding remarks in Section 5.

2 BACKGROUND AND RELATED

WORK

The proposed approach is based on AOP and target

security concerns. As such, we present in the sequel

a brief summary on AOP and an overview on the ap-

proaches related to the contribution of this paper.

2.1 Aspect-oriented Programming

AOP depends on the principle of "Separation of Con-

cerns", where issues that crosscut the application are

addressed separately and encapsulated within aspects.

There are many AOP languages that have been de-

veloped which are programminglanguage-dependent.

AspectJ (Kiczales et al., 2001) built on top of the Java

programming language and AspectC++ (Spinczyk

et al., 2002) built on top of the C++ programming

language are the most prominent ones. The approach,

which is adopted by most of the AOP languages, is

called the pointcut-advice model. The fundamental

concepts of this model are: join points, pointcuts, and

advices.

Each atomic unit of code to be injected is called

an advice. It is necessary to formulate where to inject

the advice into the program. This is done by the use of

a pointcut expression, which its matching criteria re-

stricts the set of the join points of a program for which

the advice will be injected. A join point is a princi-

pled point in the execution of a program. At the heart

of this model, is the concept of an aspect, which em-

bodies all these elements. Finally, the aspect is com-

posed and merged with the core functionality modules

into one single program. This process of merging and

composition is called weaving, and the tools that per-

form such process are called weavers.

2.2 AOP Approaches for Security

Injection

Most of the contributions (Bodkin, 2004; DeWin,

2004; Huang et al., 2004; Shah, 2003) that explore

the usability of AOP for integrating security code into

applications are presented as case studies that show

the relevance of AOP languages for application se-

curity. They have focused on exploring the useful-

ness of AOP for securing software by security experts

who know exactly where each piece of code should

be manually injected. None of them have proposed

an approach or methodology for systematic security

hardening with features similar to our proposition.

We present in the following an overview on these con-

tributions.

Cigital labs has proposed an AOP language called

CSAW (Shah, 2003), which is a small superset of C

programming language dedicated to improve the se-

curity of C programs. De Win, in his Ph.D. thesis

(DeWin, 2004), has discussed an aspect-oriented ap-

proach that allows the integration of security aspects

within applications. It uses AOP concepts to spec-

ify the behavior code to be merged in the applica-

tion and the location where this code should be in-

jected. In (Bodkin, 2004), Ron Bodkin has surveyed

the security requirements for enterprise applications

and described examples of security crosscutting con-

cerns, with a focus on authentication and authoriza-

tion. Another contribution in AOP security is the Java

Security Aspect Library (JSAL), in which Huang et

al. (Huang et al., 2004) has introduced and imple-

mented, in AspectJ, a reusable and generic aspect

library that provides security functions. Masuhara

and Kawauchi (Masuhara and Kawauchi, 2003) have

deﬁned the dataﬂow pointcut, which identiﬁes join

points based on the origin of values.

3 WEAVING METHODOLOGY

The initial proposition, which is detailed in (Mourad

et al., 2007; Mourad et al., 2008), is composed of

a framework, a language called SHL and a com-

piler for securing software in a systematic way. SHL

TOWARDS LANGUAGE-INDEPENDENT APPROACH FOR SECURITY CONCERNS WEAVING

461

Software Secured Software

Extended GCC /

Gimple Weaving

Interrupt GCC

Compile Aspect

Gimple Weaving

GCC

Compilation

Security

Gimple Trees

Software

Gimple Tree

Language-

Independent

Security Aspect

Figure 1: Approach Architecture.

is an aspect-oriented and programming-independent

language. According to the proposed methodology,

the resulting component, which is written in SHL,

is a programming-language independent aspect (also

known as pattern) for security hardening. Conse-

quently, this pattern should be reﬁned into code level

aspect before passing it to the corresponding AOP

weaver (e.g. AspectJ, AspectC++), which is then

launched to weave it with the original code.

In this paper, we have extended this approach

and built on top of it, by taking the resulting

programming-language independent aspect (i.e. pat-

tern) described using SHL and weaving its compo-

nents directly in the Gimple representation (i.e. Gim-

ple Tree) of a program. This allows to bypass the

reﬁnement of the pattern into programming-language

dependent aspect, and consequently not using the cur-

rent AOP weavers. Beside, it exploits the Gimple

intermediate representation to advise an application

written in a speciﬁc programming language with code

written in a different one. The approach architecture

is illustrated in Figure 1.

The methodology constitutes of passing the SHL

security pattern and the original software to an ex-

tended version of the GCC compiler, which gener-

ates the executable of the trusted software. An ad-

ditional pass has been added to GCC in order to inter-

rupt the compilation once the Gimple representation

of the code is completed. This pass can be called by

selecting an option when performing the compilation

(e.g. gcc -Weaving SecureConnectionPattern.shl -c

Connection.c ...). In parallel, as temporary solutions,

the components of the security pattern are translated

into special format ﬁle. Additional components have

been developed in order to parse such ﬁle, gather the

needed information (e.g. function name, return type,

etc.) and pass them as parameters to speciﬁc functions

provided by GCC and responsible of building Gimple

trees (e.g. build_decl(...)). Afterwards, the generated

security trees are integrated in the tree of the origi-

nal code (also using functions provided by GCC for

this purposes) with respect to the location(s) speciﬁed

into the pattern. Finally, the resulted Gimple tree is

passed again to GCC in order to continue the regu-

lar compilation process and produce the executable of

the secure software. The added features were origi-

nally implemented by our colleagues (Yang, 2007) in

order to insert code for monitoring. We have modiﬁed

it in order to inject security functionalities. The work

on the implementation of the weaving features is still

in progress.

4 CASE STUDY

In this section, we present a case study for securing

the connections of client applications. To demonstrate

the feasibility of our proposition , we have elaborated

ﬁrst, using SHL, the language-independent security

aspect (i.e. pattern) needed to secure the connections

of a selected client application. Then, we have re-

ﬁned the pattern into AspectC++ aspect and weaved it

into the selected application. Afterwards, we have re-

peated this process using our new proposition, where

we have compiled directly the same application and

the translated ﬁle of the pattern using the extended

GCC and applied the weaving on the Gimple repre-

sentation of the application.

4.1 Pattern and Aspect for Securing the

Connections of Client Application

We have selected a client application implemented in

C++, which allows to connect and exchange data with

a server through HTTP requests. Listing 1 presents

the pattern elaborated in SHL for securing the connec-

tion of the aforementioned application using GnuTL-

S/SSL (Please refer to (Mourad et al., 2007; Mourad

et al., 2008) for SHL structure and syntax). The code

of the functions used in the Code of the pattern’s Be-

havior(s) is illustrated in Listing 2. It is expressed in

C++ because the application is implemented in this

programming language. However, other syntax and

programming languages can also be used depending

on the abstraction required and the implementation

language of the application to harden. To generalize

our solution and make it applicable on wider range of

applications, we assume that not all the connections

are secured, since many programs have different local

interprocesscommunicationsvia sockets. In this case,

all the functions responsible of sending/receivingdata

on the secure channels are replaced by the ones pro-

vided by TLS. On the other hand, the other functions

SECRYPT 2008 - International Conference on Security and Cryptography

462

that operate on the non-secure channels are kept un-

touched. Moreover, we suppose that the connection

processes and the functions that send and receive data

are implemented in different components.

We have reﬁned and implemented (using As-

pectC++) in Listing 3 the corresponding aspect of the

pattern that is presented in Listing 1. The reader will

notice the appearance of

hardening_sockinfo_t

These are the data structures and functions that we

have developed to distinguish between secure and non

secure channels. Besides, they are used to export the

parameters between the application’s components at

runtime. In order to avoid using shared memory di-

rectly, we have opted for a hash table that uses the

socket number as a key to store and retrieve all the

needed information (in our own deﬁned data struc-

ture). One additional information that we have stored

is whether the socket is secure or not. In this manner,

all calls to a

send()

and

recv()

are modiﬁed for a

runtime check that uses the proper sending/receiving

function.

Listing 1: SHL Pattern for Securing Connection.

BeginPattern

Before

Exe c ution <main> / / S t a r t i n g Point

BeginBehavior

/ / I n i t i a l i z e the TLS l i b r a r y

I n i t i a l i z e T LS L i b r a r y ;

EndBehavior

Before

Ca ll <connect > / / TCP Connection

ExportParameter

ExportParameter

BeginBehavior

/ / I n i t i a l i z e the TLS s e s s i o n re s ou r ce s

I n i t i al i z eT L S S es s i o n ;

EndBehavior

After

Ca ll <connect >

ImportParameter

BeginBehavior

/ / Add the TLS handshake

AddTLSHandshake;

EndBehavior

Replace

Ca ll <send >

ImportParameter

BeginBehavior

/ / Change the send f u nc t i o n s us ing t h a t

/ / so c k et by t he TLS send f u n c t i o n s of the

/ / used API when using a se cured so ck e t

SSLSend ;

EndBehavior

Replace

Ca ll <rec e ive >

ImportParameter

BeginBehavior

/ / Change the r e c e i v e f u n c t i o n s us ing th a t

/ / so c k et by t he TLS r e c e i v e f u n c t i o n s of

/ / t he used API when usin g a secur e d so c k et

SSLReceive ;

EndBehavior

Before

Ca ll <clos e > / / Socket c lo s e

ImportParameter

ImportParameter

BeginBehavior

/ / Cut the TLS co nne c tio n

CloseAndDealocateT LSSession ;

EndBehavior

After

Exe c ution <main>

BeginBehavior

/ / D e i n i t ia l iz e the TLS l i br a r y

D e i n i t i a l i ze T L S L i br a r y ;

EndBehavior

EndPattern

Listing 2: Functions Used in Secure Connection Pattern.

gnutls_global_init();

InitializeTLSSession

gnutls_init (session , GNUTLS_CLIENT);

gnutls_set_default_priority (session);

gnutls_certificate_type_set_priority (session,

cert_type_priority);

gnutls_certificate_allocate_credentials(xcred);

gnutls_credentials_set (session,

GNUTLS_CRD_CERTIFICATE, xcred);

AddTLSHandshake

gnutls_transport_set_ptr(session, socket);

gnutls_handshake (session);

SSLSend

gnutls_record_send(session, data, datalength);

SSLReceive

gnutls_record_recv(session, data, datalength);

CloseAndDealocateTLSSession

gnutls_bye(session, GNUTLS_SHUT_RDWR);

gnutls_deinit(session);

gnutls_certificate_free_credentials(xcred);

DeinitializeTLSLibrary

gnutls_global_deinit();

TOWARDS LANGUAGE-INDEPENDENT APPROACH FOR SECURITY CONCERNS WEAVING

463

Listing 3: Excerpt of Aspect for Securing Connections.

aspect SecureConnection {

advice execution ("% main(...)") : around () {

Initialization of the API

...

tjp->proceed();

De-initialization of the API

...

*tjp->result() = 0;

}

advice call("% connect(...)") : around () {

//variables declared

hardening_sockinfo_t socketInfo;

const int

cert_type_priority[3] = {

GNUTLS_CRT_X509, GNUTLS_CRT_OPENPGP, 0};

//initialize TLS session info

gnutls_init (&socketInfo.session,

GNUTLS_CLIENT);

...

//Connect

tjp->proceed();

(*tjp->result()<0) {

return

;}

//Save the needed parameters and the

information that distinguishes between

secure and non-secure channels

socketInfo.isSecure = true;

socketInfo.socketDescriptor = *(

int

*)tjp->arg

(0);

hardening_storeSocketInfo(*(

int

*)tjp->arg(0),

socketInfo);

//TLS handshake

gnutls_transport_set_ptr (socketInfo.session,

(gnutls_transport_ptr) (*(

int

*)tjp->arg(0)

));

*tjp->result() = gnutls_handshake (socketInfo.

session);

}

//replacing send() by gnutls_record_send() on a

secured socket

advice call("% send(...)") : around () {

//Retrieve the needed parameters and the

information that distinguishes between

secure and non-secure channels

hardening_sockinfo_t socketInfo;

socketInfo = hardening_getSocketInfo(*(

int

tjp->arg(0));

//Check if the channel, on which the send

function operates, is secured or not

(socketInfo.isSecure)

*(tjp->result()) = gnutls_record_send(

socketInfo.session, *(

char

**) tjp->arg

(1), *(

int

*)tjp->arg(2));

else

tjp->proceed();

}};

Figure 2: Capture of Connection.

4.2 Experimental Results

In order to verify the hardening correctness, we have

set ﬁrst in the original application the server port num-

ber to 443, which means the client and the server

can only communicate through HTTPS (ssl-mode).

Any communication through http won’t be under-

stood and will fail. Then, we have compiled and run

the client application and made it connectto the server

(www.encs.concordia.ca)to retrieveinformation. The

experimental results in Figure 2 show that the appli-

cation failed to retrieve successfully the information.

The server replies with a bad request because it is not

able to understand the message content (Please see

the run in the terminal). The highlighted lines in the

Wireshark capture of the trafﬁc show that the commu-

nication fails and stops after exchanging few undeter-

mined messages.

Afterwards, we have weaved (using AspectC++

weaver) the elaborated aspect in Listing 3 with the

different variants of the original application and com-

piled the resulting source code (using g++) to gener-

ate its corresponding executable.

Then, we have compiled the same original appli-

cation using the extended GCC. Integrating the se-

curity concerns in the Gimple representation of code

does not require reﬁning the pattern into aspect. Com-

piling the selected client application by specifying

the weaving option and selecting the ﬁle, which its

contents are extracted manually (temporary solution)

from the pattern for securing connection in Listing 1,

is enough to perform the injection of the security con-

cerns and generate the executable of the secured ap-

SECRYPT 2008 - International Conference on Security and Cryptography

464

Figure 3: Capture of Hardened Connection.

plication.

Running the two generated executables gave ex-

actly the same results on the terminals and in the

Wireshark packet captures. Due to this and to avoid

duplication, we present in Figure 3 only the run of

the application hardened by the Gimple weaving ca-

pabilities. The experimental results (Please see the

run in the terminal and the highlighted lines in the

Wireshark capture) explore that the new secure appli-

cation is able to connect using both HTTP and HTTPS

connections and exchange successfully the data from

the server in ssl-mode and encrypted form, exploring

the correctness of the security integration process and

the feasibility of our propositions.

5 CONCLUSIONS

We have introduced in this paper an AOP weaving

approach for injecting security concerns in the Gim-

ple representation of programs. This proposition con-

stitutes the ﬁrst attempt towards adopting the aspect-

oriented concept on Gimple and exploiting this inter-

mediate representation to allow advising an applica-

tion written in a speciﬁc language with security code

written in a different one. In this context, few AOP

weaving capabilities for Gimple have been developed

and integrated into the GCC compiler. These features

allow to weave security concerns in the Gimple tree of

a program during the GCC compilation procedures.

We have also explored the feasibility and the rele-

vance of our propositions into practical implementa-

tion and a case study for securing an application using

the proposed weaving capabilities.

REFERENCES

Bodkin, R. (2004). Enterprise security aspects. In Proceed-

ings of the AOSD 04 Workshop on AOSD Technology

for Application-level Security (AOSD’04:AOSDSEC).

DeWin, B. (2004). Engineering Application Level Security

through Aspect Oriented Software Development. PhD

thesis, Katholieke Universiteit Leuven.

Huang, M., Wang, C., and Zhang, L. (2004). To-

ward a reusable and generic security aspect li-

brary. In Proceedings of the AOSD 04 Workshop

on AOSD Technology for Application-level Security

(AOSD’04:AOSDSEC).

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm,

J., and Griswold, W. (2001). Overview of aspectj.

In Proceedings of the 15th European Conference

ECOOP 2001, Budapest, Hungary. Springer Verlag.

Masuhara, H. and Kawauchi, K. (2003). Dataﬂow point-

cut in aspect-oriented programming. In Proceedings

of The First Asian Symposium on Programming Lan-

guages and Systems (APLAS’03), pages 105–121.

Mourad, A., Laverdière, M.-A., and Debbabi, M. (2007).

A high-level aspect-oriented based language for soft-

ware security hardening. In Proceedings of the Inter-

national Conference on Security and Cryptography.

Secrypt.

Mourad, A., Laverdière, M.-A., and Debbabi, M. (2008). A

high-level aspect-oriented based framework for soft-

ware security hardening. Information Security Jour-

nal: A Global Perspective, 17(2):56–74.

Shah, V. (2003). An aspect-oriented security assurance so-

lution. Technical Report AFRL-IF-RS-TR-2003-254,

Cigital Labs.

Spinczyk, O., Gal, A., and chroder Preikschat, W. (2002).

Aspectc++: An aspect-oriented extension to c++. In

Proceedings of the 40th International Conference on

Technology of Object-Oriented Languages and Sys-

tems, Sydney, Australia.

Yang, Z. (2007). On building a dynamic vulnerability de-

tection system. Master’s thesis, Concordia University.

TOWARDS LANGUAGE-INDEPENDENT APPROACH FOR SECURITY CONCERNS WEAVING

465