Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
..
Failed to load latest commit information.
README.md
pwn
zipfury.py

README.md

ZipFury: Yet another Zip arbitrary file write with system privileges

  • Authors: Roberto Paleari (@rpaleari) and Aristide Fattori (@joystick)
  • ID: CVE-2015-8780
  • Notification date: 12/06/2015
  • Release date: 02/11/2015

Some months ago, while testing an Android app, we identified an arbitrary file write vulnerability in a Zip file decompression routine. The standard Java/Android Zip library (i.e., ZipFile) does not perform any check on the paths of files contained in a Zip archive, as this task is devoted to the application itself.

This tickled our senses and a quick grep to find system apps using this library yielded some interesting results. In particular, we identified two interesting system level components that made use of the ZipFile library and did not check for dangerous paths: wssyncmlnps and the Swift keyboard. We soon ruled out the latter, since the vulnerability was only reachable during an update routine and required a MitM attack. Some months later, this proved to be a very bad idea :-). wssyncmlnps, on the other hand, was just slightly more interesting: it was exploitable to write arbitrary files as system as well, but the bug was reachable only through Samsung Kies. For these reasons (and also for the lack of spare time) we sat on the bug for some months.

When we finally had time to investigate better and produce a small PoC Zip to demonstrate the vulnerability, we notified it to Samsung (12/07/2015). A couple of days later, NowSecure published its blog post on the SwiftKey bug. They made no mention to wssyncmlnps, fortunately :-)

Technical details

The vulnerability affects wssyncmlnps (wssyncmlnps.odex), a proprietary Samsung application executed with administrative (i.e., "system") privileges. Among the other things, this application handles the backup & restore of user data via Kies.

Practically speaking, when a user performs a restore operation through Kies, the aforementioned application eventually processes a .bk file, which is basically a Zip archive that is uncompressed using the standard Java/Android library class ZipFile.

Due to insufficient checks on the name of the files contained in the Zip archive, an attacker can perform a directory traversal to extract uncompressed files to arbitrary locations. This permits a local user with access to Kies to write to any filesystem location, with "system" privileges (provided that the destination directory is not mounted in read-only mode).

To the best of our knowledge, this issue can only be triggered through Kies, or at least exploitation requires a physical USB connection. In other terms, there are apparently no ways that other apps on the phone could leverage to exploit this vulnerability.

Steps to recreate

As a proof-of-concept, we created a malicious e-mail backup archive that exploits the vulnerability. Other backup archive types can also be used to trigger the vulnerability.

In detail, we first created a .bk file containing a file named ../../../../../../data/testme.pwn. Consider that this is not possible using traditional file compression applications: the Zip file must be manually modified to rename one of the contained files inserting the directory traversal specifiers (../). See the attached script to create the Zip.

Secondly, we created a backup folder that satisfied the requirements of Kies. More precisely, the backup folder must contain:

  • a backupHistoryInfo.xml file containing information on the backup. The contents of this file must be adapted to reflect the parameters of the target device.

  • An EMAIL/BR/ sub-directory containing the maliciously crafted .bk file (i.e., the Zip archive).

Finally, from the Kies "Back up/Restore" tab we clicked on the "Restore" option. We then selected the directory containing the crafted backup files through the "Select folder" button and hit "Restore". The specially-crafted backup archive is thus processed and a file named /data/testme.pwn is eventually created, owned by the "system" user; this file has attacker-controlled contents.

Discussion

As mentioned earlier, a very similar bug has been almost concurrently identified by NowSecure in the update mechanism of the Swift keyboard. NowSecure demonstrated that an arbitrary file write with system privileges can be successfully exploited to eventually obtain code execution. Our bug cannot be exploited for remote code execution, but it could be exploited to gain system privileges on a physically (i.e., USB) accessible device.

Timeline

  • 12 Jun: Notified Samsung, proposed a 90-days disclosure.

  • 15 Jun: Samsung replied.

  • 15 Jun: Sent details to Samsung.

  • 16 Jun: NowSecure releases details of its attack to SwiftKey.

  • 17 Jun: Samsung acknowledges the bug and asks for some time to evaluate the time of disclosure.

  • 22 Jul: Samsung has a patch ready, but still no update on the disclosure date.

  • 28 Jul: Samsung finishes the patch testing, proposes a "End of October" disclosure.

  • 29 Jul: We agree to postpone the deadline to October 31.

  • 26 Oct: Remind Samsung of disclosure date.

  • 2 Nov: Disclosure.