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 general-purpose 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

Browser

Playground

Proxy

WE

B

1. Request for Page 2.Request for Page

3. PageLoadGraphicsServer

Loadapplet

Change<applet>tags

ChangeI/O

4. Modified Page

5. Request for Applet

6. Applet

7. Modified Applet8. I/O

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