Approximately half a year ago, I found a few security issues in Android. Some
of them have been fixed, some haven't been fixed. However, for many Android
phone users, whether Google has released patches doesn't matter anyway because
their phones' manufacturers, e.g. Motorola, don't care about the security
of the phones they sell to people and don't even give users fixed firmware
images when there are working root exploits out in the wild (e.g. the
Levitator vuln on the Motorola Defy). Yes, users can usually install a
Cyanogenmod firmware or so if they're willing to give up warranty and are
aware of the issues, but I'd assume that many people out there have phones
with long-known vulns without even knowing it or ignoring them because
they want to keep their warranty.
So, I won't release full details or PoC code for the issues I found publically
because I don't want to be the one who gives the script kiddies/oppressive but
not-well-equipped governments/... their tools, but if you're somewhat
familiar with the Android source tree and willing to spend some time looking
for these things, you'll probably find most of them.
However, I will give you approximate descriptions of the vulns and
hints on how you might be able to prevent some of these tricks from working.
Please note that sometimes one android issue tracker ID belongs to multiple
issues and that these IDs are IDs in the issue tracker at
email@example.com. Also, these issues might apply only to some
android versions, I normally didn't test them on different versions.
1. Applications on the SD card might be able to hide their permissions from
the user. This issue is relatively hard to exploit, so I wouldn't worry
about it a lot. Also, it only works if your phone supports and you use the
SD-card-access function which exposes your SD card to the computer as a
FAT filesystem. Android issue tracker IDs #1052854379 and #1054370950.
This hasn't been fixed yet. The Android Security Team thinks that this
is not exploitable in practice (and I also doubt that anyone will be able
to make use of this vuln).
2. [was in an earlier version of this document; removed it because it's
not a security feature]
3. Applications with the CHANGE_NETWORK_STATE permission are able to put
pretty much arbitrary stuff in your routing table. So, be careful with
that permission. Android issue tracker ID #1056691969.
This was already fixed before I reported it.
4. Applications with the CHANGE_NETWORK_STATE permission can also write the
strings "0", "1" or "2" (without quotes) into arbitrary files if they
already exist and root is capable of writing into them. So, you might
want to be even more careful with that permission, and app developers
might want to keep this in mind when using plaintext files for storage.
This doesn't just work for real files, it also applies to stuff in sysfs!
Android issue tracker ID #1069937150.
This was already fixed before I reported it.
5. In the default webbrowser app, login form handling is very insecure. For
example, if you choose to save your login data for https://example.org/,
an attacker who knows that can steal your login data using two remote
attack vectors that use the same vuln:
- Completely remote over the Internet. You visit his website and your
login data is stolen. Requires the attacker to register a certain
domain name (not example.org!)
- Using an evil wifi access point that you connect to and use to view
websites in the browser.
Does NOT require faking an SSL cert for example.org!
Verified on Android 4.1.1.
So, you might want to use a different browser or avoid saving important
Android issue tracker ID #1086869776.
The Android Security Team says "This issue is not present in Chrome
browser. A fix for Android browser on earlier devices is in development.".
6. This one is more of a conceptual problem: At any time, every app can
access your clipboard. Even when you're copy-and-pasting authentication
codes from Google Authenticator or so. So don't put valueable data there.
Android issue tracker ID #1086951734.
The Android Security Team says "This is documented platform
functionality and it is not considered security vulnerability.".
I would like to point out that this means that Google's Authenticator
app sometimes leaks authentication data to unrelated apps by design (in
other words, when the user presses "copy to clipboard").
7. Any app can access passwords that are saved in the default browser.
Should also work for stealing cookies, but I didn't try that.
This attack is less straightforward than most of these issues, but I've
got a PoC that works on Android 4.1.1. It's somewhat noisy, so you might
be able to notice that weird stuff is happening. Android issue tracker ID
Well, now you might want even more to use a different browser for
This bug was fixed shortly after I reported it.
8. When you install an application from an apk file on the device, you might
be approving the installation of a different apk than the one that will
really be installed. For example, this means that you might be granting
all permissions that an app could get from you without wanting to do so.
Well, be careful with apps that tell you to update them by downloading an
apk and installing it, and if you choose to do so anyway, maybe check for
apps with suspicious permissions afterwards. Android issue tracker ID
9. If you uninstall an application and then install another one, the
uninstalled application could still be running and gain all rights that the
one you just installed has. As a mitigation, you might want to reboot after
having uninstalled stuff. Android issue tracker ID #1093611178.
The Android Security Team states that
"A fix for this issue is under development.".
a. Applications with the MOUNT_FORMAT_FILESYSTEMS permission can find out
whether files or directories are currently in use. For example, they can
find out what music you're currently listening to if the music files are
on your SD card. Android issue tracker ID #1055272284.
b. Applications can in certain situations replace other apps' native code (if
the other app contains native code). This is probably one
of the most severe issues: It allows an
attacker to e.g. execute arbitrary code in the context of the Skype app
(last time I checked, it included native code) or so without having any
special privileges. The easiest thing an app developer could do against this
is to check the integrity of all *.so files owned by the application before
loading them ? this would still leave a small race condition, but would
already improve the situaton a lot. It should be possible to totally
mitigate the issue by, after installation, placing all .so files in a
randomly-named directory inside a mode-0700-directory and checking their
integrity and, when loading the libraries, always using load() instead of
loadLibrary() to specify the correct path. Android issue tracker ID
The Android Security Team says that this vuln has been fixed (the fix looks
a bit racy, but I think that it probably isn't exploitable).