Secure coding technique: Default behavior of Zip libraries can lead to Remote Code Execution

This week we are going to talk about the default behavior of Zip libraries. If you are an application developer, it is very likely that you have used this before. Most resources that are downloaded over the internet are in zip format, this makes sense; compressed data is smaller, so it downloads faster and consumes less bandwidth.

If you want some more concrete examples: textures for games, language packs for auto-completion in keyboards, ... Many resources are not automatically bundled with the application but downloaded later.

But be cautious when using this functionality, file names in zip archives can contain path traversal information. When extracted, this will lead to files being created outside of the intended directory. This is often done with the intent of overwriting existing files.

Say we have a zip archive containing the following two files:

file1
  ../file2

When this archive is extracted, file1 is extracted where we expect it to be, in the unzip directory. However, file2 was written one directory higher than where we asked the zip library to extract the archive.

So be careful, if your zip library does not take care to properly handle this case, it will allow an attacker to write an arbitrary file in the system. Always check if your library is secure, this rule of thumb is valid for any library, but in particular you know to check the default behavior of your zip library for these types of files.

Lets demonstrate the consequences when this case is not properly handled in Android. In Android, the Java Zip library (java.util.zip) is used, the library allows path traversal as explained above by default.

Androids Dalvik Executable format (.dex) has limitations on the amount of classes a single file can have. Apps that need more classes can make use of the MultiDex Support library that has been added since API level 21 (Android 5.0 Lollipop). This library saves secondary .dex files in the data directory of the application, this directory is writable by the app user and this code will be loaded and executed when the .dex file is needed.

This means that an attacker can modify the .dex file by overwriting it using a malicious zip archive and even worse, this file will be loaded and executed, resulting in a remote code execution vulnerability. This is not merely a theoretical example but has been demonstrated on the app My Talking Tom, which has over a 100 million downloads on the app store. Here is a video of the exploit that was presented at Black Hat.

Always check the behavior of your zip library so you are aware of its insecurities. If you cannot disable path traversal in your zip library, make sure you validate the name of each entry before extracting it. The name should be canonicalized and the resulting path should be in the directory you want to extract the archive. While we are at it, you should also check the total size of the extracted archive to prevent zip bombs, but this will be a post for another week.

If you want to play some challenges on path traversal or want to test your secure coding skills, check out our platform.

See you next time, and remember, secure code or no code!

- We can inject a file into a zip whose name is prefixed with an arbitrary number of " ../ "
- If the zip library does not take care to properly handle this case, it would allow us to write outside of the intended extraction directory
- If the zip file is untrusted, this gives the attacker an arbitrary write vulnerability

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf