Who Else Wants To Be Successful With GFA

1. Mobile Code Click on Java, JavaScript, ActiveX

2. Introduction • Mobile code: A term that describes any software that is mobile, being passed from one system to another. In particular, it is used to describe applets within web browsers based upon Microsoft's ActiveX, Sun's Java, or Netscape's JavaScript technologies.

3. Mobile Code Examples • Web Applets Mini-programs written in Java, which are automatically loaded and run on being named in an HTML document. A document can include a number of applets. These may be sourced from a number of different servers and run without the user being aware of them.

4. Mobile Code Examples (Continued) • Dynamic Email One proposal for the provision of dynamic email suggested incorporating Safe-TCL scripts as components of MIME email. These scripts could be run either on mail delivery, or when the mail is read by the recipient.

5. Low-level Security Issues • The use of 'mobile code' raises a number of obvious security issues: • access control - is the use of this code permitted? • user authentication - to identify valid users • data integrity - to ensure the code is delivered intact • non-repudiation of use of the code - for both the sender and the receiver especially if its use is being charged • data confidentiality - to protect sensitive code • auditing - to trace uses of mobile code

6. Mobile Code Safety • The prime focus of this paper is on the techniques which can be used to provide for the safe execution of imported code on the local system. This has to address threats due to rogue code being loaded and run. Of course in many ways, these problems are not new: they have been a key component of operating systems design on multi-user systems for many years. The traditional approach to addressing these problems has been to use heavy address space protection mechanisms, along with user access rights to the file system and other resources. The difference between the traditional problems and those posed by mobile code is one of volume and responsiveness.

7. Mobile Code Safety (Continued) • Mobile code is intended for quick, lightweight execution, which conflicts with the cost of heavy address space mechanisms in most current operating systems. In additon, each mobile code unit can, in one sense, be thought of as running as its own unique user, to provide protection between the various mobile code units and the system. Traditional methods of adding new users cannot cope with this demand.

8. Mobile Code Safety (Continued) The types of attacks which need to be guarded against include: • denial of service • disclosure of confidential information • damage or modification of data • annoyance attacks Now More

9. Resource Access & Safety • , the issue of safe execution of code comes down to a concern with access to system resources. Any running program has to access system resources in order to perform its task. Traditionally, that access has been to all normal user resources. 'Mobile Code' must have restricted access to resources for safety. However, it must be allowed some access in order to perform its required functions. Just which types of access and how these are to be controlled is a key research issue.

10. Resource Access & Safety The types of resources to which access is required include: • file system • network • random memory • output devices (entire display, various windows, speaker) • input devices (keyboard) • process control (access to CPU cycles) • user environment • system calls

11. Granting Access to Resources • One of the key issues in providing for safe execution of 'mobile code' is determining exactly which resources a particular code unit is to be granted access to. That is, there is a need for a security policy which determines the type of access of any 'mobile code' unit. This policy may be:

12. Granting Access to Resources (Continued) • fixed for all 'mobile code' units • very restrictive but easy, and is the approach currently used to handle applet security in web browsers such as Netscape • that the user verifies each security-related access request • relatively easy, but rapidly gets annoying, and eventually is self-defeating when users stop taking notice of the details of the requests (whilst there is a place for querying the user, it should be used exceedingly sparingly) • to negotiate for each 'mobile code' unit • much harder as some basis is needed for negotiation, perhaps based on various profiles, but ultimately this is likely to be the best approach

13. Granting Access to Resources (Continued) • In the longer term, some mechanisms are needed to permit negotiation of appropriate accesses. How this is expressed is, I believe, one of the key research issues. Initially this is likely to be based on a simple tabular approach based on the various categories mentioned above. While adequate for the simplistic applets seen to date, this is unlikely to be sufficient for more complex 'mobile code' applications.

14. Granting Access to Resources (Continued) • For these, some fairly powerful language is going to be needed to express the required types of accesses, along with a means of reasoning about those requests. For example, consider a simple 'mobile code' text-editor: it should be able to change any textual file specified by the user, have access perhaps to a preferences file, but otherwise be denied access to all other files. How can this be expressed and reasoned with? This is an area that needs considerable additional work, but will be a key to the successful use of 'mobile code'. Click on

15. Mobile Code Technologies Embedded Script (JScript /VBScript): Internet Explorer includes a built-in interpreter to parse Jscript or Visual Basic scripts (VBScript) embedded within web pages. These scripting engines provide the "glue" to manipulate other objects on the web page. Both scripting engines offer common programming constructs to control program flow (e.g. If, Then, Else, For, Do, etc), perform simple mathematical functions, evaluate conditions, and manipulate data types. In addition, these languages offer the ability to load objects, such as ActiveX controls and Java applets, call methods on them, or set and get their properties. On the Microsoft Windows family of operating systems both scripting engines also include at least one "built-in" object, the FileSystemObject, which can be called to manipulate files or directories on the local file system as long as those scripts aren't being run from a web page.

16. Mobile Code Technologies (Continued) ActiveX Controls: The Component Object Model (COM) is Microsoft's architecture for creating programming objects that can be reused and provide services to other programs. Most of Microsoft's productivity applications are composed of many COM objects, such as Microsoft Word, Excel, PowerPoint presentation graphics program, and Visio drawing and diagramming software. An ActiveX control is simply a COM object that is designed to be downloaded and used within web pages. Once an ActiveX control is installed on the system it runs directly on the workstation in the security context of the web browser (normally the logged on user).

17. Mobile Code Technologies (Continued) These objects can be scripted to perform operations by calling their properties and methods from embedded script within the web page. An ActiveX control can perform any operation the user can. This makes ActiveX controls tremendously powerful for developing browser-based applications, but also makes them very dangerous if normal safeguards are not employed. When developing ActiveX controls, the developer must implement sufficient security measures to prevent their malicious use. If the control is not safe for use by any web page, its use from within Internet Explorer can be disabled or the tools described below can be used to allow the control to run only when appropriate.

18. Mobile Code Technologies (Continued) Java Applets: Like ActiveX controls, Java applets are reusable code modules that can be downloaded and installed on the client machine. They are created using the Java programming language and compiled into platform-neutral byte-code. Once downloaded to the client machine the applet is loaded into a Java Virtual Machine (VM) that interprets the byte-codes and runs the applet. The VM normally restricts what the applet can do, thereby limiting the functionality of the applet, but also limiting the amount of damage a potential attacker could do.

19. Conclusions • 'Mobile code' is here with increasing demands for its use. Safe execution of 'mobile code' implies a need for controlled access to resources, access which ideally should be negotiated for each 'mobile code' unit. The means for achieving this is a subject for considerable additional research. • Approaches taken so far to providing 'mobile code' include the distribution of source, intermediate code, or binary code, and the use of Just-In-Time compilers. • Experience with these systems has shown that safe and secure systems need both correct specification and implementation. There is still considerable research and development needed in these systems. However, I believe the goal of safe and secure 'mobile code' execution is reasonable and achievable.

20. References Click on Many more