[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg-buildpackage (-rfakeroot) leaves setuid binaries

This can be a real security hole, at least when you are not aware of it (I have just discovered a working way to exploit it on one of my machines).

dpkg-buildpackage makes a semi-real "make install" into a sub directory of the debian/ directory in the source dir, and then tar's the installed files. The installed files have the real final permissions, which may include suid/sgid bits. The debian build programs do *NOT* protect the subdir, thus it may be entered by anyone on the system who has access to the source tree and he may execute the binaries therein. Since programs sometimes make assumptions about where they are installed, or which libraries they link at runtime, it is not safe to execute them from there.

Now you may say "don't build packages as root, use fakeroot instead". Well I have always used it, and somehow thought I'm safe, but I'm not: the permissions modes (like 4755) make it through to the real filesystem, only the owner/group is faked. Thus I'm left with binaries setuid *me* or setgid *my group* afterwards. That's only slightly better than root, since I'm also the admin and once my account is hijacked it's not far from being root.

It seems the only way around this (currently) is to compile packages in a directory with 0700 permissions.

I could think of two ways to improve this situation:
a) change fakeroot so it doesn't write the set[gu]id bits to disk (esp. if the faked owner/group differs from the real owner/group). b) change the debian build process so it creates the temp folders with 0700 permissions.


(BTW a somewhat similar problem (but not debian specific) exists with the perl CPAN module build process: -MCPAN is designed to work as root. It downloads the tarball, extracts it (with the user/group that the author packed them) as root, thus you are left with files belonging to random system users. -MCPAN doesn't take any precautions to protect the .cpan/build/ folder, thus with a bit luck some user on the system can modify the unpacked files before they are built/installed by root.)

Reply to: