SharpZipLib
SharpZipLib copied to clipboard
icsharpcode
Prevent symlink traversal outside target directory when using extraction helpers
Steps to reproduce
- Have symbolic link to a directory in the current directory
- Call ExtractZip on a malicious zip that knows the symbolic link is there
- Overwrite files elsewhere in the system
Expected behavior
FastZip.ExtractZip, TarArchive.ExtractContents, etc. refuse to follow symbolic links that lead outside the extraction base directory.
Actual behavior
Other files including system files get clobbered
Version of SharpZipLib
0.8.4 through 88302c560806565a20698f710aa36564448ec03a (master as of 2018-08-28)
Obtained from (place an x between the brackets for all that apply)
- Compiled from source
- branch: master
- commit: 88302c560806565a20698f710aa36564448ec03a
- DLL included as dependency
- Package installed using:
- NuGet
@jhudsoncedaron Are there other vulns you found that have not been addressed?
Yeah. Having a symbolic link created underneath the extract code as its extracting can cause the file being extracted somewhere else even if you check for a symbolic link beforehand and find nothing. (Tight race).
Ref: https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-link-effects-on-file-systems-functions#createfile-and-createfiletransacted
I haven't found a cure but it can be partially mitigated by specifying CREATE_ALWAYS which is exposed to new FileStream(..., FileMode.CreateNew, ...)
If you need to extract untrusted archives into a directory with symlinks, you should not use the FastZip helper, but rather extract the archive manually using ZipFile or ZipInputStream and skip files with an unwanted path.
We don't currently have a way to do this safely automatically, see: https://github.com/dotnet/corefx/issues/26310
Incidentally, I'm the one who filed that corefx issue and I'm the one who uploaded a library to deal with almost all of it.
@jhudsoncedaron I'm well aware and are following the Issue. But this is outside the scope of a extraction helper class.