9 Android Vulnerabilities

This advisory outlines 9 different vulnerabilities in Android. Some have been addressed while others have not.
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.

There is Full Details about the PoC code for the issues but you'll probably find most of them.
But there are 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

Source:Packetstrom