[pacman-dev] Security vuln. in makepkg?
Greetings, I've come across unexpected behavior in makepkg. One of several possible outcomes of this quirk is the ability to create files outside of the build environment. They are not included in the package, so the package manager is unaware of them. Moreover only the build process is affected, installation not a factor. In this manner, these untracked files can propogate to directories with write access by the user. It's unclear if this is a limitation of fakeroot or makepkg but I will continue to investigate. Here is a simple demonstration of this exploit. ========== Makefile ========== install: @wall creating ${HOME}/.bashrc-evil @touch ${HOME}/.bashrc-evil ========== PKGBUILD =========== pkgname=hello-world pkgver=0.1 pkgrel=1 pkgdesc="Friendly package" arch=('any') source=('Makefile') md5sums=(SKIP) build() { cd "$srcdir" make } package() { cd "$srcdir" make DESTDIR="${pkgdir}" install } ================ $ makepkg ==> Making package: hello-world 0.1-1 (Fri Sep 4 15:08:04 GMT 2015) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found Makefile ==> Validating source files with md5sums... Makefile ... Skipped ==> Extracting sources... ==> Removing existing $pkgdir/ directory... ==> Starting build()... Broadcast message from hazard@archlinux (pts/4) (Fri Sep 4 15:08:04 2015): creating /home/hazard/.bashrc-evil ==> Entering fakeroot environment... ==> Starting package()... ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. Broadcast message from hazard@archlinux (pts/4) (Fri Sep 4 15:08:05 2015): creating /home/hazard/.bashrc-evil ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package "hello-world"... -> Generating .PKGINFO file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: hello-world 0.1-1 (Fri Sep 4 15:08:05 GMT 2015) $ tar -tf hello-world-0.1-1-any.pkg.tar.xz .PKGINFO .MTREE $ ls ~/.bashrc-evil /home/hazard/.bashrc-evil $ pacman -Qo ~/.bashrc-evil error: No package owns /home/hazard/.bashrc-evil ================== It should be noted that I only caught this because makepkg failed to build a certain package due to a lack of write access to the home directory (apacman AUR wrapper uses a restricted user to build). There was that controversial change back in pacman 4.2 to prevent makepkg running as root, I propose that makepkg should not run as the current user either but instead a dedicated unprivileged user. See here for more info: github.com/oshazard/apacman/issues/23 Sincerely, hazard (Archlinux BBS and AUR) P.S. apologies if this is a dupe, last message was rejected
Yes, packaging scripts can write to files outside the directory -- that's known, documented behavior, and why we encourage folks to use an unprivileged build user. This behavior is shared by pacman's competitors -- neither dpkg, RPM, or others I'm aware of have effective technical measures to restrict write to directories writable by the build user but outside of the directories directly involved in packaging. On Fri, Sep 4, 2015 at 6:22 PM OS Hazard <oshazard@gmail.com> wrote:
Greetings,
I've come across unexpected behavior in makepkg. One of several possible outcomes of this quirk is the ability to create files outside of the build environment. They are not included in the package, so the package manager is unaware of them. Moreover only the build process is affected, installation not a factor. In this manner, these untracked files can propogate to directories with write access by the user. It's unclear if this is a limitation of fakeroot or makepkg but I will continue to investigate.
Here is a simple demonstration of this exploit.
========== Makefile ========== install: @wall creating ${HOME}/.bashrc-evil @touch ${HOME}/.bashrc-evil
========== PKGBUILD =========== pkgname=hello-world pkgver=0.1 pkgrel=1 pkgdesc="Friendly package" arch=('any') source=('Makefile') md5sums=(SKIP)
build() { cd "$srcdir" make }
package() { cd "$srcdir" make DESTDIR="${pkgdir}" install }
================ $ makepkg ==> Making package: hello-world 0.1-1 (Fri Sep 4 15:08:04 GMT 2015) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found Makefile ==> Validating source files with md5sums... Makefile ... Skipped ==> Extracting sources... ==> Removing existing $pkgdir/ directory... ==> Starting build()...
Broadcast message from hazard@archlinux (pts/4) (Fri Sep 4 15:08:04 2015):
creating /home/hazard/.bashrc-evil
==> Entering fakeroot environment... ==> Starting package()... ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Broadcast message from hazard@archlinux (pts/4) (Fri Sep 4 15:08:05 2015):
creating /home/hazard/.bashrc-evil
==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package "hello-world"... -> Generating .PKGINFO file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: hello-world 0.1-1 (Fri Sep 4 15:08:05 GMT 2015)
$ tar -tf hello-world-0.1-1-any.pkg.tar.xz .PKGINFO .MTREE
$ ls ~/.bashrc-evil /home/hazard/.bashrc-evil
$ pacman -Qo ~/.bashrc-evil error: No package owns /home/hazard/.bashrc-evil
==================
It should be noted that I only caught this because makepkg failed to build a certain package due to a lack of write access to the home directory (apacman AUR wrapper uses a restricted user to build).
There was that controversial change back in pacman 4.2 to prevent makepkg running as root, I propose that makepkg should not run as the current user either but instead a dedicated unprivileged user.
See here for more info: github.com/oshazard/apacman/issues/23
Sincerely, hazard (Archlinux BBS and AUR)
P.S. apologies if this is a dupe, last message was rejected
Either way, the package can do whatever it wants as root when it's installed. Building in a container is to provide protection from stupid mistakes, not an attacker.
On Fri, Sep 04, 2015 at 07:33:27PM -0400, Daniel Micay wrote:
Either way, the package can do whatever it wants as root when it's installed. Building in a container is to provide protection from stupid mistakes, not an attacker.
It think it would be useful if pacman warned against packages containing setuid/setgid binaries.
On Sun, Sep 6, 2015 at 6:02 AM, Mohammad_AlSaleh <ce.mohammad.alsaleh@gmail.com> wrote:
It think it would be useful if pacman warned against packages containing setuid/setgid binaries.
That might add too much noise, and I don't see any difference from a security standpoint. If you want to build in a container and avoid modifying the system, using unionfs-fuse with proot (no root needed) or aufs with chroot would probably do the trick.
On 06/09/15 06:02 AM, Mohammad_AlSaleh wrote:
On Fri, Sep 04, 2015 at 07:33:27PM -0400, Daniel Micay wrote:
Either way, the package can do whatever it wants as root when it's installed. Building in a container is to provide protection from stupid mistakes, not an attacker.
It think it would be useful if pacman warned against packages containing setuid/setgid binaries.
That's not what I'm talking about. A package gets to do whatever it wants as root when it's installed without having any setuid binaries.
participants (5)
-
Charles Duffy
-
Daniel Micay
-
David Manouchehri
-
Mohammad_AlSaleh
-
OS Hazard