Two Android vulnerabilities
(“master key” and “extra field”) with samples attached originally discovered by
Bluebox Security and presented at the most recent black hat. (http://vrt-blog.snort.org/)
·
The “master-key
vulnerability” takes advantage of the way Android application packages are
signed, allowing the contents of a package to be modified (potentially to
introduce malware) without invalidating the signatures that had been placed by
the original developer. In short, essentially the vulnerability is exploited by
having multiple files with the same name in an APK. Android's verifier and
loader handle duplicate entries differently. The verifier will check only the
last duplicate entry against the SHA1 digest stored in META-INF/MANIFEST.MF.
The loader will load the first entry.
·
The “extra field” vulnerability is exploited by a signed / unsigned handling error in the Android's verifier. A Zip file's central directory points to all of the files stored in the archive. Each file has a header which has extra space available, called the extra_field. The extra_field, when present, is between a file's header and the stored file. When its size is interpreted as a negative value, the verifier will try to skip past it to the file bytes by jumping backward. If you store the original file at the location the verifier jumps backward to, it will be verified. Then you can place some arbitrary file into the original file's position, causing the new file to be loaded.
The “extra field” vulnerability is exploited by a signed / unsigned handling error in the Android's verifier. A Zip file's central directory points to all of the files stored in the archive. Each file has a header which has extra space available, called the extra_field. The extra_field, when present, is between a file's header and the stored file. When its size is interpreted as a negative value, the verifier will try to skip past it to the file bytes by jumping backward. If you store the original file at the location the verifier jumps backward to, it will be verified. Then you can place some arbitrary file into the original file's position, causing the new file to be loaded.
Below is the variation of the
“extra field” attack which is different in its execution, but does the same
basic trick of fooling Android's APK-reading routines into thinking an APK has
been properly signed by using a copy of correctly signed data in one location
and tricking the system into running an unsigned modified version of that data
stored in another location. The Bluebox approach exploited a flaw that allowed
two copies of the same file to be present in a ZIP archive. This new
Chinese attack works by modifying the classes.dex file which contains an
application’s compiled code within the Android APK file. This file's
header includes a variable-sized space between the header, which includes the
file name with a .dex extension and the class files for an "extra
field". It is into the last three characters of the file name and the
extra field that the original class files are copied, with the length of the
extra field set to 0xFFFD.
After this, padding is added and then the attackers' own class files can be included. When validating, a bug in the reading code means that 0xFFFD is converted to -3 and the validation takes places starting at the "dex" part of the file name extension which also happens to be the opening header of the dex file format. When being loaded though, the reading code follows 0xFFFD correctly and reads the modified code.
Reference: Chinese “The android security team” blog - http://blog.sina.com.cn/s/blog_be6dacae0101bksm.html
Currently both the bugs are fully public, with a patch deployed to CyanogenMod 10.1.2, an open distribution of Android. The problem lies with how to get phone manufacturers to ship out firmware updates that will correct both issues as these problems date back as far as Android 1.6.
