diff options
author | Andrew Gregory <andrew.gregory.8@gmail.com> | 2019-03-01 02:23:20 +0100 |
---|---|---|
committer | Allan McRae <allan@archlinux.org> | 2019-03-01 02:23:20 +0100 |
commit | d197d8ab82cf10650487518fb968067897a12775 (patch) | |
tree | 725aa5f7267afefcf7e27425933f1e2f4a8b8f11 /scripts/libmakepkg/util/schema.sh.in | |
parent | adb961a88e6644d5edb16cfcb5dbd1f02e4a1781 (diff) | |
download | pacman-d197d8ab82cf10650487518fb968067897a12775.tar.gz pacman-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 'scripts/libmakepkg/util/schema.sh.in')
0 files changed, 0 insertions, 0 deletions