Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: 🐛 Arbitrary file access during archive extraction ("Zip Slip") #13765

Open
odaysec opened this issue Feb 28, 2025 · 0 comments
Open
Labels
external-contributor type-bug Something isn't working

Comments

@odaysec
Copy link

odaysec commented Feb 28, 2025

Describe the bug

File outputFile = new File(outputPath, entry.getName());

Extracting files from a malicious zip file, or similar type of archive, is at risk of directory traversal attacks if filenames from the archive are not properly validated.

Zip archives contain archive entries representing each file in the archive. These entries include a file path for the entry, but these file paths are not restricted and may contain unexpected special elements such as the directory traversal element (..). If these file paths are used to create a filesystem path, then a file operation may happen in an unexpected location. This can result in sensitive information being revealed or deleted, or an attacker being able to influence behavior by modifying unexpected files.

if a zip file contains a file entry ..\sneaky-metamask, and the zip file is extracted to the directory c:\output, then naively combining the paths would result in an output file path of c:\output\..\metamask-file, which would cause the file to be written to c:\metamask-file.

Expected behavior

No response

Screenshots/Recordings

No response

Steps to reproduce

POC

In this vulnerable, a file path taken from a zip archive item entry is combined with a destination directory. The result is used as the destination file path without verifying that the result is within the destination directory. If provided with a zip file containing an archive path like ..\metamask-file, then this file would be written outside the destination directory.

void writeZipEntry(ZipEntry entry, File destinationDir) {
    File file = new File(destinationDir, entry.getName());
    FileOutputStream fos = new FileOutputStream(file); // BAD
    // ... write entry to fos ...
}

To fix this vulnerability, we need to verify that the normalized file still has destinationDir as its prefix, and throw an exception if this is not the case.

void writeZipEntry(ZipEntry entry, File destinationDir) {
    File file = new File(destinationDir, entry.getName());
    if (!file.toPath().normalize().startsWith(destinationDir.toPath()))
        throw new Exception("Bad zip entry");
    FileOutputStream fos = new FileOutputStream(file); // OK
    // ... write entry to fos ...
}

References

Error messages or log output

Detection stage

In production (default)

Version

v7.40.0

Build type

None

Device

Android

Operating system

Android

Additional context

No response

Severity

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external-contributor type-bug Something isn't working
Projects
Status: To be fixed
Status: To be fixed
Development

No branches or pull requests

2 participants