This article is more than 1 year old

Another zombie 'bogus app' bug shambles out of Android

KitKat is safe, older Androids susceptible to .ZIP-derived attack

Jay Freeman, aka @saurik, has detailed another Zip implementation bug in pre-4.4 (Kit Kat) versions of Android which, similarly to the notorious APK vulnerability exposed earlier this year, opens a hole that malware can sneak through.

Freeman – whose previous credentials include security analysis of Google Glass and uncovering the dodginess of the “iMessage for Android” app – has written in a blog post that he uncovered the extra vulnerability in June, but waited until Android 4.4 (with a fix) was shipping.

Freeman's dense post is here, and is unpicked and explained by Sophos' Paul Ducklin at Naked Security here.

In brief, the extra APK vulnerability offered a path for an attacker to exploit the way Android used Zip file headers to verify the software. As Ducklin explains, Zip still carries an obsolete of its history around with it: lots of filename redundancy in case files had to be split across multiple floppy (remember those?) disks. To help a program navigate a file, the header includes a field for filename length – this lets an extractor navigate to where the file data is, by skipping the header.

As Ducklin writes, the problem is this: “The Java code in Android 4.3 and earlier, that extracts the file data to verify it, uses the filename length from the central directory. But the C code that extracts the file to install and execute it uses the filename length in the local header.”

An attacker could then take a verified app, add their malware, and modify the header length the C-code loader uses to point not to the legitimate app, but to the malware. Ducklin's illustration shows this simply:

Paul Ducklin's illustration of the APK vulnerability

Image: Paul Ducklin, Naked Security

As Saurik writes: “The central directory includes a file offset for each local header, so that once the Java code has finished verifying a file, it can jump directly to the next one, thus avoiding the local header data that would cause it to skip forward incorrectly. The imposter data, squeezed between the legitimate file and the next local header, is simply ignored.”

The fix in Kit Kat is to force Java to look at the same data as the C-loader so that a discrepancy is identified. ®

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like