Mobile Code Security

1. Mobile Code Security Yurii Kuzmin

2. 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.

3. 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)

4. 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

5. Security Techniques • Sandbox Model • Code Signing • Hybrid: Sandbox and Signatures • Firewalling • Proof-Carrying Code

6. 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

7. Sandbox Model • Components of Java Interpreter • Class loader • Verifier • Security manager

8. 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.

9. 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

10. Security Manager • Provides flexible access to potential dangerous system resources • Security Manager classes represent a security policy for remote applets

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Firewalling • FinjanSoftware 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.

18. 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

19. Proxy Browser 1. Request for Page 2.Request for Page Change <applet> tags 4. Modified Page 3. Page Load Graphics Server WEB 5. Request for Applet Playground Change I/O 6. Applet Load applet 8. I/O 7. Modified Applet

20. 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

21. 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

22. 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

23. 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