Mobile Code Security Yurii Kuzmin What is

Mobile Code Security Yurii Kuzmin

What is Mobile Code? Term used to describe general-purpose executables that run in remote locations. n Web browsers come with the ability to run general-purpose executables. n The executable can be written by anyone and executed on any machine that runs a browser. n Same code can be executed on any platform regardless of the operating system and hardware architecture. n

History n n n Concept is not new Several object-based systems are well established (CORBA) Hot. Java – 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 n n n 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 n Sandbox Model n Code Signing n Hybrid: Sandbox and Signatures n Firewalling n Proof-Carrying Code

Sandbox Model n 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 n Java interpreter inside Internet browsers – Each implementation of interpreter has a security policy – Policy explicitly describes the restrictions

Sandbox Model n Components of Java Interpreter – Class loader – Verifier – Security manager

Class Loader n Special Java object that converts remote bytecode into data structures representing Java classes n The only way to add remote classes to machine’s local class is via the class loader n Class loader creates a name space for downloaded code, local names are given priority, so remote classes cannot overwrite local names.

Verifier n Performs static checking on the remote code before it is loaded n 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 n Provides flexible access to potential dangerous system resources n Security Manager classes represent a security policy for remote applets

Security Manager Public boolean AAA(Type arg 1){ Security. Manager security = System. get. Security. Manager(); if (security != null){ security. check. AAA(arg 1); } } Example is taken out of “Mobile Code Security” by Aviel D. Rubin

The Sandbox Model n Error in any security component can lead to a violation of the security policy n 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 n The client manages a list of entities that it can trust. n When a mobile executable is received, the client verifies that it was signed by an entity on the list n If so, then it is run, most often with all of the user’s privileges n Used by Active. X

Code Signing n Trusted code runs with full user’s privileges, or it doesn’t run at all n If an intruder can change the policy on a user’s machine, the intruder can then enable the acceptance of all Active. X content. n Legitimate Active. X program can open the door future illegitimate traffic

Hybrid: Sandbox and Signatures Attempts to merge benefits of the sandbox model with code signing n Digitally signed applet is treated as trusted local code if the signature key is recognized as trusted by the client system that receives it n Client downloads an applet and then consults a policy table for every signed applet n Trusted applets can access file system, establish network connection and do other applications that are restricted by sandbox n

Firewalling n Selectively choosing whether run or not to run a program at the very point where it enters the client domain n Web proxy or firewall can try to identify Java applets, examine them, and decide whether or not to serve them to the client n Firewall approach assumes that applets can somehow be identified

Firewalling n 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 n Techniques that they use are confidential n Halting problem – there is no generalpurpose algorithm that can determine the behavior of an arbitrary program.

Firewalling n 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 Playground 8. I/O Load applet Proxy 2. Request for Page 3. Page 5. Request for Applet Change I/O 7. Modified Applet 6. Applet WEB Browser

Firewalling n The playground architecture trusts small graphics packages because it’s easy to analyze n More dangerous and untrustworthy mobile code has no access to meaningful resources n This approach requires bytecode modification and cannot be used in combination with the usual approach to code signing

Proof-Carrying Code n Is an active area of research today n Technique for statically checking code to make sure that it does not violate some safety policy n Some programs can construct a proof that they do not contain any buffer overflows n Proves safety properties of code

Conclusion n Best approach is combination of security mechanisms n No techniques can protect users from social engineering attacks n User education is the only way to combat mobile code attacks that are based on social engineering

References n “Mobile Code Security”, Aviel D. Rubin n “Formal Aspects of Mobile Code Security”, Richard Drews Dean n “Mobile Code and Security”, Gary Mc. Graw, Edward W. Felten n “Securing Systems Against External Programs”, Brant Hashii, Manoj Lal, Raju Pandey and Steven Samorodin