Attacks on iPod

‘What’s wrong with your machine?’

‘Nothing, I just want to find out what type of network adapter needs to be installed in this PC to get Linux to work.’

‘Oh. What’s Linux?’

‘It’s an operating system developed in Finland…’

‘Aha,’ I said, and stepped outside to enjoy a cigarette at –15C .

This decade-old conversation soon came to my mind as I began installing Linux on my iPod to test run iPodLinux/Podloso, the first concept virus on this platform.

Many enthusiasts develop Linux for the iPod, which involves an enormous amount of work. One needs to reverse engineer the hardware and its firmware code to be able to build everything from the ground up. Needless to say, this is a major challenge. New hardware is released frequently with updated firmware code which is even encrypted in newer models in an attempt to discourage the iPod Linux developer community – but to no avail!

I love music, which explains why I have the largest collection of iPods one can imagine. Although I expected iPod threats from the very beginning, I was not too surprised that we hadn’t seen any five years after the iPod came out – by which time, Apple had sold 100 million iPod units worldwide.

At the heart of the iPod is the PortalPlayer (PP) SuperIntegration System-On-Chip [1]. This is a complete digital audio system featuring dual ARM microprocessors. The PP chip supports encoding and decoding of digital audio data directly to and from flash or hard disk.

PortalPlayer also supports a PP chip with an embedded OS that includes robust development tools, enabling custom feature sets and enhancements. This chip is designed to provide support for codecs and DRMs, and is amazingly capable. Among many other features, it supports real-time encoding of MP3 and ACELP.NET audio formats, as well as real-time decoding of MP3, WMA, AAC and ACELP.NET formats.

iPod devices come in a variety of flavours today, but the traditional systems have the basic bootstrap code in flash ROM, which reads the Apple application firmware stored on the disk and jumps to it. Obviously, this process can be hijacked just as easily as any other system’s boot process, and this is precisely what Linux does on the iPod. It puts a little extra boot code in place, which will optionally direct control either to Apple’s own firmware or to the Linux firmware to run either the apple-app UI, or first the Linux kernel, and then the Podzilla UI shell on top of it.

Obviously, there is a checksum function to verify that the content of Apple’s application is not altered. This checksum can easily be changed. All this is stored in a little partition of its own, starting typically at logical block 63, in the format of a simple file system. Not surprisingly, several versions of utilities have been released for the iPod, which can change the firmware resources and thus replace the familiar icons with the user’s choice.

The newer release of the firmware partition starts with a volume header, which has a pointer to a directory structure. The directory entry of the bootloader image contains the checksum of the file, as well as its start address on the disk.

Linux on the iPod saves a copy of the original firmware, and patches itself into the boot process by extending the original firmware code with its boot code and itself. Finally, it sets a new checksum in place.

It is plain to see that hostile code could also update itself into the firmware with extra code. This is exactly why I expected to see security threats, including viruses (worms), on the iPod. The iPod is basically a general computer which lacks documentation, and an open programmable API.

The format of the file system is either HFS+ or FAT32, depending on the host OS and the initial installations. In the end, with a bit of luck, you can install all the cool games that come with Linux. You can even install Nintendo NES games, which may come in handy when your two-year-old gets tired of Brick on his own Nano (or ‘Kenoo!’).

The early versions of Podzilla were not modularized. As a result, Podloso does not really have a chance to replicate on them – since it will not be loaded dynamically, but only by placing the virus in the module folder, for example with the installation of a game. The virus does not have any means to jump from the desktop to the iPod on its own, but as explained above, this could potentially be done. The most obvious method of attack is to install Linux on the connected iPod via a desktop-compatible virus, thus taking over the iPod world with Linux on the way. However, direct attacks could also be carried out.

Podloso is limited to Podzilla version 2. Early releases do not support module loads from /usr/lib/ folders dynamically, loading them instead during startup. Each module is in 32-bit ELF format and contains native ARM code. The ELF file is a relocatable image library stored with a .mod.o extension, and functions much like a DLL.

