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
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
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
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 :-)
The vulnerability affects
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
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
../). 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:
backupHistoryInfo.xmlfile containing information on the backup. The contents of this file must be adapted to reflect the parameters of the target device.
EMAIL/BR/sub-directory containing the maliciously crafted
.bkfile (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
eventually created, owned by the "system" user; this file has
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.
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.