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 first attempt to-
wards adopting the aspect-oriented concept on Gimple and exploiting this intermediate representation to allow
advising an application written in a specific 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 confidence 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 fit 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 diffi-
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
Copyright
c
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 first attempt towards adopting the aspect-oriented
concept on Gimple and exploiting this intermediate
representation to allow advising an application writ-
ten in a specific 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
field 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
defined the dataflow pointcut, which identifies 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 refined 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
refinement 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 specific 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 file. Additional components have
been developed in order to parse such file, gather the
needed information (e.g. function name, return type,
etc.) and pass them as parameters to specific 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) specified
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 modified
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
first, using SHL, the language-independent security
aspect (i.e. pattern) needed to secure the connections
of a selected client application. Then, we have re-
fined 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 file 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 patterns 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 refined 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 defined 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 modified 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
<xcred >
ExportParameter
<sessi on >
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
<sessi on >
BeginBehavior
/ / Add the TLS handshake
AddTLSHandshake;
EndBehavior
Replace
Ca ll <send >
ImportParameter
<sessi on >
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
<sessi on >
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
<xcred >
ImportParameter
<sessi on >
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();
if
(*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
if
(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 first 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 traffic 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 refining the pattern into aspect. Com-
piling the selected client application by specifying
the weaving option and selecting the file, 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 first attempt towards adopting the aspect-
oriented concept on Gimple and exploiting this inter-
mediate representation to allow advising an applica-
tion written in a specific 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). Dataflow 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