Problems with Securing Mobile Code

for RuBoard

There are numerous well-supported forms of mobile code applications or components , each with its own benefits and drawbacks:

• Downloaded executables

• Source code

• Scripts

• Java applets

• ActiveX controls

Downloaded Executables

By downloaded executables, I mean files compiled to target specific architectures and operating systems. For example, notepad.exe is a commonly used executable file found in Windows. Downloaded executables are found all over the Internet. There are whole Web catalogs of programs for Windows, Macintosh, Linux, and other platforms. In addition, e-mail and peer-to-peer sharing mechanisms, such as Napster, have made it easy for users to share executables with each other.

Downloaded executables are good for the following reasons:

• They are very easy for end users to handle, because mobile code hosts can be configured to run them automatically.

• Executables are highly tunable by developers. They can be made to run with small footprints, fast execution, or other desired parameters.

• Executable files are well- understood entities. Some assurances about their runtime behavior can be made by using digital signatures, checksums/hashes, and virus checkers.

Executable files have the following problems:

• It can be very difficult to tell what an executable will do before it runs. From a security perspective, this is dangerous, because the code can contain some type of malicious code. Many e-mail viruses are spread by people who run seemingly harmless executable attachments.

• Executables must be recompiled for different architectures and operating systems. Thus, every version of a file you distribute must be recompiled for every target platform.

• Due to security issues with downloaded executables, it is common for companies to block some of their distribution mechanisms (such as filtering on e-mail servers).

Source Code

Source code is a common way to distribute applications in the UNIX/Linux world. Because there are numerous flavors of related operating systems with different hardware architectures and capabilities, source code can be compiled into working applications on each machine. Because Windows computers are sufficiently different from UNIX/Linux machines, tend not to have compilers on each machine, and can usually execute the same binaries, source code is a less common way to distribute applications for Windows.

Applications distributed via source code have the following benefits:

• With source code, it is easier to tell what resources are used on the computer when compared to most of the other formats mentioned. Source code can be analyzed more simply than compiled files, although it is still too daunting for average computer users.

• Application behavior can be tailored by end users to suit their specific needs. If you have the source code for an application, you can add, remove, or change capabilities, which is generally not possible with most of the other mentioned mobile code formats.

• Some kinds of application patches (for example, some security fixes) can be easily distributed with little data using source code. Source modifications are commonly shared and can be easily applied to application source code. Then, a user just has to recompile an application to get the updated behavior.

Distributing source code has the following pitfalls:

• There is no automatic execution of code. There is always a manual step of compilation before the application can be run. For many end users, this is too technically daunting to be practical.

• Compilers are not found on many machines. Thus, it is not possible to run applications on most machines by distributing source code alone.

• Even on machines where compilers exist, available headers, libraries, and versions will vary. Thus, an application that builds on one computer may not build properly on a very similar one.

• Owners of source code often do not want to give it away. Profits are difficult to make if you freely hand over all your intellectual property.

Scripts

Technically, scripts are just a certain class of source code. However, for this discussion, source code means files that are compiled to machine-level instructions, while scripts are interpreted by a scripting engine at execution time.

Scripts are text files that contain program instructions written in a specific scripting language. Some typical scripting languages are Perl, Python, ECMA Script, JavaScript, VBScript, and Tcl.

Some benefits of scripts include the following:

• Scripts are typically smaller than any of the other distribution methods listed here. A script may only be a few lines of text.

• Writing a simple application in a scripting language is typically easier than writing the same application in a compiled language.

• If scripting engine functionality is standardized across different platforms, the same script can run on multiple platforms. This is quite different from source code mentioned previously.

• Scripts are easy to read, so it is usually simple to see how they are using resources. Also, scripting engines can be specially tailored for mobile code hosts to remove potentially dangerous functionality.

Scripts have the following problems:

• Scripts require the presence of a scripting engine before they can execute. Thus, mobile code hosts will have to package the scripting engine for each scripting language they want to support.

• Scripts are interpreted rather than compiled, so they typically do not run as fast as applications using other mentioned distribution methods.

• The power of a scripting engine limits the power of scripts using that engine. Complex applications can be very difficult to write due to limitations of scripting engines.

Java Applets

Java applets came about as the power of the Java runtime was applied to Web browsers. They are somewhat like a combination between downloaded executables and scripts. They are compiled like executables, but they still run on a virtual machine, which is similar to a scripting engine.

Java applets have the following benefits:

• If Java applets are written without using platform-specific extensions, the same Java applet can run on different platforms.

• Typically, a Java virtual engine packaged with a mobile code host is written so that only safe functionality is exposed. That allows users to securely run Java applets from untrusted sources.

• The Java runtime provides a type-safe environment. This means it is possible to easily verify many security properties of Java applets. For example, we could verify that an applet doesn't perform invalid casts or access arbitrary memory.

The following are some problems with Java applets:

• Java applets can generally only be written in the Java language. While some software exists that allows developers to write them in other languages, most Java runtime environment developers are primarily trained in the Java language.

• Several Java decompilers exist that allow a user to convert a Java applet back to Java language source code. This is a threat to the applet developers' intellectual property.

• The same virtual machine that only provides safe functionality for applets also restricts their possible utility. There is no good way to differentiate between trusted and untrusted applets so that we can grant the trusted applets greater freedom.

ActiveX Controls

ActiveX controls have been around since early 1997 (http://www.microsoft.com/com/presentations/default.asp, presentation titled "An Overview of ActiveX"). They are basically COM controls that have been packaged in a way to ease downloading, scripting, and execution in Web browsers (though they cannot execute alone). They were developed by Microsoft as a way to make the client-side, Web programming experience powerful and simple.

Some benefits of ActiveX controls are as follows :

• They are compiled, executable files, so they have all the strengths of downloaded executables.

• Because they are COM controls at a base level, ActiveX controls can be used as components in non-Web applications in addition to Web browsers.

• They have some attempts at security built in. If a control is not marked as "safe for scripting," it cannot be used in a Web browser. This allows ActiveX controls to be safely created and deployed with functionality that is potentially dangerous for mobile code.

• Authenticode signing is often used for downloaded controls, so users can frequently tell who authored a specific control and make trust decisions based on that.

ActiveX controls have the following drawbacks:

• ActiveX controls are generally only supported by Windows operating systems.

• The "safe for scripting" determination of a control is made by developers, not users or administrators. Also, after the control is compiled, this setting cannot be changed. Thus, any "safe for scripting" control written by a careless or malicious developer cannot ever be safely used by a Web browser.

• ActiveX controls that are not Authenticode signed are usually blocked from executing. Thus, most downloaded controls are signed. However, even signed ActiveX controls usually require a manual trust decision at execution time from the user. Because most users don't comprehend the ramifications of the "run"/"don't run" decision, Authenticode security is arguably not very strong.

for RuBoard