Android upgrade mechanism brings to light a whole new set of
vulnerabilities pervasively existing in almost all Android versions,
which allow a seemingly harmless malicious app (“unprivileged app” in
the security term) running on a version of Android to automatically
acquire significant capabilities without users’ consent once they upgrade to newer versions!
Such capabilities include automatically obtaining all new permissions
added by the newer version OS, replacing system-level apps with
malicious ones, injecting malicious scripts into arbitrary webpages,
etc.
We call these vulnerabilities Pileup flaws (privilege escalation through updating). In total, we discovered six Pileup flaws in the code
of Android OS. We further confirmed the
presence of the issues in all AOSP (Android Open Source Project)
versions and 3,522 source code versions customized by Samsung, LG and
HTC across the world. Those flaws affect all the Android devices
worldwide, posing serious threats to billions of Android users who are
actually encouraged to update their systems.
A distinctive feature of the threat is that the attack is not aimed at a vulnerability in the current system. Instead, it exploits the flaws in the updating mechanism of the “future” OS, which the current system will be upgraded to.
More specifically, through the app running on a lower version Android,
the adversary can strategically claim a set of carefully selected
privileges or attributes only available on the higher OS version. For
example, the app can define a new system permission such as
android.permission.READ_PROFILE (read the user’s personal profile data)
on Android 2.3.6, which is to be added on 4.0.x. It can also use the
shared user ID (UID) (a string specified within an app’s manifest file)
of a new system app on 4.0.x, its package name and other attributes.
Since these privileges and attributes do not exist in the old system
(2.3.6 in the example), the malicious app can silently acquire them
(self-defined permission, shared UID and package name, etc.). When the
system is being updated to the new one, the Pileup flaws within the new
Package Manager will be automatically exploited. Consequently, such an
app can stealthily obtain related system privileges, resources or
capabilities. In the above example, once the phone is upgraded to 4.0.x,
the app immediately gets android.permission.READ_PROFILE without the
user’s consent and even becomes its owner, capable of setting its
protection level and description. Also, the preempted shared UID enables
the malicious app to substitute for system apps such as Google
Calendar, and the package name trick was found to work on the Android
browser, allowing the malicious app to contaminate its cookies, cache,
security configurations and bookmarks, etc.
The consequences of the attacks are dire, depending on the exploit opportunities on different Android devices,
that is, the natures of the new resources on the target version of an
update. As examples, on various versions of Android, an upgrade allows
the unprivileged malware to get the permissions for accessing
voicemails, user credentials, call logs, notifications of other apps,
sending SMS, starting any activity regardless of permission protection
or export state, etc.; the malware can also gain complete control of new
signature and system permissions, lowering their protection levels to
“normal” and arbitrarily changing their descriptions that the user needs
to read when deciding on whether to grant them to an app; it can even
replace the official Google Calendar app with a malicious one to get the
phone user’s events, drop Javascript code in the data directory to be
used by the new Android browser so as to steal the user’s sensitive
data, or prevent her from installing critical system apps such as Google
Play Services. We performed a measurement on those exploit
opportunities, which shows how they are distributed across Android
versions and vendors. Figure 1 compares the average numbers of the
exploit opportunities provided by AOSP, Google and Samsung, when the
system is upgraded from 2.3.X to 4.0.X, then to 4.1.X, 4.2.X, 4.3.X and
4.4.X consecutively. As we can see from the figure, not only do the
manufacturers introduce more opportunities than AOSP, but Samsung adds
more than Google. Also interestingly, though Google and AOSP apparently
make the biggest system overhaul from 2.3.X to 4.0.X and show a trend of
less aggressive updating afterwards, Samsung continues to bring in more
new stuffs from 4.1.X to 4.2.X and to 4.3.X, at the cost of increased
security risks.
Posts
