Details: Android does not properly check cryptographic signatures for applications, which allows attackers to execute arbitrary code via an application package file (APK) that is modified in a way that does not violate the cryptographic signature. Android security bug 8219321. [citation-needed]
Details: File offsets in zips are supposed to be unsigned but were interpreted as signed allowing different content to be verified from the content executed. [citation-needed]
Details: APK signature verification does not check name lengths correctly, creating a difference between how the zip files are verified compared with how they are extracted which allows files in an existing APK to be replaced with new files. [saurik-19]
Exploited by RockMyMoto [androidpolice-rockmymoto]
Details: The software does not properly validate an application's certificate chain. An application can supply a specially crafted application identity certificate to impersonate a privileged application and gain access to vendor-specific device administration extensions. The vulnerability resides in the createChain() and findCert() functions of the Android JarUtils class. [securitytracker-1030654]
Google bug 13678484 [blackhat-briefing-fakeid]
Discovered by: Jeff Forristal of Bluebox [bluebox-fakeid] on: Unknown
Fixed versions: there is no single, specific “fixed” version of Android. In fact, multiple vendors are maintaining the same prior version number, and only patching the functionality. We have confirmed “fixed” versions existing within the ranges of 4.1, 4.2, 4.3, and 4.4 [bluebox-fakeid]
Details: The futex_requeue function in kernel/futex.c in the Linux kernel through 3.14.5 does not ensure that calls have two different futex addresses, which allows local users to gain privileges via a crafted FUTEX_REQUEUE command that facilitates unsafe waiter modification. [CVE-2014-3153]
Details: Drake said that the vulnerabilities can be exploited by sending a single multimedia text message to an unpatched Android smartphone. While the exploit is deadly, in some cases, where phones parse the attack code prior to the message being opened, the exploits are silent and the user would have little chance of defending their data. [techworm-stagefright]
Stagefright is the media playback service for Android, introduced in Android 2.2 (Froyo). Stagefright in versions of Android prior to 5.1.1_r9 may contain multiple vulnerabilities, including several integer overflows, which may allow a remote attacker to execute code on the device. [cert-kb-stagefright]
Details: Meet Stagefright 2.0, a set of two vulnerabilities that manifest when processing specially crafted MP3 audio or MP4 video files. The first vulnerability (in libutils) impacts almost every Android device since version 1.0 released in 2008. We found methods to trigger that vulnerability in devices running version 5.0 and up using the second vulnerability (in libstagefright). Google assigned CVE-2015-6602 to vulnerability in libutils. [zimperium-stagefright2]
Details: Insufficient paramter checking for asec container creation allows an asec container to be mounted over part of the filesystem using directory traversal if the app has the ASEC_* permissions such as ASEC_CREATE [cassidian-vold-asec]
There is an adb tethered root explot for motorola phones [xda-developers-pie-exploit]
Affected devices: Motorola devices [xda-developers-pie-exploit], Proper SEAndroid policies do block this, Nexus 5, Samsung S4/5/Note3, LG Flex, Sony Z2 devices etc should have this mitigated. Nexus 4 if it hasn't been updated to 4.4.3 nor reset since OTA to 4.4 [plus-jcase-pie]
Details: In Android <5.0, java.io.ObjectInputStream did not check whether the Object that is being deserialized is actually serializable. That issue was fixed in Android 5.0. This means that when ObjectInputStream is used on untrusted inputs, an attacker can cause an instance of any class with a non-private parameterless constructor to be created. All fields of that instance can be set to arbitrary values. The malicious object will then typically either be ignored or cast to a type to which it doesn't fit, implying that no methods will be called on it and no data from it will be used. However, when it is collected by the GC, the GC will call the object's finalize method. [fulldisclosure-ois]
luni/src/main/java/java/io/ObjectInputStream.java in the java.io.ObjectInputStream implementation in Android before 5.0.0 does not verify that deserialization will result in an object that met the requirements for serialization, which allows attackers to execute arbitrary code via a crafted finalize method for a serialized object in an ArrayMap Parcel within an intent sent to system_service, as demonstrated by the finalize method of android.os.BinderProxy, aka Bug 15874291. [CVE-2014-7911]
A POC local root exploit is available [CVE-2014-7911_poc]
