On Gray Box Program Tracking For Anomaly Detection-Books Download

On Gray Box Program Tracking for Anomaly Detection

2020 | 8 views | 16 Pages | 253.35 KB

On Gray-Box Program Tracking for Anomaly Detection Debin Gao Michael K. Reiter Dawn Song Carnegie Mellon University [email protected] [email protected] [email protected]

platform dependent and less universally applicable reported mimicry attack on systems that em
see Section 2 ploy return address information as an input to
anomaly detection Specifically prior work in
A consequence of limiting our attention to gray box troducing the use of return address informa
approaches is that any gray box model of normal tion largely disregarded the possibility that this
behavior depends on being trained with execution information could be forged by the attacker 1
traces that contain all normal behaviors of the pro While doing so is indeed nontrivial we demon
gram It is not our goal here to determine how to ac strate how the attacker can forge this informa
quire adequate training data for a program Rather tion Despite this observation we demonstrate
we simply assume we have adequate training data in that utilizing this information continues to have
our study if this is not true our techniques might benefits in substantially increasing the attack
yield false detections i e they may detect anoma code size This in turn can render some vul
lies that are not in fact intrusions nerabilities impossible to exploit e g due to
the limited buffer space within which an at
In this context this paper makes the following con tacker can insert attack code
4 Finally we suggest how to use white box ran
domization techniques to render the mimicry
1 We organize the design space of gray box pro attacks mentioned above more challenging
gram tracking along three axes that informally
capture i the information extracted from the
process on each system call ii the granularity The rest of the paper is organized as follows Sec
of the atomic units utilized in anomaly detec tion 2 introduces our proposed framework for gray
tion single system calls or variable length sys box program tracking which covers most of the
tem call sequences and iii the history of such previous works in this area and our new propos
atomic units remembered by the anomaly de als Section 3 provides a detailed quantitative study
tector during monitoring This framework en of the space of gray box program tracking Sec
ables us to categorize most previous approaches tion 4 presents our attack on a previously proposed
and to pinpoint new approaches that were not anomaly detector to forge information and evade de
explored before tection In Section 5 we describe the randomization
technique to make such attacks more difficult Fi
2 We systematically study this design space and nally we present our conclusion and future work in
examine the cost and benefits of the various Section 6
including new gray box program tracking ap
proaches Exploiting richer information along
each axis improves the detector accuracy but
also induces additional costs by increasing 2 Framework for gray box program
both the size of the model and the cost of glean
ing additional information from the running
tracking and new spaces
process Through systematic study we com
pare the benefits resilience against mimicry at
In system call based anomaly detection the
tacks and costs performance and storage over
anomaly detector maintains state per process mon
head of growing these parameters and develop
itored and upon receiving a system call from that
recommendations for setting them in practice
process and possibly deriving other information
In a nutshell our analysis suggests that by
updates this state or detects an anomaly Similar
examining return addresses grouping system
to previous works e g 16 20 we abstract
calls into variable length subsequences and re
this process as implementing a nondeterministic
membering a window of the two most recent
finite automaton Q q0 q where Q is a
program states permits an anomaly detector to
set of states including the initial state q0 and a
track the program with good accuracy at rea
distinguished state q indicating that an anomaly
sonable runtime and storage overhead and to
has been discovered is the space of inputs that
prevent certain mimicry attacks that cannot be
can be received or derived from the running
stopped in previous approaches
process and Q Q is a transition relation
3 We generalize prior work on mimicry at We reiterate that we define as a relation with
tacks 18 21 to demonstrate a previously un the meaning that if state q Q is active and the
monitor receives input then subsequently The decomposition of execution history in the time
all states q 0 such that q q 0 are active If domain into axes 2 and 3 matches program behavior
the set of active states is empty we treat this as a well an atomic unit ideally corresponds to a basic
transition to the distinguished state q block in the program in which there is no branching
the sequence of atomic units an anomaly detector
Below we describe how to instantiate Q and along remembers captures the control flow and transitions
the three axes thereby deriving a space of different among these basic blocks
approaches for gray box program tracking We fur
ther show that this space with three axes provides According to the three axes we parameterize our
a unified framework for gray box program tracking automaton to represent different points in the space
which not only covers most of the previous relevant of gray box program tracking In particular the
gray box proposals but also enables us to identify set
S of states Q is defined as Q q0 q
new ones and S P R S P R
1 The first axis is the runtime information the
anomaly detector uses to check for anomalies S S S S
In black box approaches the runtime informa P P S P P S
tion that an anomaly detector uses is restricted R R P S R R P S
to whatever information is passed through the
system call interface such as the system call By this definition the value of captures two axes
number and arguments though we do not con including the runtime information acquired by the
sider arguments here In a gray box approach anomaly detector axis 1 and the grouping of sys
the anomaly detector can look into the pro tem call subsequences in forming an atomic unit
cess s address space and collect runtime infor axis 2 while the value of n captures axis 3 i e
mation such as the program counter and the the number of atomic units the anomaly detector
set of return addresses on the function call remembers Intuitively growing each of these axes
stack Let S represent the set of system call will make the automaton more sensitive to input
numbers P represent the set of possible pro sequences In fact it can be proven that the lan
gram counter values R represent the set of pos guage accepted by an automaton A1 is a subset of
sible return addresses on the call stack The the language accepted by automaton A2 if A1 has
runtime information an anomaly detector could a larger value on axis 1 or axis 3 than A2 and the
use upon a system call could
S be S P S or same value as A2 on the other two axes
R P S where R d 1 Rd
Below we first describe how a variety of prior works
The second and third axes are about how an fit into our unified framework
anomaly detector remembers execution history in
the time domain In one of the original works in monitoring
system calls Forrest et al 4 implement an
anomaly detection system equivalent to an au
2 The second axis represents whether the atomic tomaton where S and n 1 is a fixed pa
unit that the detector monitors is a single sys rameter that was empirically chosen as n 5
tem call and whatever information is extracted For clarification on this choice see 17 3 The
during that system call or a variable length se transition function is trained by observing the
quence of system calls 23 24 that intuitively sequence of system calls emitted by the pro
should conform to a basic block of the moni gram in a protected environment and on a va
tored program That is in the latter case sys riety of inputs Specifically if during training
tem calls in an atomic unit always occur to the automaton is in state q s1 sm and
gether in a fixed sequence input s is received then q s s1 sm s is
added to if m n and q s s2 sm s is
3 The third axis represents the number of atomic
added otherwise
units the anomaly detector remembers in order
to determine the next permissible atomic units Sekar et al 16 propose coupling the system
call number with the program counter of the
process when the system call is made Sekar et to system call based anomaly detection Though we
al modify the usual definition of the program intend to incorporate these white box approaches
counter however as described in Section 4 1 into our future analysis our reason for precluding
That is P This effort considered only n them from this initial study is that they are gen
1 As in 4 the transition function is trained erally more platform sensitive or require stronger
as follows if during training the automaton is assumptions and thus are generally less applica
in state q and input is received then ble than gray box approaches For example some
q q 0 is added to where q 0 require source code e g 20 and those that do
not are platform specific Most notably the com
Feng et al 3 propose additionally considering plexity of performing static analysis on x86 binaries
the call stack of the process when a system call is well documented This complexity stems from
is made When a system call is made all return difficulties in code discovery and module discov
addresses from the call stack are extracted i e ery 14 with numerous contributing factors includ
R Again this work considered only n ing variable instruction size 4 hand coded assem
1 If during training the automaton is in state bly routines e g due to statically linked libraries
q and input is received then q q 0 is that may not follow familiar source level conven
added to where q 0 tions e g that a function has a single entry point
or use recognizable compiler idioms 15 and indi
Wespi et al 23 24 suggest an anomaly de
rect branch instructions such as call jmp reg32
tection approach in which training is used to
that make it difficult or impossible to identify the
identify a set of system call subsequences using
target location 10 14 Due to these issues and oth
a pattern discovery algorithm 13 The result
ers binary analysis rewrite tools for the x86 plat
of the training is a set of variable length sys
form have strict restrictions on their applicable tar
tem call sequences S They then define
gets 9 10 14 15 As such we have deferred con
an anomaly detection system in which n 0 in
sideration of these techniques in our framework for
our parlance i e for each q0 q0 is
the time being
Other omissions from our present study are system
Of the approaches above only that of Wespi et call arguments a topic of ongoing work and other
al 23 24 utilizes nondeterminism i e permits paradigms that have been proposed for detecting
multiple active states simultaneously All others when a process has been commandeered via the in
above could be expressed using a deterministic sertion of foreign code into the process address space
transition function instead e g program shepherding 8
Table 1 summarizes the prior work described above
and identifies the new approaches we explore in this
paper We emphasize that this is not necessarily a 3 Empirical study of gray box pro
complete list of prior work and that we have not gram tracking
captured all aspects of these prior works but rather
only those of interest here To our knowledge how
ever our analysis is the first that covers many of the The parameters and n are central to the effec
regions in Table 1 Moreover in certain regions that tiveness of an anomaly detection system Together
have received attention in prior work the analysis these parameters determine the states of the au
has been incomplete Notably the analysis of Wespi tomaton and thus the history information on which
et al 23 24 was performed on audit log records the automaton decides that a new input is
not system calls though they conjectured the tech anomalous Intuitively increasing the information
nique could be applied to system call monitoring in each element of or n increases the number of
as well In such cases our analysis here provides states of the automaton and thus the granularity
new insight into the effectiveness of these techniques and accuracy of anomaly detection In this paper
when applied to system call monitoring we view this greater sensitivity as a benefit even
though it comes with the risk of detecting more
Finally we remind the reader that by restricting our anomalies that are not in fact intrusions How
analysis to approaches captured in the above model ever since we restrict our attention to techniques
we do not address various white box approaches that ensure that any transition triggered by sys
Table 1 Scope of this paper and prior work
tem call sequences in the training data will never in order to make a system call which must be the
result in a transition to q we simply assume that same as those in the correct process to avoid de
our detectors are adequately trained and consider tection Nevertheless we demonstrate in Section 4
this risk no further As such the primary costs we that mimicry remains possible While we are not
consider for increasing each of these parameters are concerned with the mechanics of doing so for the
the additional overhead for collecting information present section we do wish to analyze the impact
and the size of the transition relation of monitoring program counter and return address
information on these attacks Specifically in order
Our goal in this section is to provide a system to forge this information the injected attack code
atic analysis of the costs and benefits of enhancing must incorporate the address information to forge
these parameters Specifically we study the follow possibly compressed and so this necessarily in
ing question For given costs what combination of creases the size of the attack code As such a goal
and n is most beneficial for anomaly detection of our analysis is to quantify the increase in size of
We reiterate that as shown in Table 1 this study the attack code that results from the burden of car
introduces several new possibilities for anomaly de rying this extra information We comment that this
tection that to our knowledge have not yet been size increase can impose upon the viability of the
studied attack since the area in which the injected code is
written is typically bounded and relatively small
3 1 Mimicry attacks A second challenge to achieving a mimicry attack is
that a step of the attack may drive the automaton
to a state that requires a long sequence of interven
To understand the benefits of growing or n it is ing system calls to reach the next system call in the
necessary to first understand the principles behind attack or that even makes reaching the next system
mimicry attacks 18 21 An attack that injects call undetected impossible In general enhancing
code into the address space of a running process or growing n increases this challenge for the at
and then causes the process to jump to the injected tacker as it increases the granularity of the state
code results in a sequence of system calls issued by space This must be weighed against the increased
the injected code In a mimicry attack the injected size of the automaton however as well as the ad
code is crafted so that the attack system calls are ditional run time costs to extract the information
embedded within a longer sequence that is consis dictated by A second aspect of our analysis in
tent with the program that should be running in this section is to explore these tradeoffs particularly
the process In our model of Section 2 this simply with an eye toward as the measure of automaton
means that the attack issues system calls that avoid size
sending the automaton to state q
There are many challenges to achieving mimicry at 3 2 Analysis
tacks First it is necessary for the injected code
to forge all information that is inspected by the
anomaly detector This seems particularly diffi In order to analyze the costs and benefits of enhanc
cult when the anomaly detector inspects the pro ing the axes of the state space we set up a testbed
gram counter and all return addresses in the process anomaly detection system The system is imple
call stack since the mechanics of program execu mented as a kernel patch on a Red Hat Linux plat
tion would seem to force even the injected code to form with configuration options for different val
conform to the program counter and stack it forges ues of and n We implement the variable length
pattern approach as described in 13 24 for each first column of Figure 1 shows that the mimicry at
S P R We have chosen four com tack is impossible when R and n 2 Here
mon FTP and HTTP server programs wu ftpd we explain with a simple example In Figure 3 a
proftpd Apache httpd and Apache httpd with solid rectangle represents a state in the automaton
a chroot patch for evaluation purposes Automata and r p and s represent a set of return addresses a
for these four programs and different configurations program counter and a system call number respec
of the axes are obtained by training the anomaly tively If the anomaly detector does not check return
detection system with between four and nine million addresses the two states r1 p s and r2 p s will
of system calls generated from test runs After ob collapse into one and the impossible path denoted
taining the automata we perform analysis to evalu by the dashed line will be accepted which makes a
ate the costs and benefits of different configurations mimicry attack possible Thus checking return ad
of and n Figures 1 and 2 show the results when dresses makes the automaton model more accurate
S P R and S P R respectively
That is Figures 1 and 2 correspond to the two pos Although the minimum number of system calls an
sible instantiations of axis 2 in Section 2 attack makes is a good measure of the difficulty of
a mimicry attack in many cases attackers are free
to make any number of system calls as long as they
do not set off any alarms in the anomaly detector
3 2 1 Resilience against mimicry attacks However in the case where P R P R
the attack has to forge all information that is in
The first three columns of Figures 1 and 2 are about spected by the anomaly detection system program
resilience against mimicry attacks The attack we counters and return addresses We thus provide a
test is the addition of a backdoor root account into second measure on the difficulty of the mimicry at
the password file This common attack needs to tack namely the size of the attack data which is
perform a series of six system calls chroot chdir shown by the graphs on the second column of Fig
chroot open write close which is similar to ures 1 and 2 In this measure we only take into
the attack sequence discussed in 21 However in account the attack data which is the forged pro
the case of Apache httpd only three system calls gram counter and the return addresses and noth
are needed open write close We choose to ing in the case of S and S with the assumption
analyze this attack sequence because it is one of the of perfect compression Again the graphs show that
most commonly used system call sequences in an growing or n makes mimicry attacks consume sig
attack Many attacks need to make system calls nificantly more space Note that the size increase in
that constitute a superset of this sequence attack data could make mimicry attacks less effi
cient due to the need to send more data easier
We perform an exhaustive search to find the shortest to detect or even make some mimicry attacks im
sequence containing the above series of system calls possible due to limited space in the program buffer
not necessarily contiguously that avoids detection 5 where the attack code is inserted For example the
The exhaustive search reveals the best an attacker size of the attack data becomes a few kilobytes on
can do to evade detection when making the attack the proftpd program in some configurations
system calls Graphs on the first column show the
minimum number of system calls a mimicry attack The analysis so far has been focused on one
must make in order to evade detection Missing mimicry attack In an effort to quantify the dif
data points on the graphs indicate that the mimicry ficulty of mimicry attacks in general we define a
attack is not possible For example in the case of property of an automaton state called its fanout
Apache httpd with chroot patch the mimicry at as follows fanout q q where q
tack makes 28 system calls when R and n 1 q q 0 q q 0 fanout q measures the
while it becomes impossible for n 2 with the same number of possible states that can follow an active
setting of It is clear from the graphs that growing state q If an attack compromises the program and
or n makes mimicry attacks more difficult in the course of performing its attack activates q
then only fanout q states can follow from q As
It might not be obvious why the mimicry attack be such fanout q is a coarse measure of the extent to
comes impossible when R while it is possible which a mimicry attack is constrained upon activat
for P with the same setting of n For ex ing q Graphs in the third column of Figures 1 and 2
ample the graph of Apache httpd chroot in the show the percentage of states with fanout q 1 in
of syscalls the attack makes size of attack data bytes of states with fan out 1 average of active transitions size of transition function
80 500 100 50 700
300 R 60 30
S 100 20 S 10 S
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6
400 100 20
200 3000 S
20 S 500 S
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6
200 100 250
Apache httpd
P 50 P 2 P
S 20 S 50 S
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6
Apache httpd chroot
400 100 800
30 200 S 400
P 100 P 2 200 P
1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6
x axis in all graphs above represents the value of n legends show the configuration of
Figure 1 Evaluation results on S P and R with varying window size n
of syscalls the attack makes size of attack data bytes of states with fanout 1 average of active transitions size of transition function
600 100 300 400
300 P 150 200
40 200 100
0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6
500 100 30
400 5000 80 P 800 P
100 P 20 P 200
0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6
Apache httpd
150 50 S 300
3 100 P 3 200
P 50 P 100
0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6
Apache httpd chroot
30 P 3 300
S 100 S 100
10 0 0 1 0
0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6
x axis in all graphs above represents the value of n legends show the configuration of
Figure 2 Evaluation results on S P and R with varying window size n
Collapse time which measures the time spent in the kernel
However this translates to less than 6 increase
in the overall execution time Therefore utilizing
r1 p s P R P R introduces only moderate over
We next consider the amount of processing the
anomaly detector has to do when a system call is
r2 p s made At any point in time the anomaly detec
tor must track the active states q Q as well
as the transitions that the next input symbol from
valid Path
may trigger active transitions When a sys
tem call is made active transitions are examined
impossible path being accepted
if not checking return addresses to determine the next active states and next active
transitions 6 We simulate executions of the FTP
and HTTP server programs and measure the num
Figure 3 Two states collapse if return addresses are ber of active transitions whenever a system call is
not checked made Finally we calculate the average of these fig
ures and present them in the fourth column of Fig
each automata As seen from the graphs the per ures 1 and 2 As shown in these graphs growing
centage of states with fanout q 1 increases as n or n reduces the number of active transitions and
increases especially when n is small thus the processing time of the anomaly detection
system Another observation is that when n 3
We note that average branching factor as introduced increasing n seems to have less effect and the active
in 20 is a conceptually similar measure Here we number of transitions becomes very close to one
prefer to use fanout because fanout measures the
property of an automaton whereas average branch Memory usage and storage overhead is another im
ing factor is a property of executions of the program portant measure of performance As a coarse mea
as well Another difference is that fanout considers sure of the storage overhead here we calculate
all possible transitions regardless of whether the sys for each of the automata the results are pictured
tem call that triggers it is harmful as determined in the last column of Figures 1 and 2 Intuitively
in 20 or not Thus for any particular automaton growing or n should increase the size of due to
fanout should have a much higher value than aver the increase in granularity and accuracy of the au
age branching factor which is used in 5 6 20 tomaton This is confirmed by graphs in Figure 1
However graphs in the last column of Figure 2 sug
gest opposite results as the size of transition func
tion of R is less than those of P and
3 2 2 Overhead S for some values of n A closer look at the
automata reveals that the average length of
The previous three measures give evidence that number of system calls in an atomic unit is larger
growing or n makes mimicry attacks more dif in the case R than it is when S P
ficult However doing so also increases the cost of leading to a reduced number of states and a smaller
the anomaly detector We would thus like to mea transition relation for some values of n This is true
sure the performance overhead in order to find the for all four FTP and HTTP programs in our im
best configuration of and n plementation of the pattern extraction algorithm
However whether this holds for other pattern ex
The first measure we evaluate is the cost of extract traction algorithms remains future work
ing program counters and return addresses We
run two sets of tests one with and one without
the Linux kernel configured to extract return ad 3 3 Discussion and recommendations
dresses from the process when a system call is made
and measure the time it takes to do a Linux kernel
compilation Results Table 2 show that the per Looking at the first axis runtime information cap
formance hit is especially noticeable in the system tured by the anomaly detector we observe that
no checking seconds checking seconds
average of 3 tests overall 80 205 84 934
user 66 397 66 917
system 13 103 16 633
average overhead overall 5 896
user 0 783
system 26 940
Table 2 Performance overhead for checking return addresses
checking return addresses R R greatly in extraction algorithm produces very promising re
creases the difficulty of mimicry attacks Although sults for monitoring accuracy and performance
these addresses could possibly be forged by attack
ers see Section 4 it requires not only detailed
understanding of the vulnerable program and its
automaton but also careful crafting of the attack 4 Program counter and return ad
code and sufficient buffer size for it Since the per
formance overhead for checking return addresses is
dress forgery
moderate Table 2 an anomaly detection system
should always check return addresses
A presumption for the analysis of Section 3 was that
As for the second axis the evidence suggests that an attacker is able to forge the program counter and
forming atomic units from variable length subse return addresses of the process execution stack In
quences makes mimicry attacks difficult even with a gray box monitoring approach these values are
a small value of n This is an interesting result as extracted by the monitor automatically per system
a small value of n indicates smaller memory usage call by directly examining the relevant portions of
and storage overhead last column of Figure 2 Al the process address space As such these values
though S P R introduces nondetermin constitute state that controls the subsequent execu
ism into the automaton supposing that the tech tion of the process upon return of the system call
nique of 13 24 is used with n 2 there are fewer from the kernel due to the mechanics of process
than two active transitions on average and thus the execution It is therefore not obvious that an at
system processing time should be sufficiently small tack could effectively forge these values For exam
ple the first system call of the attack would seem
The third axis value of n shows some tradeoff ingly return control to the program that the pro
between accuracy and performance Since increas cess should be running Indeed prior work that
ing n has little effect on improving accuracy when proposed monitoring return addresses 3 largely dis
R and n 2 refer to the first 4 columns in carded the possibility that these values could be un
Figure 2 we consider the setting of R and detectably forged
n 2 as a general recommendation which makes
mimicry attacks difficult with reasonably low costs In this section we describe how these values can in
in performance Some complicated programs might fact be undetectably forged We describe this at
require n to take a slightly bigger value with an in tack for the Linux execution environment though
crease in performance overhead our approach can be generalized to other environ
ments as well The principle behind our attack is
However choosing S P R requires an to modify the stack frame so that the detector does
extra step in constructing the automaton which is not observe an anomaly even for system calls made
to extract the variable length patterns Different by the attack code Please refer to Appendix A for
parameter settings in the pattern extraction algo a brief review on the structure of a stack frame
rithm could yield very different results It remains
future work to analyze the best pattern extraction We demonstrate our attack using a very simple vic
algorithm and its parameter settings Nevertheless tim program see Figure 4 We emphasize that we
our relatively simple implementation of the pattern have implemented successful attacks for the pro
gram in Figure 4 against our own implementations
of the anomaly detection techniques of 3 16 as In order to evade detection by such a monitor an
well as against an independent implementation of attack should ensure that
return address monitoring by the authors of that
technique 3 The victim program takes a com
mand line argument and passes it to f1 f1 1 The address of the attack code does not appear
calls another function f2 twice which calls a li as a return address when the anomaly detector
brary function lib The function lib in the is tracing the program counter
victim program makes a system call with 17 as the
system call number Function f2 is called twice 2 The program counter found by the anomaly de
just to make the victim program have multiple sys tection system is a valid address for the system
tem calls The victim program is designed in this call made
way to demonstrate how most software programs
make system calls Note that f1 has a local buffer
Because of the first requirement our attack code
that can be overflowed
cannot call a library function to make system calls
void lib syscall 17 If the attack code uses a call instruction the ad
dress of the attack code will be pushed onto the
void f2 lib stack and the anomaly detection system will ob
serve the anomaly So instead of using a call in
void f1 char str char buffer 512
struction our attack code uses a ret instruction
A jump instruction could serve the same purpose
strcpy buffer str
The difference between a call and a ret instruc
int main int argc char argv tion is that the call instruction pushes the return
f1 argv 1 address onto the stack and then jumps to the target
location whereas a ret instruction pops the return
Figure 4 C source code of victim program address and then jumps to that location If we can
make sure that the return address is the address of
the instruction in the library function that makes
the corresponding system call we could use the ret
4 1 Forging the program counter instruction in place of a call instruction Figure 5a
shows the stack layout right before the ret instruc
tion is executed By forging this stack frame the
Upon receiving a system call from the monitored address of an instruction in lib will be used as
process the program counter indicates the address the return address when ret is executed
of the instruction initiating the system call Since
most system call invocations are made from within In order to satisfy the second requirement we must
a library function in libc lib in our sample vic forge another address on the stack which the mon
tim program in Figure 4 the value of the program itor will determine to be the location where lib
counter is often not useful particularly for dynam is called Our attack code simply inserts a valid
ically linked libraries Therefore in the work that address i e one that the monitor will accept for
introduced monitoring the program counter Sekar this system call at the appropriate location as the
et al 16 instead trace back each system call to the forged program counter Figure 5b shows the stack
most recent function invocation from the statically layout after the first ret is executed as seen by the
linked code section and use this location as the pro anomaly detection system
gram counter By doing this the program counter
value will be an address in the program that results As described previously the above suffices to
in the system call rather than an address in the achieve only one system call of the attack after it
library We take a similar approach in our work has been completed control will return to the code
Before the program is run the anomaly detection indicated by the forged program counter However
system examines the section header table of the bi most attacks need to make at least a few system
nary executable to find out address range of the code calls Thus we have a third requirement
text section 7 At runtime it determines the pro
gram counter by tracing the return addresses from
the innermost stack frame until a return address 3 Execution will return to attack code after an
falls within that address range attack system call finishes
addr of instruction in lib argument of f1
ebp old ebp addr of last instruction in main
esp old ebp
a Before ret is executed
addr of strcpy in f1
ebp old ebp
argument of lib argument of lib popped
forged program counter forged program counter popped
ebp old ebp old ebp popped
esp popped
addr of instruction in lib popped addr of instruction in lib popped
old ebp popped old ebp popped
b After ret is executed c After lib returns
Figure 5 Stack layouts in program counter forgery stack grows downwards
The idea to achieve this is to modify a return ad execution always starts at the same location in the
dress remaining on the stack after the system call attack code we need to keep some state information
finishes However a challenge is that the instruction This could be realized by a counter Each time the
that does this modification has to be an instruction attack code is entered the counter is checked and in
in the original program s code because at that time cremented so that the attack code knows how many
execution has not returned to the attack code yet system calls it has already made
Generally speaking any instruction that performs
assignment by pointer dereferencing could be used
For example if a is defined as long and b is defined
as long the instruction a b could be used for
our purpose We just need to modify the stack in 4 2 Forging return addresses
cluding the ebp value so that a is the address of
the return address that we want to modify and b
is the value of an address in the attack code Such
assignment instructions are common in C programs We have also successfully extended our attack to
anomaly detection systems that monitor the entire
In our victim program Figure 4 there is no instruc set of return addresses on the stack The attack
tion that performs simple assignment by pointer is confirmed to be successful against an implemen
dereferencing like a b We implement our at tation of anomaly detection approach proposed by
tack in a different way In the victim program the Feng et al 3
call to strcpy is used to overflow the buffer and
therefore overwrite the return address We could To achieve this we need to modify our attack only
execute this instruction again when the first system slightly to forge the entire set of return addresses
call made by the attack code finishes This overflows on the process execution stack In the attack de
the buffer and overwrites the return address again scribed in Section 4 1 we forged one return address
Execution will return to the attack code when f1 so that the monitor will see a valid program counter
returns value Here the attack is simply required to forge
more stack frames including that for main The
Figure 5c shows the stack layout our attack has to forgery is simpler in this case however as the stack
forge in order to satisfy all three requirements Exe frames contain only the return address and the old
cution will return to strcpy in f1 and by doing ebp value without any arguments or local variables
that the return address of f1 will be overwritten These stack frames are only checked by the anomaly
again This ensures that execution will go back to detection system and they are not used in program
the attack code after a system call is made Since execution at all
5 Using randomization to defend header table is always available for relocatable files
against forgery attacks not true for executables and the dynamic symbol
table is always available for shared libraries binary
analysis becomes much easier
In this section we propose a white box randomiza
tion technique to defend against the forgery attack We note however that even this defense is not fool
presented in Section 4 The attack of Section 4 re proof if the attacker is able to view the memory
quires the attacker to have an in depth understand image of the running process the randomized ad
ing of the internal details of the victim program as dresses could be observed As such the attacker s
well as the automaton representing the normal be code running in the address space of the process
havior of the victim program e g the attacker must could scan the address space to discern the random
know the value of the program counter and return ized addresses and then adjust the return addresses
addresses to forge Thus randomization techniques it forges on the call stack accordingly However this
could be used to render this type of attack more substantially complicates the attack and possibly
difficult increases the attack code size
Although there have been previous works on ad
dress obfuscation e g 1 our goal here is to hide
program counter and return address values and pre
vent attackers from forging them which is differ
ent from previous works Kc et al 7 introduce
the idea of randomizing the instruction set to stop 6 Conclusions and future work
code injection attacks However our randomization
technique does not require special processor support
as required in 7
An initial attempt is to randomize a base address
Two types of base addresses could be randomized
the starting address of dynamically linked libraries In this paper we perform the first systematic study
and the starting address of the code segment in the on a wide spectrum of anomaly detection techniques
executable The former can be implemented by in using system calls We show that previous proposed
serting a dummy shared library of random size The solutions could be organized into a space of three
latter can be implemented by simple modifications axes and that such an organization reveals new
to the linker Changes to these base addresses are possibilities for system call based program tracking
easy to implement However this randomization We demonstrate through systematic study and em
relies on only a single secret pirical evaluation the benefits and costs of enhanc
ing each of the three axes and show that some of the
A more sophisticated technique is to reorder func new approaches we explore offer better properties
tions in the shared library and or the executable than previous approaches Moreover we demon
This can be combined with the first approach to in strate novel mimicry attacks on a recent proposal
troduce a different random offset for each function using return addresses for system call based pro
although implementation becomes a bit more com gram tracking Finally we describe how a simple
plicated Both above techniques rely on the avail white box randomization technique can make such
ability of the object code mimicry attacks more difficult
Although white box approaches could be problem We have analyzed the program counter and return
atic on x86 platform as discussed in Section 2 re addresses as the runtime information acquired by
ordering functions in the dynamically linked library the anomaly detector Other runtime information
and or the executable is not difficult for the follow we have not considered is the system call arguments
ing reasons First we do not need to make any It remains future work to include system call ar
changes within a function block Most other white guments in our systematic analysis The pattern
box techniques e g 5 6 10 need to analyze in extraction algorithm used to group related system
dividual instructions in function blocks and insert calls together as an atomic unit is another area that
additional instructions Second since the section requires further attention
Acknowledgements 2 H Feng J Giffin Y Huang S Jha W Lee
and B Miller Formalizing sensitivity in static
analysis for intrusion detection In Proceedings
This work was partially supported by the U S De of the 2004 IEEE Symposium on Security and
fense Advanced Research Projects Agency and the Privacy May 2004
U S National Science Foundation
3 H Feng O Kolesnikov P Fogla W Lee and
W Gong Anomaly detection using call stack
information In Proceedings of the 2003 IEEE
Notes Symposium on Security and Privacy pages 62
75 May 2003
4 S Forrest S Hofmeyr A Somayaji and
1 Priorwork 3 states only that the intruder could
T Longstaff A sense of self for Unix processes
possibly craft an overflow string that makes the call stack In Proceedings of the 1996 IEEE Symposium
look not corrupted while it really is and thus evade detec on Security and Privacy pages 120 128 May
tion Using our method the same attack would probably still 1996
generate a virtual path anomaly because the call stack is al
tered Our attack demonstrates that this trust in detection
is misplaced 5 J Giffin S Jha and B Miller Detecting ma
nipulated remote call streams In Proceedings
2 m ranges from 1 to n because the number of atomic units of the 11th USENIX Security Symposium Au
the anomaly detector remembers is less than n in the first n gust 2002
states of program execution
6 J Giffin S Jha and B Miller Efficient context
17 n is recommended to be 6 which corresponds to
n 5 in our parlance
sensitive intrusion detection In Proceeding of
Symposium on Network and Distributed System
4 Prasad and Chiueh claim that this renders the problem Security Febuary 2004
of distinguishing code from data undecidable 10
7 G Kc A Keromytis and V Prevelakis Coun
5 Our exhaustive search guarantees that the resulting tering code injection attacks with instruction
mimicry attack involves the minimum number of system calls set randomization In Proceeding of the 10th
made in the case of wu ftpd Apache httpd and Apache httpd
with chroot patch However due to the complexity of the ACM Conference on Computer and Communi
proftpd automaton we could only guarantee minimum num cation Security pages 272 280 October 2003
ber of intervening system calls between any two attack system
calls 8 V Kiriansky D Bruening and S Amarasinghe
6 If the automaton is in fact deterministic then optimiza
Secure execution via program shepherding In
Proceeding of the 11th USENIX Security Sym
tions are possible In this analysis we do not explicitly con
sider these optimizations though the reader should view the posium August 2002
fourth column of Figure 1 as potentially pessimistic
9 X Lu A Linux executable editing library Mas
7 Strictly
speaking this constitutes white box processing ter s Thesis Computer and Information Sci
though qualitatively this is distant from and far simpler than ence National Unviersity of Singpaore 1999
the in depth static analysis performed by previous white box
approaches Were we to insist on sticking literally to gray box
techniques however we could extract the same information 10 M Prasad and T Chiueh A binary rewriting
at run time using less convenient methods defense against stack based buffer overflow at
tacks In USENIX Annual Technical Confer
ence General Track June 2003
11 N Provos Improving host security with system
call policies In Proceeding of the 12th USENIX
Security Symposium August 2003
1 S Bhatkar D DuVarney and R Sekar Ad
dress obfuscation an efficient approach to com 12 N Provos M Friedl and P Honeyman Pre
bat a broad range of memory error exploits In venting privilege escalation In Proceeding of
Proceeding of the 12th USENIX Security Sym the 12th USENIX Security Symposium August
posium pages 105 120 August 2003 2003
13 I Rigoutsos and A Floratos Combinatorial 23 A Wespi M Dacier and H Debar An
pattern discovery in biological sequences the intrusion detection system based on the Teire
TEIRESIAS algorithm In Proceedings of the sias pattern discovery algorithm In Proceed
1998 Bioinformatics vol 14 no 1 pages 55 ings of the 1999 European Institute for Com
67 1998 puter Anti Virus Research Conference 1999
14 T Romer G Voelker D Lee A Wol 24 A Wespi M Dacier and H Debar Intrusion
man W Wong H Levy B Bershad and detection using variable length audit trail pat
B Chen Instrumentation and optimization of terns In Proceedings of the 2000 Recent Ad
Win32 Intel executables using etch In Proceed vances in Intrusion Detection pages 110 129
ing of the USENIX Windows NT workshop October 2000
August 1997
15 B Schwarz S Debray and G Andrews Dis
assembly of executable code revisited In Pro
ceeding of Working Conference on Reverse En A Review of stack frame format
gineering pages 45 54 Oct 2002
16 R Sekar M Bendre D Dhurjati and P Bolli
The call stack of the system we are using in this pa
neni A fast automaton based method for de
per is divided up into contiguous pieces called stack
tecting anomalous program behaviors In Pro
frames Each frame is the data associated with a call
ceedings of the 2001 IEEE Symposium on Se
to one function The frame contains the arguments
curity and Privacy pages 144 155 May 2001
given to the function the function s local variables
17 K Tan and R Maxion Why 6 Defining etc When the program is started the stack has
the operational limits of stide an anomaly only one frame Each time a function is called a
based intrusion detector In Proceedings of the new frame is made Each time a function returns
2002 IEEE Symposium on Security and Pri the frame for that function invocation is eliminated
vacy pages 188 201 May 2002 If a function is recursive there can be many frames
for the same function The frame for the function
18 K Tan J McHugh and K Killourhy Hiding in which execution is actually occurring is called the
intrusions from the abnormal to the normal innermost frame
and beyond In Proceedings of Information Hid
ing 5th International Workshop pages 1 17 The layout of a stack frame is shown in Figure 6
January 2003 ebp always stores the address of the old ebp value
of the innermost frame esp points to the current
19 D Wagner Janus an approach for confine bottom of the stack When program calls a function
ment of untrusted applications Technical Re a new stack frame is created by pushing the argu
port CSD 99 1056 Department of Computer ments to the called function onto the stack The
Science University of California at Berkeley return address and old ebp value are then pushed
August 1999 Execution will switch to the called function and the
20 D Wagner and D Dean Intrusion detection ebp and esp value will be updated After that space
via static analysis In Proceedings of the 2001 for local variables are reserved by subtracting the
IEEE Symposium on Security and Privacy esp value When a function returns ebp is used to
pages 156 168 May 2001 locate the old ebp value and return address The
old ebp value will be restored and execution returns
21 D Wagner and P Soto Mimicry attacks on to the caller function
host based intrusion detection systems In Pro
ceedings of the 9th ACM Conference on Com function arguments
puter and Communications Security Novem return address
ber 2002 ebp old ebp
esp local variables
22 R Wahbe S Lucco T E Anderson and
S L Graham Efficient software based fault
isolation In Proceeding of the Symposium on Figure 6 Stack frame layout stack grows down
Operating System Principles 1993 wards

