Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
fix: prevent extracting archived files outside of target path #374
This PR is meant to fix an arbitrary file write vulnerability, that can be
A sample malicious zip file named Zip.Evil.zip was used,
There are various possible ways to avoid this issue, some include checking
May 2, 2018
1 check passed
referenced this pull request
Jun 28, 2018
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
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
Any idea how to fix this properly without losing cross-platform case sensivity?
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.
I reproduced it both on .NET Core (2.1) and the full CLR on Windows 10.
CoreCLR just delegates to the Windows API function