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 users 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 machines 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 users privileges Used by ActiveX

Code Signing Trusted code runs with full users privileges, or it doesnt run at all If an intruder can change the policy on a users 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 WEB 1. Request for Page2.Request for Page 3. Page Load Graphics Server Load applet Change tags Change I/O 4. Modified Page 5. Request for Applet 6. Applet 7. Modified Applet 8. I/O

Firewalling The playground architecture trusts small graphics packages because its 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