Bug#789404: pbuilder: insecure use of /tmp
On Mon, Aug 10, 2015 at 01:32:54AM +0200, Jakub Wilk wrote: > * Jakub Wilk , 2015-06-20, 17:04: > >pbuilder builds the package in $BUILDPLACE/tmp/buildd. But $BUILDPLACE/tmp > >is normally world-writable, and pbuilder doesn't fail if the buildd > >direcory already exists: > > > > mkdir -p "$BUILDPLACE/tmp/buildd" > > > >There's a race window between unpacking base.tgz and the mkdir call when > >malicious local user could create their own $BUILDPLACE/tmp/buildd. > > As Mattia correctly noted in another mail, tmp/builddr is stored in the > tarball, so (assuming that tar unpacks it securely...) there's no race > window when you build a package. *can* be stored in the tarball. If a user wants to use it's own tarball creation system the directory will be created at build time. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature
Bug#789404: pbuilder: insecure use of /tmp
Correction: * Jakub Wilk , 2015-06-20, 17:04: pbuilder builds the package in $BUILDPLACE/tmp/buildd. But $BUILDPLACE/tmp is normally world-writable, and pbuilder doesn't fail if the buildd direcory already exists: mkdir -p "$BUILDPLACE/tmp/buildd" There's a race window between unpacking base.tgz and the mkdir call when malicious local user could create their own $BUILDPLACE/tmp/buildd. As Mattia correctly noted in another mail, tmp/builddr is stored in the tarball, so (assuming that tar unpacks it securely...) there's no race window when you build a package. Alternatively, the attacker could exploit #789401 to plant tmp/buildd directly in base.tgz. There's plenty of time for an attacker at bootstrap time, though. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789404: pbuilder: insecure use of /tmp
On Sun, Aug 09, 2015 at 09:05:12PM +, Thorsten Glaser wrote: > The current “let's move the build dir” stinks much more, why > not pre-create /tmp/build in the chroot to be writable only > to the buildd user? pbuilder currently creates /tmp/buildd at chroot creation time, just after debootstrap finishes. The creation command is a plain `mkdir -p`: * it's -p, it doesn't fail if it exists * it's not umask safe * it's owned by root:root (and chowned just before the build starts) ← good so the current state of affairs is suboptimal. Also, if the build directory is missing it's happily created by pbuilder while extracting the tarball. Now, is right, it could be improved by * forcing that directory to have certain perms * forcing that directory to have a certain owner * forcing that directory to be empty before copying the files A random user can currently happily implant /tmp/buildd right before (if it doesn't already exist), moving it to some other location (in this case just under /) makes this particular issue impossible. FYI, I have to improve the documentation, doing some more thorough tests and then I'll ask to a friend of mine to upload. I welcome tracking bugs for the 3 improvable points above -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature
Bug#789404: pbuilder: insecure use of /tmp
Jakub Wilk dixit: > And there's DoS aspect: local user could stuff chroot's /tmp with garbage, > which pbuilder then will have to compress and later decompress on every build. Meh, it's probably trivial to let it create the chroot inside a temporary directory other users may not traverse. The current “let's move the build dir” stinks much more, why not pre-create /tmp/build in the chroot to be writable only to the buildd user? bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789404: pbuilder: insecure use of /tmp
* Mattia Rizzolo , 2015-08-08, 17:00: I don't see how changing it can fix #789401, though. It would improve the situation, as a malicious local user can not plant the build dir any more Right. But there might be other /tmp vulnerabilities (in pbuilder or elsewhere) that #789401 would ease exploiting. And there's DoS aspect: local user could stuff chroot's /tmp with garbage, which pbuilder then will have to compress and later decompress on every build. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789404: pbuilder: insecure use of /tmp
Control: tags -1 pending Control: severity 789401 important On Wed, Aug 05, 2015 at 01:33:43PM +0200, Jakub Wilk wrote: > * Mattia Rizzolo , 2015-08-04, 07:41: > >>pbuilder builds the package in $BUILDPLACE/tmp/buildd. But > >>$BUILDPLACE/tmp is normally world-writable, and pbuilder doesn't fail if > >>the buildd direcory already exists: > >> > >> mkdir -p "$BUILDPLACE/tmp/buildd" > >> > >>There's a race window between unpacking base.tgz and the mkdir call when > >>malicious local user could create their own $BUILDPLACE/tmp/buildd. > >>Owning the buildd directory would let them tamper with the build > >>process. > >> > >>Alternatively, the attacker could exploit #789401 to plant tmp/buildd > >>directly in base.tgz. > > > >I think I'm going to solve both this and #789401 by making /tmp/buildd > >configurable > > Right. Moving the build directory outside /tmp will should fix this bug. done, by parametring the directory with BUILDDIR and changing the default to /build I forsee angry users, since /tmp/buildd is probably used in a lot of local script (hooks). Also the example hooks need updating, not to speak about docs → work. > I don't see how changing it can fix #789401, though. It would improve the situation, as a malicious local user can not plant the build dir any more (yes, it could still temper with /tmp, but with the actual build dir, which is somewhere else) > >and defaulting to another place, maybe the one used by sbuild (/buildd > >iirc) > > It's "/build" (with a single "d"). cool, thanks. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature
Bug#789404: pbuilder: insecure use of /tmp
* Mattia Rizzolo , 2015-08-04, 07:41: pbuilder builds the package in $BUILDPLACE/tmp/buildd. But $BUILDPLACE/tmp is normally world-writable, and pbuilder doesn't fail if the buildd direcory already exists: mkdir -p "$BUILDPLACE/tmp/buildd" There's a race window between unpacking base.tgz and the mkdir call when malicious local user could create their own $BUILDPLACE/tmp/buildd. Owning the buildd directory would let them tamper with the build process. Alternatively, the attacker could exploit #789401 to plant tmp/buildd directly in base.tgz. I think I'm going to solve both this and #789401 by making /tmp/buildd configurable Right. Moving the build directory outside /tmp will should fix this bug. I don't see how changing it can fix #789401, though. and defaulting to another place, maybe the one used by sbuild (/buildd iirc) It's "/build" (with a single "d"). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789404: pbuilder: insecure use of /tmp
On Sat, Jun 20, 2015 at 05:04:03PM +0200, Jakub Wilk wrote: > pbuilder builds the package in $BUILDPLACE/tmp/buildd. But $BUILDPLACE/tmp > is normally world-writable, and pbuilder doesn't fail if the buildd direcory > already exists: > >mkdir -p "$BUILDPLACE/tmp/buildd" > > There's a race window between unpacking base.tgz and the mkdir call when > malicious local user could create their own $BUILDPLACE/tmp/buildd. Owning > the buildd directory would let them tamper with the build process. > > Alternatively, the attacker could exploit #789401 to plant tmp/buildd > directly in base.tgz. I think I'm going to solve both this and #789401 by making /tmp/buildd configurable (so people wanting /tmp/buildd can still have it) and defaulting to another place, maybe the one used by sbuild (/buildd iirc) Does this sounds sane enough? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature
Bug#789404: pbuilder: insecure use of /tmp
Source: pbuilder Version: 0.215+nmu3 Severity: grave Tags: security pbuilder builds the package in $BUILDPLACE/tmp/buildd. But $BUILDPLACE/tmp is normally world-writable, and pbuilder doesn't fail if the buildd direcory already exists: mkdir -p "$BUILDPLACE/tmp/buildd" There's a race window between unpacking base.tgz and the mkdir call when malicious local user could create their own $BUILDPLACE/tmp/buildd. Owning the buildd directory would let them tamper with the build process. Alternatively, the attacker could exploit #789401 to plant tmp/buildd directly in base.tgz. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pbuilder depends on: ii coreutils 8.23-4 ii debconf [debconf-2.0] 1.5.56 ii debianutils4.5.1 ii debootstrap1.0.70 ii dpkg-dev 1.18.1 ii wget 1.16.3-2+b2 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
