-
Notifications
You must be signed in to change notification settings - Fork 1.3k
arbitrary file over write #453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
And this library also supports symbolic link creation, which may cause security issue under certain circumstances |
Any update? |
AFAIK, supporting unrestricted parent path is a well-known feature in zip, tar or 7z protocol. don't understand why a zip library should handle this but indeed, lack of knowing this leads to unexpected things, thus arbitrary code execution. |
盘古的大神,你们应该是 宣传自己的安全工具吧 @turingH |
@fangli The best solution is checking script of security before runs it. |
fangli has a valid point. In my humble opinion I'd say we keep the original implementation as-is without extra filtering so as not to break backward compatibility, however we should probably implement new methods that explicitly handle the situation |
Agree with fangli. This is a feature, not a bug. |
@Naville 哪都能看见你 ^. ^ |
@turingH |
@SilverMoonSecurity but obviously this module doesn't provide such api, it just extract everything as is. |
The proposed fix in #456 is the right approach, I think. Overwriting files outside of the folder where the archive is getting unzipped is very unexpected (even if "valid" when it comes to what the zip format allows) and will surprise most users and developers, resulting in security issues. This is why most (if not all) popular archiving tool, such as the built-in tools on MacOS and Windows, do not support this behavior and never create files outside of the selected folder. The fix should make the library safe by default, with an option to override the security feature and restore the original behavior (which allows file overwrite). If you do it the other way around, none of the vulnerable apps will make the code change needed to enable security. |
2.1.3 released |
I'm a security researcher from pwnzen at Shanghai,China.
First of all, thank you for your sharing .
We found that
function may lead to arbitrary file over write
In case of holding path traversal filenames in the archive, strPath should be checked for whether it contains "../../../".
The text was updated successfully, but these errors were encountered: