Introduction

A new threat model exists for malicious code and virus attacks on portable devices. These threats are no longer contained to common desktop environments. Portable devices employing custom electrical circuit design, product-specific capabilities, and embedded operating systems are commonplace in corporate infrastructure. It is increasingly common for vendors to introduce these devices to an environment before the security ramifications have been examined. PDAs are now being deployed by corporations for security-related applications. Added functionality of wireless technologies, such as infrared (IR) and radio frequency (RF), increases risk areas. New classes of malicious code attacks exist that cannot be detected or contained by current methods long deployed in desktop environments. In addition, the notion of cross-architecture pollination very quickly becomes a mainstream concern. [5] provides an overview of some malicious threats to PDAs and can be read in parallel with this text.

Many users do not recognize that the information stored on their PDA is open to compromise by unauthorized users, and hence do not treat the data stored on their handhelds with the same care as they do on their desktop. Our research discusses the underlying problem that security is not properly designed into the Palm OS platform. Although Palm OS is not presented as a secure operating system, if the device is being used for security purposes, which is becoming prevalent in corporate environments, there are a number of risk areas to be concerned with.

For example, Palm OS offers a built-in Security application which is used for the legitimate user to protect and hide records from unauthorized users by means of a password. In all basic built-in applications (Address, Date Book, Memo Pad, and To Do List), individual records can be marked as ``Private'' and should only be accessible if the correct password is entered. Another example is the ``Beam Bit'' flag contained in every application database, which is used to prevent the information from being transferred, or ``beamed'', to another device via IR. Honoring the state of the Beam Bit is purely voluntary by the executing application. These simplistic mechanisms lull the user and perhaps some developers into a false sense of security. There should be strong warnings by the vendor that these mechanisms are trivially bypassed (as in §4, §5, and with [14]), so users and developers can plan for and workaround the lack of security. Security-based applications exist on the Palm OS, such as software authentication tokens, cryptographic key storage, and encryption products, all that require a secure operating system in order to be properly implemented. Without proper protection mechanisms in place, applications that rely on the secure storage of secret components are severely at risk of compromise.

The properties of malicious code, particularly viruses, can be distilled into four stages: Infection, Storage, Triggers, and Actions. In this paper, the design of Palm OS is analyzed with respect to each of these stages. A number of weaknesses and attack vectors have been identified from both classical and new technology areas and we offer insight into addressing these problems in design and usage. In no way is this text exhaustive in enumerating attacks. Rather, an attempt is made to educate the reader on the design flaws and new threats that exist on portable devices.

In §2, we provide a summary of the various types of malicious code: viruses, Trojan horses, and worms. §3 describes the typical design and architecture of a PDA, focusing on the Palm OS software and hardware platform. §4 and §5 detail the risks of weak system password storage and backdoor debug modes inherent in Palm OS. §6 through §9 address the four stages of the virus lifecycle with respect to Palm OS.

We conclude that current state-of-the-art portable devices are not equipped for the threat of viruses or other malicious code components. In addition, it becomes apparent that threat models and attack vectors these devices introduce are not yet taken into account by product designers and anti-virus vendors¹. Hopefully, the various sections of this paper can act as a road map towards the future design of these devices and aid in security awareness for existing deployments.