fix: prevent extracting archived files outside of target path

[odinn1984]

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.Evil.zip was used,
and when running the code below, resulted in the creation of C:/Temp/evil.txt
outside of the intended target directory.

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

[diaconesq]

I have decompiled version 0.21.1 from Nuget.org (the .net 4.5 dll) and the fix is not there.

[majoreffort]

Hi! Don't know if this is the right place, but I ran into a bug related to this fix, or more precisely, the behaviour of the method Path.GetFullPath used here.

I had an edge case scenario where some of the files inside of an archive would have tildes in their filename, e.g. "test~". Somehow, this has an odd influence on the path normalisation on Windows, if the target folder is not given with the proper letter case.

Take the following code snippet as an example:

string dir = "c:/test"; // <- exists in the real filesystem as "C:\Test"
string file = "testfile~";
dir = Path.GetFullPath(dir);
// dir = "c:\\test"
string filepath = Path.Combine(dir, file);
// filepath = "c:\\test\\testfile~"
filepath = Path.GetFullPath(filepath);
// filepath = "c:\\Test\\testfile~" <- note the capital 'T'

The tilde seems to trigger the short-to-long path extension, which accesses the file system and in return "corrects" the case.

Now the check filepath.StartsWith(dir) fails, because the case doesn't match (see

sharpcompress/src/SharpCompress/Common/ExtractionMethods.cs

Line 55 in 7beff9e

if (!destinationFileName.StartsWith(fullDestinationDirectoryPath))

) and the exception ("Entry is trying to write a file outside of the destination directory.") gets thrown erroneously.

Any idea how to fix this properly without losing cross-platform case sensivity?

[adamhathcock]

Sounds like a possible bug in the Path.GetFullPath code. Is that full framework on windows doing that? Does .NET Core have the same behavior?

It could be trivial to do a case-sensitive filesystem check then do the right thing but it feels wrong to build that if this is a bug.

[majoreffort]

I reproduced it both on .NET Core (2.1) and the full CLR on Windows 10.

CoreCLR just delegates to the Windows API function GetLongPathNameW(https://github.com/dotnet/coreclr/blob/72ee1dacaa5ce68546da9fb9365936ab5a8899b6/src/System.Private.CoreLib/shared/System/IO/PathHelper.Windows.cs#L72). I don't know if we can do anything about that...it may even be accepted behaviour.