Transcript Mobile Code Security

Mobile Code
Security
Yurii Kuzmin
What is Mobile Code?

Term used to describe general-purpose
executables that run in remote locations.
 Web browsers come with the ability to run
general-purpose executables.
 The executable can be written by anyone and
executed on any machine that runs a
browser.
 Same code can be executed on any platform
regardless of the operating system and
hardware architecture.
History





Concept is not new
Several object-based systems are well
established (CORBA)
HotJava – web browser itself written in Java,
first browser to support applets.
Version 2 of Netscape Navigator (spring of
1996)
Version 3 of Internet Explorer (winter of 1995)
Security Concerns





Global, homogeneous, general-purpose
interpreter
Interpreter is part of the browser
Attacker can run native code on the executing
machine
Attacker can include malicious machine code
in executables and cause it to be executed
Code executed by a user runs with that user’s
permissions
Security Techniques
Sandbox Model
 Code Signing
 Hybrid: Sandbox and Signatures
 Firewalling
 Proof-Carrying Code

Sandbox Model

Contain mobile code in such a way that
it cannot cause any damage to the
executing environment
– Restrict access to a file
– Limit the ability to open network connection

Java interpreter inside Internet browsers
– Each implementation of interpreter has a
security policy
– Policy explicitly describes the restrictions
Sandbox Model

Components of Java Interpreter
– Class loader
– Verifier
– Security manager
Class Loader
Special Java object that converts
remote bytecode into data structures
representing Java classes
 The only way to add remote classes to
machine’s local class is via the class
loader
 Class loader creates a name space for
downloaded code, local names are
given priority, so remote classes cannot
overwrite local names.

Verifier
Performs static checking on the remote
code before it is loaded
 Checks that the remote code

– Is valid virtual machine code
– Does not overflow or underflow the
operand stack
– Does not user registers improperly
– Does not convert data types illegally
Security Manager
Provides flexible access to potential
dangerous system resources
 Security Manager classes represent a
security policy for remote applets

Security Manager
Public boolean AAA(Type arg1){
SecurityManager security =
System.getSecurityManager();
if (security != null){
security.checkAAA(arg1);
}
}
Example is taken out of “Mobile Code Security” by Aviel D. Rubin
The Sandbox Model
Error in any security component can
lead to a violation of the security policy
 Risks are increased by the complexity
of the interaction between components.

– If the class loader has incorrectly identified
a class as local, the security manager
might not be able to apply the right
verifications
Code Signing
The client manages a list of entities that
it can trust.
 When a mobile executable is received,
the client verifies that it was signed by
an entity on the list
 If so, then it is run, most often with all of
the user’s privileges
 Used by ActiveX

Code Signing
Trusted code runs with full user’s
privileges, or it doesn’t run at all
 If an intruder can change the policy on a
user’s machine, the intruder can then
enable the acceptance of all ActiveX
content.
 Legitimate ActiveX program can open
the door for future illegitimate traffic

Hybrid:Sandbox and Signatures

Attempts to merge benefits of the sandbox
model with code signing
 Digitally signed applet is treated as trusted
local code if the signature key is recognized
as trusted by the client system that receives it
 Client downloads an applet and then consults
a policy table for every signed applet
 Trusted applets can access file system,
establish network connection and do other
applications that are restricted by sandbox
Firewalling
Selectively choosing whether run or not
to run a program at the very point where
it enters the client domain
 Web proxy or firewall can try to identify
Java applets, examine them, and
decide whether or not to serve them to
the client
 Firewall approach assumes that
applets can somehow be identified

Firewalling
Finjan Software and Security 7 have
products that attempt to identify applets
and then examine them for security
properties. Only safe applets are
allowed to run
 Techniques that they use are
confidential
 Halting problem – there is no generalpurpose algorithm that can determine
the behavior of an arbitrary program.

Firewalling

Digitivity Inc. uses another approach
– Java applets are divided into graphical
actions and all other actions
– Graphical run on the client machine
– Other run on a sacrificial playground
machine
1. Request for Page
Change
<applet>
tags
4. Modified Page
Load
Graphics
Server
Proxy
Playground
8. I/O
3. Page
5. Request for Applet
Change
I/O
Load
applet
2.Request for Page
7. Modified Applet
6. Applet
WEB
Browser
Firewalling
The playground architecture trusts small
graphics packages because it’s easy to
analyze
 More dangerous and untrustworthy
mobile code has no access to
meaningful resources
 This approach requires bytecode
modification and cannot be used in
combination with the usual approach to
code signing

Proof-Carrying Code
Is an active area of research today
 Technique for statically checking code
to make sure that it does not violate
some safety policy
 Some programs can construct a proof
that they do not contain any buffer
overflows
 Proves safety properties of code

Conclusion
Best approach is combination of
security mechanisms
 No techniques can protect users from
social engineering attacks
 User education is the only way to
combat mobile code attacks that are
based on social engineering

References
“Mobile Code Security”, Aviel D. Rubin
 “Formal Aspects of Mobile Code
Security”, Richard Drews Dean
 “Mobile Code and Security”, Gary
McGraw, Edward W. Felten
 “Securing Systems Against External
Programs”, Brant Hashii, Manoj Lal,
Raju Pandey and Steven Samorodin
