summaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorAndrew Gregory <andrew.gregory.8@gmail.com>2019-03-01 11:23:20 +1000
committerAllan McRae <allan@archlinux.org>2019-03-01 11:23:20 +1000
commitd197d8ab82cf10650487518fb968067897a12775 (patch)
tree725aa5f7267afefcf7e27425933f1e2f4a8b8f11 /test
parentadb961a88e6644d5edb16cfcb5dbd1f02e4a1781 (diff)
downloadpacman-d197d8ab82cf10650487518fb968067897a12775.tar.xz
Sanitize file name received from Content-Disposition header
When installing a remote package with "pacman -U <url>", pacman renames the downloaded package file to match the name given in the Content-Disposition header. However, pacman does not sanitize this name, which may contain slashes, before calling rename(). A malicious server (or a network MitM if downloading over HTTP) can send a content-disposition header to make pacman place the file anywhere in the filesystem, potentially leading to arbitrary root code execution. Notably, this bypasses pacman's package signature checking. For example, a malicious package-hosting server (or a network man-in-the-middle, if downloading over HTTP) could serve the following header: Content-Disposition: filename=../../../../../../usr/share/libalpm/hooks/evil.hook and pacman would move the downloaded file to /usr/share/libalpm/hooks/evil.hook. This invocation of "pacman -U" would later fail, unable to find the downloaded package in the cache directory, but the hook file would remain in place. The commands in the malicious hook would then be run (as root) the next time any package is installed. Discovered-by: Adam Suhl <asuhl@mit.edu> Signed-off-by: Allan McRae <allan@archlinux.org>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions