As reported by a user on Huntr.com.
The implementation of is_symlink is hard-coded to return False, which could give the false impression that a path is not a symlink, whereafter they may expand the zipfile using a utility that does honor symlinks, exposing access to unwanted paths.
|
def is_symlink(self): |
|
""" |
|
Return whether this path is a symlink. Always false (python/cpython#82102). |
|
""" |
|
return False |
That code refers to python/cpython#82102, where CPython's zipfile implementation does not have any support for either detecting nor creating nor extracting symlinks.
However, the Path object could provide support for reflecting a symlink if present.
According to the vulnerability report, the symlink could be detected from a ZipInfo object with the following expression:
(info.external_attr >> 16) & 0o170000 == 0o120000
I'd like to verify that logic is correct.
As reported by a user on Huntr.com.
The implementation of is_symlink is hard-coded to return False, which could give the false impression that a path is not a symlink, whereafter they may expand the zipfile using a utility that does honor symlinks, exposing access to unwanted paths.
zipp/zipp/__init__.py
Lines 392 to 396 in 051250e
That code refers to python/cpython#82102, where CPython's zipfile implementation does not have any support for either detecting nor creating nor extracting symlinks.
However, the
Pathobject could provide support for reflecting a symlink if present.According to the vulnerability report, the symlink could be detected from a
ZipInfoobject with the following expression:I'd like to verify that logic is correct.