1. Mobile Code Security Aviel D. Rubin, Daniel E. Geer, Jr. MOBILE CODE SECURITY, IEEE Internet Computing, 1998 Minkyu Lee 2007. 04. 23

2. 2 Contents Introduction The Sandbox Code Signing Hybrid: Sandboxes and Signatures Firewalling Proof-Carrying Code Conclusion

3. 3 Introduction Mobile code –Web browser come with the ability to run general- purpose executables. –Written by anyone, execute on any machine Security perspective –General-purpose scripts on the Internet opens up a world of distributed applications. –Nothing more dangerous than global, homogeneous, general-purpose interpreter. –In worst case, allow an attacker to run native code without any restrictions.

4. 4 Introduction (cont’d) Practical techniques for securing mobile code –Sandbox model Limiting the privileges of the executable to a small set of operations. –Code signing Obtaining assurance that the source of the executable is trusted. –Firewalling Examining executables as they enter a trusted domain and deciding whether or how to run them on the client –Proof-carrying code Mobile code carries with it a proof that it satisfies certain properties.

5. 5 The Sandbox The Sandbox model –Containing mobile code in such a way that it cannot cause any damage to the executing environment. –Usually, restricting access to file system and limiting the ability to open network connections. –The most widespread implementation Java interpreter inside Web browser –Adhere to a security policy Describe the restrictions that should be placed on remote applet.

6. 6 The Sandbox Security in Java interpreter –Three main components Class loader Verifier Security Manager

7. 7 The Sandbox Class loader –Any class loaded from the network requires an associated class loader (subtype of Classloader) –The only way to add remote classes to a machine’s local class hierarchy is via the class loader.

8. 8 The Sandbox Verifier –Verifier performs static checking on remote code Is valid virtual machine code, Stack overflow, underflow Improper usage of registers Illegal conversion of data types

9. 9 The Sandbox Security Manager –Local classes are unrestricted –Remote classes are passed to security manager. –Classloader classifies operations as safe or potentially harmful. Safe operations are always allowed Potentially harmful ones defer a decision to the security manager. In effect, the security manager classes represent a security policy for remote applet.

10. 10 The Sandbox

11. 11 The Sandbox Problem with Sandbox –Error in security components can lead to a violation of the security policy. Two types of applets cause most problems –Attack applets Try to exploit software bugs in clients’ virtual machine. Breaks type safety, and buffer overflows –Malicious applets Designed to monopolize resources Cause inconvenience rather than actual loss.

12. 12 Code Signing In code-signing –Client manages a list of trusted entities. –When mobile code is received, the client verifies that it was signed by an entity on the list. –If so, it run most often with all of the user’s priviliges. –Microsoft Authenticode system for ActiveX.

13. 13 Code Signing Problems with code signing –ActiveX with full privileges. A legitimate ActiveX can easily open illegitimate traffic –Delayed attacks Malicious code can plant all manner of delayed attacks. Later, when problem occur, there is no way to tie them to back to a given ActiveX control run at some point in the past.

14. 14 Code Signing Trust model –Code-signing assumes It is possible to distinguish trustworthy from untrustworthy authors of mobile code Trustworthy authors are incorruptible.

15. 15 Hybrid: Sandboxes and Signatures Digitally signed applet (in JDK 1.1) –Treated as local code, if signature key is recognized as trusted. –This allows applets to access file system and establish network connections –However, same security problem inherent in the Active-X code signing approach.

16. 16 Hybrid: Sandboxes and Signatures Flexible approach (in JDK 1.2) –In JDK 1.1, applets are still either totally trusted or severely limited. –Subjects all classes : local, remote, signed, unsigned –A security policy defines the access each piece of code has to resources on the client. –For example, signed code can run with different privileges based on the key. Trust model –All code is untrustworthy except for code from trustworthy supplier who is incorruptible.

17. 17 Firewalling Firewalling approach –Selectively choosing whether or not to run a program at very point where it enters the client domain. –Malkhi et al. approach Java applets are divided into graphics actions and all other actions The former run on the client machine The latter run on a sacrificial playground machine

18. 18 Firewalling

19. 19 Proof-Carrying Code Proof-carrying codes (PCC) –Statically checking code to make sure that it does not violate some safety policies. –Untrusted code producer must supply with the code a safety proof that attests to the code’s adherence to a previously defined safety policy.

20. 20 Proof-Carrying Code Overview of Proof-Carrying Code

21. 21 Conclusion Each techniques provides different, and best approach is probably a combination of security mechanisms. None of the techniques can do much to protect users from social engineering attacks. User education is the only way to combat mobile code attacks that are based on social engineering.