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 security@android.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 passwords. 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 #1086986860. Well, now you might want even more to use a different browser for important stuff. 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 #1069937150. 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 #1055942661. 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). Jann Horn