Automatic Detection of Unsafe Dynamic
Component Loadings: A Survey
Sneha D. Patel#1, Tareek M. Pattewar*2
#
PG Student, Department of Computer Engineering, North Maharashtra University
SES’s R. C. Patel Institute of Technology, Shirpur, MS, India
#1sweetsp7@rediffmail.com
*
Assist. Prof., Department of Information Technology, North Maharashtra University
SES’s R. C. Patel Institute of Technology, Shirpur, MS, India
*2tareekpattewar@gmail.com
Abstract-- Dynamic loading is an one of the important mechanism
for software development. It allows an application, to run it and
to dynamically link a component and use its exported
functionalities. Dynamic loading is a process by which a
computer program can run at time, and it loads a library into
memory, and regains the addresses of functions and variables in
the library, and execute those functions and those variables, and
also unload the library from memory. An effective dynamic
analysis to detect vulnerable and unsafe dynamic component
loadings is proposed. This work introduces the first automated
technique to detect and analyze vulnerabilities and errors related
to the dynamic component loading. This analysis has two phases:
1) Online Phase to apply dynamic binary instrumentation to
collect runtime information on component loading, and 2) Offline
Phase to analyze the collected information to detect vulnerable
component loadings. The technique uses a set of practical tools
for detecting unsafe component loadings on Microsoft Windows
and Linux. An extensive analysis of unsafe component loadings
on various types of popular software has been conducted.
Keywords--- Binary Instrumentation, Dynamic loading , Unsafe
Component Loading, Vulnerability, Dynamic analysis.
I. INTRODUCTION
Dynamic loading is one of the important mechanisms for
software development. It allows an application to run flexible
and to dynamically link a component and use its
functionalities. Their merits include modularity and generic
interfaces for third-party software like plug-ins. It also helps
to remove software bugs as bug fixes of a shared library can
be used easily. Because of these advantages, dynamic loading
is widely used in designing and implementing software. A key
step in dynamic loading is component resolution, i.e., locating
the right component for use at runtime. Operating systems
mainly provide two resolution methods, first specifying the
full path and second the filename of the target component.
The full path, operating systems simply locate the target from
the given full path. And the filename, operating systems
resolve the target by searching a number of directories, which
are determined by the runtime directory search order, to find
the first component. Thus far this issue has not been
addressed. In particular, this shows that unsafe component
loading represents a common class of security vulnerabilities
on the Windows and Linux platforms.
The problem of an unsafe dynamic loading had been
known, but it had not been considered as a very serious threat
because its exploitation requires local file system access on
the affected host. The problem has started to receive more
attention due to recently discovered remote code execution
attacks [2][3][4]. Here is an example of the attack framework.
Suppose,an attacker sends a victim an archive file containing a
document for a vulnerable program (e.g., a Word document)
and a harmful (malicious) DLL. In this case, if the affected
host (victim) opens the document after extracting he archive
file, the vulnerable program will load the harmful DLL, which
leads to remote code execution. In this, here it presents the
first automated technique to detect unsafe dynamic component
loadings. This technique mainly includes two parts of
dynamic analysis. In the first phase, which is online, it uses
dynamic binary instrumentation to capture a program’s
sequence of events related to component loading (dynamic
profile generation). In particular this dynamically collects
three kinds of information:
1) System calls which are required for dynamic loading for
information on target component specifications, directory
search orders, and the sequence of component loading
behavior.
2) Image loading for information on resolved component
paths, and
3) Process and thread identifiers for multithreaded
applications. In the second phase, which is offline, it analyzes
the captured profile to detect unsafe component resolutions
(offline profile analysis). It detect two types of unsafe
loadings—resolution failure and unsafe resolution—for each
component loading from the profile. A resolution failure is
similar to the case where the target component is not found,
while an unsafe resolution is similar to the case where there
exist other directories searched before the directory containing
the resolved target component. [1]
A. Unsafe Component loading
1) Dynamic Loading of Components
Software components often utilize functionalities
exported by other components such as shared libraries
execution at runtime. This operation is mainly composed of
three parts: resolution, loading, and usage. Specifically, an
application resolves the needed target components, loads
them, and utilizes the useful functions provided by them.
Components internal operation can be achieved through
dynamic loading provided by operating systems or runtime
environments.
a) Component Resolution
Fig.1. Dynamic component loading procedure
In order to resolve a target component, it is necessary to
identify it correctly. Here, operating systems provide two
types of target component specifications: full path and
filename. For full path, operating systems resolve a target
component based on the provided full path. For example, a
full path specification /lib/libc-2.7.so for the libc library in
Linux determines the target component using the given full
path. For filename, operating systems obtain the full path of
the target component from the provided file name and a
dynamically determined series of search directories. In
particular, an operating system repeat an action through the
directories until it finds a file with the given file name, which
is the resolved component.
b) Chained Component Loading
In dynamic loading, the full path of the target component
is determined by its specification through the resolution
process, and the component is included into the host software
if it is not already loaded. During the process of including the
target component, the component’s loading time and
dependent components are also loaded. Fig. 1 explains the
procedure of dynamic loading. Here component B is loaded
by component A. B’s dependent components (e.g., component
C) are also loaded. It can usually obtain information on B’s
dependent components from B’s file representation. This
process of chained component loading is repeated until all
dependent components have been loaded.
2) Unsafe Component Resolution
Although dynamic loading is a crucial step in software
termination, it also has an inherent security issue. A loaded
target component is only determined by the specified file
name. This can lead to the loading of unavailable or even
harmful components and thus may allow arbitrary code
execution. For example, an attacker can judge a vulnerable
web browser to resolve a spyware file with the specified file
name instead of the intended component. To mitigate this
problem, operating systems provide functionalities to prevent
certain components from being replaced by another harmful
component. For example, Microsoft Windows has Windows
Resource Protection to protect system resources, and
operating systems like UNIX, require root privilege for
modifying system files. However, these protections are not are
much more or useful to prevent unsafe component loadings.
Due to the problems in security of resolution mechanism, it is
mainly possible to hijack the loading of an planned
component. It classifies two types of unsafe resolution failure,
component resolution and unsafe resolution.
a) Resolution Failure
This occurs when an application fails to resolve a target
component because the file does not exist in the specified
path or the given search directories. If this condition comes ,
any file with the same given name in the directories searched
by the application and can be loaded, and attackers can
terminate arbitrary code by placing malicious component
files in such directories.
b) Unsafe Resolution
overflows. Although these approaches have shown promising
results in detection of such vulnerabilities, no one has targeted
Although the correct and the specified component are the detection of unsafe component loadings; our work
resolved, there may still exist a vulnerability that makes formulates the problem and introduces the first effective
hijacking possible. In particular, if the resolution of a automated technique to detect such vulnerabilities. [14]
component satisfies the following issues given, it may still be
Non-control-data attack. Unsafe component loading can
possible to hijack the loaded component:
also be considered an example of non-control-data attacks
1. The target component is given by the specified file name,
because it does not alter the control data of the target program.
2. The resolution is determined by iteratively searching a Chen et al. surveyed attack techniques that corrupt application
sequence of directories, and
data, which include host identity data, configuration data, host
3. There exists another directory searched before the one input data, and decision-making data, and presented a detailed
containing the target component.
analysis and defense mechanism. Compared to those nonIf a dynamic loading satisfies the given conditions, an control-data attacks, unsafe dynamic loading is mainly due to
attacker can attempt to place a harmful component with the defects in the component loading procedure, while they
same specified name in such a first searched directory. When originate from unsafe handling of application data. In
the OS tries to find the solution of the target component, the addition, the attack vectors are different. [14][15]
harmful component is found first and loaded in place of the
III. METHODOLOGY
planned component. In such a case, arbitrary code termination
becomes possible.
II. RELATED WORK
In this survey additional related work besides those on
detecting unsafe DLL loadings. This divide the related work
into four categories: safe component resolution, safety
improvement of browser plug-ins, vulnerability analysis and
detection, and no control data attacks.
Safe component resolution. Chari et al. [5] present a
mechanism, safe-open, to prevent unsafe component
resolutions in UNIX by detecting modifications to path names
by untrusted users on the system. In comparison, this proposes
a dynamic analysis to discover unsafe component loading
vulnerabilities in the software itself.
Safety improvement of browser plug-in [6], [7], [8], [9]
Secure browsers; have been introduced to mitigate risks
caused by unsafe usage of third-party plug-ins.
Gazelle [7] browsers adopt OS-level sandboxing
techniques to reduce damage introduced by an unsafe plug-in
usage.
Grier et al. [9] propose security policies for secure plug-in
execution. Internet Explorer utilizes a kill-bit [10] to prevent
malicious ActiveX components from being loaded. These
techniques aim at providing software platforms with secure plugin usage, while our technique aims at detecting unsafe loadings of
general software components.
Vulnerability analysis and detection. Testing and analysis
techniques for detecting software vulnerabilities have been
well explored. Most of the previous approaches have focused
on detecting low-level, unexpected program behaviors such as
memory corruption errors [10], [11], [12], [13] and integer
An unsafe component loading can cause serious security
vulnerabilities in software. Here, we present a dynamic
analysis technique for detecting unsafe component loadings.
Fig. 2 shows the high-level overview of our analysis process,
which is composed of two parts: dynamic profile generation
and offline profile analysis. To search unsafe component
resolutions, we first capture series of sequence of system-level
actions for dynamic loading during a program’s termination.
Here we use dynamic binary instrumentation to produce the
profile on its runtime termination. We then reconstruct the
dynamic loading information from the profile offline and
check safety conditions for each resolution. Because our
technique only requires binary executables, it is robust and
can be applied to study not only open source applications but
also commercial off-the-shelf products. Alternatively, we
could also detect an unsafe component loading during the
program termination. However, we divide our analysis into
two parts (i.e., the dynamic profile generation and the offline
profile analysis) to reduce the performance overhead incurred
during dynamic binary instrumentation.
A. Dynamic Profile Generation
Dynamic analysis has been widely used to understand
software behavior. Specifically, it dynamically instruments
the binary executable under analysis to capture a series of
system-level actions for dynamic loading of components.
During the instrumented program termination, it collect three
types of information: system calls invoked for dynamic
loading, image loading, and thread identifiers and also the
processes.
Fig.2. Framework for detecting unsafe component loading.
1) System Calls Involved for Dynamic Loading
System call analysis is a widely used analysis technique
to Understand program behavior because a sequence of
invoked system calls (with names of the invoked functions
and their arguments) can provide useful information on a
program termination. To gather system-level actions for the
dynamic component loading, this instrument system calls that
cover all possible control-flow paths of the dynamic loading
steps, which enables us to reconstruct the procedure offline.
Besides the name of an instrumented system call, it also
collects its parameter information for detecting unsafe
component resolutions. The target component specification
(i.e., specified full path or filename) and the directory search
order can be obtained from the system call parameters. The
directory search order can vary according to the underlying
system and program settings; it is calculated by operating
systems and provided as parameters to the relevant system
calls for dynamic loading. Further, results of the instrumented
System calls provide both the control flow in the loading
procedure and error messages generated by the operating
systems. This information is used for the reconstruction of the
dynamic loading procedure and the detection of unsafe
loadings.
2) Image loading
It also captures actual loadings of target components via
dynamic binary instrumentation. The component loading
information is needed for reconstructing the loading procedure
in a combination with the information captured by the system
call instrumentation. It also shows the given resolved full path
determined by the loading procedure. This uses this resolved
path to detect unsafe component loading.
each thread loads a component dynamically and the
instrumented system calls for each loading can be inserted,
which makes it difficult to correctly reconstruct the loading
procedure of each thread. To solve this problem, this captures
process and thread identifiers along with the other information
on instrumented system calls.
B. Offline Profile Analysis
In this phase, it extracts each component loading from the
profile and detects the unsafe loadings of a target component
and its dependent components. In the first step of this offline
phase, we extract component loading from the profile. To this
end, this first group a sequence of actions in the profile by
process and thread identifiers as the actions performed by
different threads may be interleaved due to context switching.
This grouping separates the series of dynamic loadings
performed by different threads. This divides the sequence for
each thread into subsequences of actions, one for each
different dynamic loading. This can be obtained by using the
first invoked system call for dynamic loading (e.g., dlopen) as
a delimiter.
1) Resolution Failure of a Target Component
To detect failed resolution of a target component, this
simply checks the number of image loads and the number of
failed resolutions during the dynamic loading procedure. If, if
no image is loaded and the resolution of the component failed,
this report the component loading as a resolution failure. Note
that an OS does not load the same component multiple times.
Thus, it checks this necessary condition for resolution failure
because a program may attempt to load a component that is
already loaded. To avoid reporting any unavailable resolution
failures, this also explicitly checks whether a resolution failure
has occurred.
3) Process and Thread Identifiers
2) Unsafe Resolution of a Target Component
Because our approach is based on the system call
instrumentation, it is important to consider multiple threaded
applications. If the target program uses multiple threads and
It describes how to detect unsafe resolution of a target
component. This first check whether the target component is
specified by its file name because a full path specification
does not iterate through the search directories for resolution. If
a file name is used, this retrieve the resolved path of the target
component by retrieving the first element of a list of image
loads in the dynamic loading method. Here the first element of
the list corresponds to the target component because there
exists no image load in the loading procedure if the target
component is already loaded or its resolution fails, and the
target component is always loaded for the first time during its
runtime loading. Based on the resolved full path, the target
component specification, and the applied directory search
order, these determine whether to classify this as an unsafe
resolution by checking the directories searched before the
resolution.
also discovered 41 potential remote code execution attacks on
Microsoft Windows.
ACKNOWLEDGEMENT
We are thankful to all the personalities who helped us
throughout this survey.
REFERENCES
[1]
[2]
[3]
3) Unsafe Component Resolution by Chained Loadings
In this, it detect unsafe component resolutions in the
chained loading procedure by performing the offline profile
analysis recursively In particular, it extract each component
loading from the chained loadings and recursively apply the
aforementioned technique to detect unsafe component
resolutions.
IV. OBJECTIVES
Our objective is to implement the system discussed above
by making some crucial changes. We are interested in
developing static binary analysis techniques to detect unsafe
component loadings. Although our dynamic analysis is
effective, it may suffer from the standard limitation of
dynamic analysis, namely, the code coverage problem.
Specifically, our approach may miss unsafe component
loadings that can happen. We plan to develop sound, practical
static analysis techniques to complement the dynamic analysis
we introduced here.
[4]
[5]
[6]
[7]
[8]
[9]
[10]
V. CONCLUSION
[11]
In this paper, we have described the first analysis technique to
detect unsafe dynamic component loadings. This technique
works in two parts. It first produces profiles to record a
sequence of component loading behaviors at runtime using
dynamic binary instrumentation. It then studies the profiles to
detect two types of unsafe component loadings: resolution
failures and unsafe resolutions. To evaluate our technique, this
implemented tools to detect unsafe component loadings on
Microsoft Windows and Linux. This evaluation specifies that
unsafe component loadings are prevalent on both platforms and
more severe on Windows platforms from a security perspective.
In particular, our tool detected more than 4,000 unsafe
component loadings in popular software on both platforms. It
[12]
[13]
[14]
[15]
T. Kwon and Z. Su, “Automatic Detection of Unsafe Component
Loadings,” Proc. 19th Int’l Symp. Software Testing and Analysis,
pp. 107-118, 2010.
“Exploiting DLL Hijacking Flaws,” http://blog.metasploit.com/
2010/08/exploiting-dll-hijacking-flaws.html, 2011.
B.Cornelissen, A. Zaidman, A. van Deursen, L. Moonen, and
R.Koschke,
“A
Systematic
Survey
of
Program
Comprehensionthrough Dynamic Analysis,” IEEE Trans. Software
Eng., vol. 35,no. 5, pp. 684-702, Sept./Oct. 2009.
C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney,
S.Wallace, V.J. Reddi, and K. Hazelwood, “Pin: Building
Customized Program Analysis
Tools
with Dynamic
Instrumentation,”Proc. ACM SIGPLAN Conf. Programming
Language Design and Implementation, pp. 190-200, 2005.
S. Chari, S. Halevi, and W. Venema, “Where Do You Want to Go
Today? Escalating Privileges by Pathname Manipulation,” Proc.
Network and Distributed System Security Symp., Mar. 2010.
Grier, S. Tang, and S.T. King, “Secure Web Browsing with the
OP Web Browser,” Proc. IEEE Symp. Security and Privacy, pp.
402-416, 2008.
H.J. Wang, C. Grier, A. Moshchuk, S.T. King, P. Choudhury, and
H. Venter, “The Multi-Principal OS Construction of the Gazelle
Web Browser,” Proc. 18th Conf. USENIX Security Symp., pp. 417432, 2009.
Goldberg, D. Wagner, R. Thomas, and E.A. Brewer, “A Secure
Environment for Untrusted Helper Applications Confining the
Wily Hacker,” Proc. Sixth Conf. USENIX Security Symp.
Focusing on Applications of Cryptography, 1996.
Grier, S.T. King, and D.S. Wallach, “How I Learned to Stop
Worrying and Love Plugins,” Proc. Workshop Web 2.0 Security
and Privacy, May 2009.
D.Dhurjati and V. Adve, “Backwards-Compatible Array Bounds
Checking for C with Very Low Overhead,” Proc. 28th Int’l Conf.
Software Eng., pp. 162-171, 2006.
O. Ruwase and M.S. Lam, “A Practical Dynamic Buffer Overflow
Detector,” Proc. Network and Distributed System Security Symp.,
Feb. 2004.
Cadar, V. Ganesh, P.M. Pawlowski, D.L. Dill, and D.R. Engler,
“Exe: Automatically Generating Inputs of Death,” Proc. 13th
ACM Conf. Computer and Comm. Security, pp. 322-335, 2006.
Cadar, D. Dunbar, and D. Engler, “KLEE: Unassisted and
Automatic Generation of High-Coverage Tests for Complex
Systems Programs,” Proc. Eighth USENIX Conf. Operating
Systems Design and Implementation, pp. 209-224, 2008.
P. Saxena, P. Poosankam, S. McCamant, and D. Song, “LoopExtended Symbolic Execution on Binary Programs,” Proc. 18th
Int’l Symp. Software Testing and Analysis, pp. 225-236, 2009.
S. Chen, J. Xu, E.C. Sezer, P. Gauriar, and R.K. Iyer, “NonControl Data Attacks Are Realistic Threats,” Proc. 14th Conf.
USENIX Security Symp., 2005.