Related Books

GE Energy r03 - Advantage Austria

GE Energy r03 - Advantage Austria

GE Energy Jenbacher gas engines Benito Prieto Baumann10/14/2008 Motores a gas Jenbacher • Rango de potencia desde 0.25MW a 3MW, 4 plataformas / 10 productos • Flexibilidad de combustibles: gas natural o una amplia variedad de combustibles renovables o alternativos (gas de relleno sanitario, biogás, gas de carbón, etc.)

Continue Reading...
EQUIPMENT DATA SHEET - Used Generator Power

EQUIPMENT DATA SHEET - Used Generator Power

EQUIPMENT DATA SHEET Generator Bill of Material reference number B0000973A Model reference GN1000GASCON, GN77G 1000 kW MODEL Model size and rating MANUFACTURER Model Reference GE Jenbacher 1000KWNGG PERFORMANCE DATA Design Rating kW1063 Maximum Ambient °F104 ELECTRICAL DATA Prime Power (PRP) kW1063 Voltage Capability 480 @ 60Hz Frequency 50/60Hz ENGINE Make/Type Jenbacher J-320 Cylinders and ...

Continue Reading...


GE Jenbacher 0.10 Technical parameters All data in the technical specification are based on engine full load (unless stated otherwise) at specified temperatures as well as the methane number and subject to technical development and modifications. For isolated operation an output reduction may apply according to the block load diagram. Before being able to provide exact output numbers, a ...

