Standardize the filename of Archive Entries so path traversal characters cannot be used to manipulate file output location #171
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ers cannot be used to manipulate file output location
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to eliminate the Zipperdown security vulnerability. Relevant Github issue
Files inside of an archive may contain path traversal characters in their filename. When unarchiving these, SSZipArchive follows
../sequences which can lead to a file being written to an unexpected destination. This could potentially lead to RCE under the worst of circumstances (such as overwriting a javascript file that the app is going to execute).This addition sanitizes dot-dot-slash (
../) characters from the destination path of files being unarchived, mimicking the default behavior of the Archive Utility found on macOS (as well as most other popular desktop archiving clients).Consider an archive containing the following file:
../../../../../../../../../../../Users/test/Desktop/hello.txtWhen unarchived using the current release of ZipZap, the directory traversal characters are followed causing unarchived files to break out of the current directory, resulting in
/Users/test/Desktop/hello.txtbeing created.Compare this to the default behavior of macOS's Archive Utility, which does not follow directory traversal characters. The same archive results in extraction restricted to the current directory:
%current_path%/Users/test/Desktop/hello.txtFrom a security standpoint, discarding directory traversal characters when unarchiving should be the default behavior of this SDK.