Modules are loaded by the pz_module_init() function of Podzilla 2. If a file named ‘Module’ is available with little information about its content, it will be loaded as long as the file appears to be compatible with the Podzilla release. In such a case, the init function of the module is triggered immediately after loading the module. In Podloso, this function is init_oslo(), which will follow the standard module format. It simply installs a menu handle with the name ‘/Extras/Demos/Oslo’, so the user will be able to run it later on. The virus follows the standard method to run a module, although this is not necessary.

Podloso requires the installation of its main file, the 6128-byte oslo.mod.o, into a folder under /usr/lib/. In addition, there is a module file, as well as a picture file called image.png, which need to be available in the same folder in order for the virus to execute its payload correctly.

When the user executes the Oslo module, the virus is triggered. The infection routine is very simple. It searches recursively for new files with .mod.o extensions to infect, which appear to be in ELF format according to their header.

Podloso is a little like a library infector, but it does not infect the library files properly. For each file, the virus copies itself to the top of the host program, just like a prepender virus, saving the original ELF module content after itself, and placing an ‘Oslo’ infection marker after that.

Eventually, all modules will have a copy of the virus at the start, and the content of the original module will no longer run. After running the virus, therefore, only one module name will be registered: that of the virus itself. However, Podzilla will dutifully display all the module names according to the text of module files, as if they loaded normally. In some versions of Podzilla, a number of error messages will be displayed.

It should be noted that the virus ignores read-only files, thus the file system flags could be used to help avoid infection.

Immediately after the infection function finishes, the virus is supposed to trigger its payload, which is to display a window showing a penguin and a short message. So far, however, only Konstantin Sapronov of Kaspersky Lab has been lucky enough to capture this elusive moment [2], which he says was often followed by a Linux crash on his 5.5 generation Video iPod.

I have installed Linux on each of the more than half-dozen different iPod editions that I currently own, and even made use of my friend’s devices [3]. On all of these releases I have attempted to bring Podzilla to the most recent version after installing the latest supported edition of the Linux kernel. On several of the devices, I got a warning from the installer stating that I was practically on my own, since they are not completely supported devices.

Only on a traditional iPod Mini edition did I finally achieve what seemed to be successful installation, with no warnings displayed. Yet as soon as the payload ran, either the virus hung or Linux crashed, displaying the system console on screen.

The error seems to be related to SDL, the graphical window library, which suddenly ‘deploys parachute’. In turn, the clean-up routine of the virus, cleanup_oslo(), is triggered by the exception handling, and the virus prints the following message to the console:

greetz:genetix,necro,wargame

After this, Linux needs to be rebooted.

It is possible that newer, unsupported kernel editions could resolve these problems, and this may be why the virus does work in certain environments. However, in most cases, Podloso will simply crash in the installations that people are most likely to be using. This says a lot about how difficult it is to support code on an unknown platform with all kinds of firmware flavours. The virus always infects each module on the device, regardless of the troubled payload routine.

Evidently, the virus is iPod-specific. Not only does it require iPod Linux to run, but it also requires the Podzilla 2 environment, since it is a Podzilla 2 module itself.

In this short section, I will discuss some of the attacks that have been carried out, or could be carried out, utilizing iPod devices.

The earliest attacks simply used the iPod as a USB disk drive, placing startup files on the execution path in the hope that a program or script will be triggered from the iPod upon its connection to the host. Such attacks typically look for confidential information to steal from the host. An iPod with a large hard drive can be used by an attacker this way to ‘backup’ data quickly, and do so by gaining physical access to the host system.

Although Podloso is clearly a simple concept virus, it is certainly possible to make viruses that spread from desktop systems to the iPod. One can easily imagine that there would also be a number of opportunities for a host system to be infected from an iPod.

