In 2009, Red Hat, SuSE, and other Linux distributors fixed a
major flaw that could have allowed any user to escalate his
privileges and fully compromise a Linux system. The vulnerability,
in theudev process, occurred because the device-resource-handling
component did not verify that a certain type of message, known as a
netlink message, came from the kernel.
A variant of the udev flaw, or CVE-2009-1185, is one component
of the DroidDream attack identified earlier this month. That
exploit, called exploid.c, uses a netlink message to create a
user-controlled copy of the init process, which handles boot up,
thus gaining root access. The init process reuses much of the code
from the previously vulnerable udev process, according to Zach
Lanier, a security consultant with mobile-security provider
Intrepidus Group.
"Large chunks of code have been moved from udev to the init
daemon," Lanier says. "The exploit uses the same technique but
attacks a different process."
The DroidDream attack used the init process flaw and another
vulnerability -- a resource exhaustion attack on the Android
debugging bridge (adb) -- to install a rootkit that could install
additional malicious software from a command-and-control server.
However, the attack never matured to that point before the 58
infected apps were removed from the Android Marketplace, and Google
used its capability to remotely remove the application from nearly
260,000 victims' phones.
Yet such an attack will undoubtedly happen again. The openness
of the Android operating system and the fact that it is based on
Linux means that a large cadre of operating-system hackers can
attempt to find vulnerabilities in the system. And they have an
incentive to do so: While cybercriminals typically target PCs with
malware to make money, many of the exploits created for smartphones
are motivated by the need to jailbreak the devices to gain certain
functionality, such as the ability to switch cellular
providers.
"The place where we are seeing mature, reliable exploit code
being disseminated are for vulnerabilities that people are using to
rootkit or jailbreak their phones," says Tom Cross, a security
researcher with IBM's Internet Security Systems' X-Force research
team. "Obviously, there is a desire to do that to these devices and
that is driving the creation of these reliable exploits, and those
exploits can be used for malicious purposes."
IBM has tracked smartphone exploits and found that attacks have
steadily increased during the past few years.
Moreover, as demonstrated by the DroidDream incident, carriers
and manufacturers tend to be slow to patch their phones, leaving
them vulnerable longer. At least 42 percent of Android-based phone
used vulnerable versions of the operating system -- version 2.1 and
below, according to the Android developer site. In reality, Android
2.2.1 and below are vulnerable, but it's uncertain what fraction of
the 58 percent of phones running Android 2.2 are running a
vulnerable version.
It's no mystery as to why: The pipeline for fixing
vulnerabilities is more tortuous than in the computer industry.
After a patch is accepted, Google must commit the fix to the code
base, the manufacturer must produce a tailored build of the
operating system for its products and test the software, and,
finally, the carrier has to test the software on its own network
and then push out an over-the-air update.
"The Linux kernel might be updated, but there is still a window
in which it has to be pushed into the Android tree, then pushed
into a OEM's build ... then pushed into the carrier's queue to be
updated," Lanier says. "So you are talking months between when a
kernel-level bug is found and the patch on mainstream Linux
distributions and finally rolled out to the Android devices."
Still, like the DroidDream incident, smartphones do have
significant security controls in place, so it's uncertain how
successful attacks will be against the platforms. Apple patches the
iPhone on par with PC-industry norms, and its control of the App
Store means that attackers have a hard time getting malicious code
onto victims' phones. Similarly, Google's control over the Android
Marketplace allows it to respond quickly to outbreaks and limit the
spread of malicious code. Both benefit from the security controls
in Linux and some form of sandboxing.
"These platforms are getting more robust," Lanier says. "If used
right, you know, in the ideal world of unicorns and gumdrops, the
security model of Android is fairly robust."
Moreover, the latest incident might have been a watershed for
mobile malware, but the easiest and most sure way to steal data
remains to steal the phone, not compromise it with malware, IBM's
Cross says.
"Right now that approach is not proven as a successful way to steal
data from people," Cross says. "So there is still the question is
what is the criminals business model that leads to widespread
exploitation ... so far, none has arisen."