Continue Reading...
Jenbacher gas engines a variety of efficient applications

Jenbacher gas engines a variety of efficient applications

GE Power & Water -Jenbacher gas engines 14.02.2011 Two Jenbacher biogas engines generate much needed energy while helping to solve the farm’s waste problems: The farm owns three million chickens, producing 220 tons of manure and 170 tons of wastewater each day.

Continue Reading...
Biogas 330kW el. - KTS Eng

Biogas 330kW el. - KTS Eng

The technical Instruction TA 1100-0110 "PARAMETER FOR GE Jenbacher GAS ENGINES" must be strictly observed. for plants installed at > 500m above see level and/or intake temperature > 30°C, the reduction of engine power is determined for each project. Jenbacher gas engines ’

Continue Reading...
[DOC] Jenbacher Jgs Engines Manual

[DOC] Jenbacher Jgs Engines Manual

Jenbacher Jgs Engines Manual Right here, we have countless book Jenbacher Jgs Engines Manual and collections to check out. We additionally have enough money variant types and as well as type of the books to browse. The standard book, fiction, history, novel, scientific research, as competently as various additional sorts of books are readily ...

Continue Reading...
Jenbacher Gas Engines Manual - thepopculturecompany.com

Jenbacher Gas Engines Manual - thepopculturecompany.com

