Deconstructing Windows Mobile

Last month's issue of Virus Bulletin contained an interview conducted by Juha Saarinen with Microsoft representative Brett Roberts about the update issues surrounding Microsoft's Mobile operating system platforms (see VB, July 2005, p.13). However, Mr. Roberts' answers were left largely uncontested, so the following are a few points that I felt were missing from the article.

Juha's first question related to whether (unlike on the PC platform) it is safe to run a Windows Mobile device without updates. However, the answer provided by Mr. Roberts did not include a discussion of securing the operation of the device - for example, what is done or offered by the OS, so that a malevolent piece of software (such as one that always shuts off the device and/or reinstalls itself during reboot) cannot prevent the user from regaining full control of his/her device?

Windows Mobile (WM) has no 'restricted' or 'safe-mode' to allow rebooting while skipping the normal startup programs, thus allowing the recovery and cleanup of an infected system. For a common user the dreaded operation that in Windows CE parlance is known as 'hard-reset' - a complete memory re-initialization and reset to factory defaults (which also implies 100 per cent data loss) - appears to be the only available 'solution' to resolve such a situation ^[1].

Furthermore, there is no encapsulation of processes that would ensure limited threats from flawed drivers or other third-party software that comes pre-installed on the system. For example, some Bluetooth stacks are well known to have security holes. There is no OS support for executing certain parts of the software in a restricted or limited mode to prevent access to and/or modification of critical OS data, amongst other things.

Mr. Roberts emphasizes the rather trivial point that not getting infected is the best way to stay uninfected - i.e. do not download and/or install 'doubtful' software. This needs to be emphasized because, once the system has been infected, Windows Mobile does not have any further system-internal protection, access controls, or any other safety barriers. However, a program does not even have to be explicitly malevolent in order to cause disruption. Just a simple program error can be enough to wipe out the entire system and/or render it useless (by causing endless reboots, etc.).

Further on in the Q & A, Mr. Roberts states that it is difficult, if not impossible, to distribute patches directly to end-customers due to the diverse nature of Windows Mobile devices. He claims that Microsoft depends on the hardware manufacturers and OEMs to integrate and forward its patches.

Alas, the hardware manufacturers and OEMs seldom feel the need to forward these patches with the due urgency. My own experience (with multiple generations of devices from Casio, Toshiba, Siemens and several Compaq/HP iPAQs) is that the release of such updates takes at least two, but more typically three to six months, during which time users remain exposed and essentially can do nothing about it. The burden, therefore, is on the user to avoid being exposed to malicious software. This problem is revisited throughout the article.

However, I find this situation hard to accept, since many sources indicate that, when a manufacturer requests to license Windows Mobile, Microsoft has a pretty strong say in what a device must offer, how it must appear and behave, what applications must be included and which must not come pre-installed, etc.

Given such power, it would seem comparatively easy for Microsoft to enforce a standardized API, via some code package (of course sealed, signed, etc.) that would be able to reflash at least parts of the OS without requiring an OEM's further blessing and support.

Given that we have already gone through several generations of Windows CE / Handheld PC / Pocket PC / Windows Mobile and whatever-they-name-them-today devices, there would have been ample time to require such a capability and thus I rather suspect that the issue was not considered very important or urgent (to date). I wish the Mobile group had exhibited the same 'great work by the Windows division on Windows update technology'.

Mr. Roberts points out that the Windows Mobile platform can also be operated as a closed platform (using techniques from the Trustworthy Computing Initiative), where operators or businesses have full control over what software can be installed to a device, thus minimizing the risks. This, of course, is just a way of sidestepping the real problem by merely preventing discretionary execution of code - and due to its restrictive nature this is not a popular or widespread approach.

Furthermore, operating as a closed platform to minimize risks is not 100 per cent secure, since (as previously indicated) the code does not even have to be malevolent to cause problems; a simple bug is enough!

A controlled environment simply reduces the probability of software bugs by making the assumption that approved applications are tested more thoroughly before they are widely deployed, especially regarding their interaction with other controlled applications. This is probably a faulty assumption and a dangerous one.

Finally, today's PDAs are still far less continuously connected to the Internet than desktop systems, and in many cases they connect to the Internet only via some 'sync partner'.

As a result, there is only a relatively small population of attackable devices available on the Internet at any point in time, and the channels via which worms and viruses would have to travel to infect them are convoluted and contain barriers that need to be crossed. But, with more and more Windows Mobile devices being constantly and directly connected to the Internet (thanks to integrated WiFi and/or built-in high-speed phone capability, e.g. GSM/GPRS or UMTS, and especially with billing models based on generated traffic rather than connection time) this picture may change quickly and dramatically.

There is one major risk on the horizon for Windows Mobile, that is quite troubling and that was not mentioned at all in Juha's article: most of the newer Windows Mobile devices have a large flash memory in which not only do they store the OS and the pre-installed applications, but a part of the memory (usually a quarter to a half) is also made available to the user as a place where he/she can install applications and store data. The feature was meant originally to provide users with a place where they could store data that would be safe even when the device runs out of battery and all normal RAM content is lost.

The flash memory on such devices is, in effect, split into two 'partitions'; one for the OS and pre-installed applications and one for user data. However, the boundary between these two partitions is purely virtual and can be shifted, thereby allowing a newer (and most likely larger) version of the OS to consume a slightly larger fraction of that memory than the previous one.

Such a mechanism also means that, given the device-specific or brand-specific knowledge on how to write data to the flash, viruses, too, could 'burn' themselves into the OS area of the 'ROM' such that they would survive hard-resets, i.e. complete 'memory loss' and reset to factory defaults. Such viruses would not be removable with any means available to the normal user, meaning that an infected device would have to be sent back to the manufacturer for repair.

That, together with the growing CPU ^{[2] [3]} and architectural homogeneity of Windows Mobile devices, will become a major threat in the probably not-so-distant future. The requirement for hardware-assisted memory protection and OS-supported security models will thus soon become a requirement for Windows Mobile-based PDAs and phones.