Chapter 10: Client-side Security

In this chapter, we focus on client-side security in general, and the security implications of executable (or active) content in particular. After a brief introduction in Section 10.1, we elaborate on binary mail attachments in Section 10.2, helper applications and plug-ins in Section 10.3, scripting languages in Section 10.4, Java applets in Section 10.5, and ActiveX controls in Section 10.6. In Section 10.7, we elaborate on security zones as implemented, for example, in Microsoft Internet Explorer. In Section 10.8, we discuss the implications of executable content for firewalls, and in Section 10.9, we draw some conclusions. It is reasonable to expect that client-side security problems as outlined in this chapter will become a more and more important topic in the future.

10.1    Introduction

One of the most dangerous things that can be done with a computer system connected to a network (e.g., the Internet) is to download an arbitrary piece of software and execute it locally. This is because many operating systems place no limits on what a program can do once it starts running. Consequently, when a user downloads an arbitrary piece of software and executes it locally, the user places himself or herself entirely in the hands of the corresponding programmer or software developer (note, however, that this is true not only for downloaded programs, but also for any program that is executed locally).

In practice, most programs that are downloaded behave as expected. But the point is that they don t have to and some don t. Some programs have bugs and programming errors that cause computer systems to crash. Other programs have bugs that may be exploited by hackers. Still other programs are malicious and may do damaging things, such as erasing hard disks or transmitting confidential data to some arbitrary locations on the Internet.

In general, the ultimate goal of a (software) attacker is to be able to execute a program of his or her choice on a computer system of his or her choice without the corresponding victim s knowledge. Once this ability is achieved, any other attack is usually feasible and may be mounted. The easiest way for an attacker to accomplish this goal is to provide a user of the computer system with some program code to execute with his or her privileges.

One would think that an easy way to protect a computer system against this type of attack is to inspect all downloaded programs to see if they contain malicious software. Unfortunately, it s impossible to determine what a computer program will do without actually running it. What s possibly even more worrisome is the fact that it s often impossible to determine what a program is doing while or after it is running. Programs may have many ways of hiding the functions they actually implement.

Even sophisticated operating systems with memory protection and other security features, such as the Windows or Linux operating systems, offer users little protection against malicious programs that they download and execute locally. That s because once the program is running, it typically inherits all the privileges and corresponding access rights from the user who invoked it. No commercially deployed operating system allows users to create a restricted area in which potentially malicious programs can be executed (similar to the Java sandbox addressed below). To make things worse , Internet users have been told for years to download various programs and execute them locally without asking any further questions. For example, browsers as well as helper applications and plug-ins are typically distributed by having users download, execute, and install particular software modules. The same is true for bug-fixes, patches, and system upgrades. This user behavior automatically leads to security problems.

In general, executable or active content embraces a large collection of technologies that make the Internet (including the WWW) more interesting and interactive, but also more dangerous. In short, executable or active content is downloaded into client software where it is executed locally. Sometimes the local execution requires a user initiative, but sometimes it doesn t. Examples of executable or active content include binary mail attachments, data files for word processors and other office automation programs, Java applets, ActiveX controls, as well as programs written in scripting languages, such as JavaScript or VBScript.

Well-written executable or active content may enhance Internet sites and corresponding Web pages with animations, interactive games , and serious applications, such as database browsers or groupware applications. In fact, the entire idea of network computing was centered around the idea of well-written (and well-intended) executable or active content. However, one question that arises immediately is how to decide whether executable or active content is well-written (and well-intended). If the content is buggy or not well-written , it may contain security holes that may compromise the user s privacy or the integrity of the data stored on the computer system. Even more worrisome, executable or active content written for malicious purposes may attempt to damage the computer system or seek to gain illegitimate access to the local network. Unfortunately, it has been shown that deciding whether an arbitrary piece of software is malicious or includes malicious code is difficult (to say the least) [1].