For example, people often borrow music from each other, using the iPod in hand-managed mode, instead of letting iTunes synchronize directly. Currently, the DRM settings seem to be strong enough in the newest Shuffle editions to disallow the copying of music from several hosts to a single device. In other editions, however, this is certainly an option, allowing people to exchange music. Details of how to find the music folder on the iPod and copy it back to the desktop are already common knowledge, and one can easily use the Terminal program, by dragging the iPod icon to it, to browse the music folders. These are not usually synchronized back to the host by iTunes to reduce music piracy.

The early editions of iPod can synchronize data very quickly, utilizing Apple’s Firewire standard. Back in 2004, a vulnerability was discovered in Firewire interfaces [4]. The vulnerability resides in the handling of host memory access (including PCI RAM), which is directly available to the connected Firewire devices, such as the iPod. During data transfers the device is supposed to read and write in the designated DMA memory range that the host indicates. However, the device can decide to read and write outside of these areas and thus, according to its will, modify the host’s kernel memory as a result.

It would be the duty of the host to disallow access to outside regions, but this is not typically enforced by operating systems. For example, Mac OS X kernel (prior to 10.3.9 releases) could be modified directly by a connected iPod device. In 2005, another paper reported that a Linux iPod port of such an attack tool already existed [4].

Using iPod Linux, it is trivial to access the host for modification, and even plant a rootkit, or possibly a virus, back on the connected host machine. In addition, dumping of physical memory – a process known as memory imaging – can be performed, alongside memory modifications. Although Windows 2000 crashes, and other releases such as Windows XP do not support direct DMA for Firewire, the attack can still be achieved under certain conditions. It must also be noted that Firewire DMA can be disabled on Mac OS X, for example by setting an open firmware password [5].

As expected, there are possible ways to simulate communication between an iPod and iTunes, and perhaps via those interfaces exploit vulnerabilities from the iPod on the host machine. A variety of iTunes vulnerabilities are already known today. In addition, there are releases of gnu-Tunes, to support music libraries on other operating systems.

Thus, a multi-platform concept is certainly possible. A virus (worm) could jump to the iPod and then back to the desktop to exploit new targets all over again.

Obviously, the basic recovery of the iPod is supported by the device itself. Key combinations can be utilized to put the iPod into disk mode, and then the host can restore the iPod to its original state, cleaning up all the cool music and stuff on the way.

However, once code is running on the iPod, the key combination could be hooked by hostile code in such a way that one could not easily trigger the disk mode. In addition, there are many firmware nuances. Years ago, when I first thought about the possible attacks against iPod devices, I talked to the lead developer of the iPod Linux kernel. He told me that during the discovery stages they played with the sleep function of the iPod firmware code, and accidentally put iPods into comas, with no chance of waking them. When you do not use your iPod for a short period of time, it goes into a light sleep, allowing it to be turned back on more quickly. However, after a prolonged period of time without use, the device goes into a deep sleep, from which it will boot more slowly. Apparently, this deeper sleep will turn into a coma state if the function is called with the incorrect parameters. No wonder the iPod Linux developers need continuous donations of iPod devices to keep their operations running!

We are currently waiting for the release of the exciting Apple iPhone which, according to Apple, supports a micro Mac OS X kernel. The iPhone will borrow from the iPod in many ways, so it will be interesting to see how these threats develop further, once attackers are facing wireless devices with additional personal information stored on them.

Supposedly, the iPhone will have additional security features beside DRM, but the ability to get around these safeguards is already on the horizon. For the moment, the iPhone is reportedly a closed device – at least as much as the iPod is today. It is very likely that the iPhone will also use code signing to verify new modules. However, the pressure will be huge on Apple to support the device with an open API in the future.

[Marius van Oers will present a paper on Apple Media Files and the iPhone at this year’s Virus Bulletin conference in Vienna (19–21 September). For the full programme details, including abstracts for all papers, as well as online registration, see http://www.virusbtn.com/conference/vb2007/.]