[pacman-dev] [GIT] The official pacman repository branch, release/5.1.x, updated. v5.1.3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, release/5.1.x has been updated via 1bf767234363f7ad5933af3f7ce267c123017bde (commit) via 9702703633bec2c007730006de2aeec8587dfc84 (commit) from 0b36d8781783d7f4a0086e12eb7cae542e7f6bd7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 1bf767234363f7ad5933af3f7ce267c123017bde Author: Allan McRae <allan@archlinux.org> Date: Fri Mar 1 11:28:42 2019 +1000 Release v5.1.3 Signed-off-by: Allan McRae <allan@archlinux.org> commit 9702703633bec2c007730006de2aeec8587dfc84 Author: Andrew Gregory <andrew.gregory.8@gmail.com> Date: Fri Mar 1 11:23:20 2019 +1000 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> (cherry picked from commit d197d8ab82cf10650487518fb968067897a12775) ----------------------------------------------------------------------- Summary of changes: NEWS | 2 ++ configure.ac | 4 ++-- lib/libalpm/dload.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) hooks/post-receive -- The official pacman repository
participants (1)
-
Allan McRae