Read Book Jenbacher Gas Engines Manual Jenbacher Gas Engines Manual Thank you for downloading jenbacher gas engines manual. Maybe you have knowledge that, people have search numerous times for their chosen novels like this jenbacher gas engines manual, but end up in malicious downloads.

Continue Reading...
Technical Specification

Technical Specification

The technical Instruction TA 1100-0110 "PARAMETER FOR GE Jenbacher GAS ENGINES" must be strictly observed. for plants installed at > 500m above see level and/or intake temperature > 30°C, the reduction of engine power is determined for each project. Jenbacher gas engines Technical Specification

Continue Reading...
A Subjective Academic Narrative Reviewing Academic ...

A Subjective Academic Narrative Reviewing Academic ...

world. Critical thinking has challenged this mode of producing knowledge not initself per se but as a way of providing a template for all academic knowledge. Partly, of course, this powerful domination exists because these scientific methods have been extremely successful in such areas as medicine, technology, manufacturing and warfare. They have

Continue Reading...


2. Colonna, Mary R. and Judith E. Gilbert, Reason to Write: Strategies for Success in Academic Writing, Oxford, Oxford UP, 2006. Second Year 1. 2. Critical Thinking (reading to develop critical thinking and thinking skills, promote discussion and prepare students for writing assignments). Topics

Continue Reading...