安全なコーディング手法:Zipライブラリのデフォルトの動作がリモートコード実行につながる可能性がある
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
アプリケーションセキュリティ研究者-研究開発エンジニア-博士候補者
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
アプリケーションセキュリティ研究者-研究開発エンジニア-博士候補者
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
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
始めるためのリソース
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
