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
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Application Security Researcher - R&D Engineer - PhD Candidate
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
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
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Application Security Researcher - R&D Engineer - PhD Candidate
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
Table of contents
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
