fix: prevent extracting archived files outside of target path

[aviadatsnyk]

Why this PR?

This PR is meant to fix an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive, that holds path traversal filenames. When the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder.

A sample malicious zip file named zip-slip.zip. (see this gist) was used, and when running the code below, resulted in creation of evil.txt file in /tmp folder.

fs.createReadStream('zip-slip.zip').pipe(unzipper.Extract({ path: '/tmp/safe' }));

There are various possible ways to avoid this issue, some include checking for .. (dot dot) characters in the filename, but the best solution in our opinion is to check if the final target filename, starts with the target folder (after both are resolved to their absolute path).

Stay secure,
Snyk Team

[aviadatsnyk]

Finally got a version that passes for all the node versions, so no more planned changes here.

[ZJONSSON]

This should either throw an error or at the very least show a warning.
Also the entry is left hanging here as nothing drains it (possibly use .autodrain)

[ZJONSSON]

published as unzipper@0.8.13. Awesome catch, thank you!!

[glen-nicol]

Hi there, I ended up using the code snippet above to add zip-slip protection to some of my manual unzipping methods that use this library. And I noticed that on my linux docker image it failed to detect the windows zip-slip archive.

I am using the following and it catches both of the examples from synk on windows and linux docker images (did not try mac)

const DUMMY_PATH = path.join('/sandbox');
const extractPath = path.join(DUMMY_PATH, zipEntry.path.replace(/\\/g, '/'));
if (extractPath.indexOf(DUMMY_PATH) !== 0) {
  return true;
}

[ZJONSSON]

Good catch, can you do a PR with a test that fails without the fix above?

[glen-nicol]

Sure, I'll try to do that in the next couple days.

[ZJONSSON]

Awesome, thank you @glen-nicol

[glen-nicol]

I was looking at it some more, I don't think UNIX machines are actually vulnerable to the windows zip. But I think it will end up creating a rather strange filename "................\tempevil.txt". Should we still go ahead and make the change to ignore something that is obviously attempting to do something bad?

[ZJONSSON]

Thanks @glen-nicol I ran tests against the windows zip-slip archive on a windows machine and the file was safely ignored there. Ideally we should want same behavior independent of platform so the preference here would be to ignore. But I'm happy that this is not actual vulnerability