From a theoretical point of view, the security problems related to executable or active content occur because there is no fundamental difference between a program (representing an active component) and data (representing a passive component) with regard to its internal representation within a computer system. In fact, they are both internally represented as a series of zeros and ones. Furthermore, in the traditional approach to designing and building computer systems, ^[1] programs and data are treated equally and stored in the same memory. ^[2] This allows a program to modify both data and programs (eventually modifying itself). For example, most computer viruses take advantage of the fact that they can manipulate and directly modify program code. But in spite of these theoretical considerations, we have become accustomed to the clear distinction between active programs and passive data. Unfortunately, this distinction has been blurred in the recent past. Things that we used to assume are safe, such as data files for word processors, can now contain and use a macro virus to attack our systems. As a matter of fact, macro viruses that infect data files (or rather, the macro programming features of these data files) are spreading very rapidly throughout the Internet and the WWW. To make things worse, Web pages can contain executable or active content that is entirely transparent and invisible to Web users.

The WWW in general, and the deployment of executable or active content in particular, have also changed the way software is being distributed and sold globally. Instead of having users physically walk into trusted neighborhood retail stores and buy shrink-wrapped software packages, they download the software they want from corresponding Web sites (i.e., Web-based software distributors). The point that must be kept in mind is that there are all kinds of distributors . Some of them are good and distribute software that is perfectly secure and safe, whereas others are not so good and distribute software that is either not secure and safe (because it contains, for example, bugs and programming errors) or ”even worse ”malicious (because it contains, for example, a Trojan horse). The point is that it is hard to tell the difference without actually running the software (it may even be difficult to tell the difference after the software has run). To make matter worse, there is hardly any traceability or accountability in the Web-based software distribution model. This makes liability issues very difficult to address and resolve.

Against this background, it is important to note that the WWW and its possibility to distribute executable or active coolant has shifted the main security problem from protecting the server against potentially malicious clients to protecting the client against potentially malicious servers. One way to protect the client is to use secure software distribution systems that provide something conceptually similar to a digital shrink-wrap . For example, a group of researchers at Bell Communications Research (Bellcore) developed and ran a secure software distribution system called Bellcore s Trusted Software Integrity System (BETSI) in the early 1990s [2, 3]. BETSI used PGP and distinguished between authors and users:

• Authors were people or companies (e.g., Microsoft) who wished to securely distribute software on the Internet (i.e., software publishers).

• Users were people who wished to download software that has authenticity and integrity guarantees .

Authors had to register with BETSI in advance. Once they were registered, they could communicate securely with a BETSI server because they shared authentic and valid copies of one another s PGP public keys. If an author had a file (e.g., a software package) he or she wanted to securely distribute, he or she created an integrity certificate request for it. The request contained information, such as the author s name, the file s name , and the MD5 hash value of the file. The author then digitally signed the request with his or her private PGP key and sent the result to the BETSI server. The BETSI server, in turn , verified the message and its PGP signature. If the message was valid, BETSI sent back to the author an integrity certificate that was digitally signed. The integrity certificate basically claimed that the named author was registered and that he or she had properly requested a certificate linking a certain hash value to a specific file (or filename). The author then verified the integrity certificate and was free to make it publicly available (e.g., together with the file).

On the other side, each BETSI user was required to have PGP, an implementation of MD5, and an authentic PGP public key from the BETSI server. When he or she downloaded a file, he or she also got an integrity certificate for this file. He or she could then verify that the file had not been (intentionally or unintentionally) modified, by verifying the integrity certificate with BETSI s public key and computing the hash value of the corresponding file. If the integrity certificate was valid, the user could be sure that the file was authentic and had not been modified.

Unfortunately, the use of BETSI or any other secure software distribution system has never really taken off in the commercial world. This is slowly beginning to change with the use and deployment of code signing technologies and systems (as discussed later in this chapter). These technologies and systems are conceptually similar to BETSI. ^[3]

In the following sections, we overview and briefly discuss the potential problems related to the various classes of executable or active content. In particular, we elaborate on binary mail attachments, helper applications and plug-ins, scripting languages, Java applets, and ActiveX controls.

^[1] This approach is generally attributed to John von Neumann. You may refer to the URL http://www-groups. dcs.st-andrews.ac.uk/history/Mathematicians/Von_Neumann.html to get a comprehensive overview about John von Neumann s work.

^[2] Note that this approach applies to Von Neumann architecture machines , but it does not necessarily apply to other machines. For example, in a Harvard architecture machine , programs and data are stored in separate memories. The reason for this separation is efficiency; it has, however, also a positive side effect on security.

^[3] This is the reason why BETSI is discussed in the first place.