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
* Add netstandard 2.0 target and netcoreapp2.0 tests
* Update xunit
* set tests explicitly to netcore2
* update travis
* Don't say build as netcoreapp1.0
* try adding dotnet 1 too
* Remove .NET Core 1 support
* switch to circle
* update cake
* fix circle build
* try fix file ending test again
* Fix casing on files
* Another casing fix
* Add back netstandard1.0
* Finish adding netstandard 1.0 back
* Add netstandard1.3 back
* Zip64 introduced seekable behavior into ZipWriter. The position may not be zero.
* Remove some dead code
* Update formats for zip64
* Make version created by and version needed to extract the same
* Running tests is faster than skipping
* First pass. Writing isn't implemented on stream. Tests are busted.
* LZipReader works...no file name :(
* LZipWriter works
* Writing tests are actually correct now. LZipStream correctly writes trailer now. lzip command line tool likes it.
* Add recommendation blurb
* Update notes for formats
* LZip isn't an archive format
* Attempting to fix and implement crc32
* LZip writing test passes
* Had to invert crc to check uncompressed data.
