Directory traversal vulnerability from libzip

[jiahao42]

Issue

Given a crafted zip file containing a file of filename ../../../../../../../../tmp/evil.txt, zip will extract the file to /tmp/evil.txt, while actually it should be extracted to ./tmp/evil.txt. This vulnerability could allow the attacker to write a file to an arbitrary directory.

How to reproduce

You can try to reproduce this vulnerability using this zip file, note that the symbol nim -d:useLibzipSrc is needed for compilation. You can find the PoC here

[dmknght]

The variable dest should be filtered https://github.com/nim-lang/zip/blob/master/zip/zipfiles.nim#L193

[StayPirate]

CVE-2020-23171 has been assigned to this security bug. Is any patch going to be released anytime soon?

[Araq]

Well the hyperbole isn't motivating to look into the issue.

This vulnerability could allow the attacker to write a file to an arbitrary directory.

The operating system enforces access rights...

[rposkocil]

Understood but any progress or what is the plan with this issue? Still open and vulnerability tools marks all versions.

[ajurge]

Hi is there any update on this because our builds started failing because of CVE-2020-23171?

[VaeterchenFrost]

Some guidance on remedial actions has been collected, for example, in https://snyk.io/research/zip-slip-vulnerability.

[rposkocil]

Hi guys, it's false positive. See https://github.com/jeremylong/DependencyCheck/issues/3594.

[StayPirate]

How can that be a FP if the reported @jiahao42 attached a reproducer? Has anyone tested it?

[prosprice]

The linked DependencyCheck project is doing a poor job matching CPEs and has attributed the CVE for this issue to an unrelated Java library. That's the FP that @rposkocil is referring to and what brought me here, but the FP report in that project should not be interpreted to mean that this issue is false.

[StayPirate]

Just to clarify, we can ignore https://github.com/jeremylong/DependencyCheck/issues/3594 (FP is their problem) and keep tracking this actual security bug with CVE-2020-23171. @prosprice, am I correct?

[prosprice]

@StayPirate I'm not a Nim user; with that caveat, yes I agree with you.

[StayPirate]

@Araq could you share some extra information about how the upstream is going to address this issue?

[supakeen]

I must say that without diminishing the exploitability of this that nim-lang/zip isn't in Nim by default and like many other libraries it can be misused.

This is the same for other languages that provide wrappers around libzip's extractall, see for example the Python documentation warning you against this possibility: https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall

What would be the proposed 'fix' for this CVE? Removing the extractall binding or documenting that it doesn't handle relative paths?

[kraptor]

Shouldn't this bug be moved into nim-lang/zip as it's not a bug in Nim and it's not in the standard library as pointed out by @supakeen ??

[0-wiz-0]

I must say that without diminishing the exploitability of this that nim-lang/zip isn't in Nim by default and like many other libraries it can be misused.

This is the same for other languages that provide wrappers around libzip's extractall, see for example the Python documentation warning you against this possibility: https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall

What would be the proposed 'fix' for this CVE? Removing the extractall binding or documenting that it doesn't handle relative paths?

libzip doesn't provide an extractall function. (Python doesn't use libzip.) It's a problem in the zip implementation for nim - they need to sanitize their paths.