--- Begin Message ---
- From: James Ralston <qralston+ml bugtraq andrew cmu edu>
- To: <BUGTRAQ SECURITYFOCUS COM>
- Subject: Re: RPM building races
- Date: Wed, 21 Mar 2001 19:29:49 -0500 (EST)
Unfortunately, if you're doing pretty much any type of development
work on a machine that contains users you can't trust, and you haven't
taken very specific steps to protect yourself, you've pretty much
lost.
A prime example (already mentioned by Jeff Johnson on the rpm list) is
gcc: by default, it creates temporary files in /tmp, and although it
would take some effort, there are probably exploitable race conditions
there.
If you have to do development work on a machine that contains users
you can't trust, you need to relocate your entire development process
to a subdirectory that you exclusively control; for example, a
subdirectory of your home directory, or a directory in /tmp or
/var/tmp that you've created and inspected manually.
For example:
$ mktemp -d /tmp/RPM-XXXXXX
/tmp/RPM-oge8Ic
$ mkdir /tmp/RPM-oge8Ic/TMP
$ TMPDIR=/tmp/RPM-oge8Ic/TMP; export TMPDIR
$ cd /tmp/RPM-oge8Ic
$ mkdir BUILD RPMS SOURCES SPECS SRPMS
Then in your ~/.rpmmacros, put:
%_topdir /tmp/RPM-oge8Ic
%_tmppath /tmp/RPM-oge8Ic/TMP
Even these steps might not protect you, if during the build process
you wind up executing development tools that don't respect the TMPDIR
environment variable.
If you're distributing a source RPM, and you want to make sure that a
naive user who rebuilds from the source RPM in an untrusted
environment can't be exploited by a race condition, you can more or
less do it, but it's not trivial. I've attached a skeleton spec file
as an example.
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
On Mon, 19 Mar 2001, Ian Lynagh wrote:
> I have attached a patch against gzip-1.3-6 from RedHat which pauses
> the build process at various points and lists commands that will
> build a gzip RPM in which the gzip binary simply echos foo. To
> exploit this race for real is difficult, and you need an account on
> the machine in question, but even so I think problems like these
> should be fixed. There may also be easier races in other packages.
> I am not overly familiar with RPM, but I think the easiest solution
> would be to set the default buildroot on all packages to be
> something like ./rpm-building/%{package} or, slightly more work, to
> make sure the buildroot is secure before you do anythign else in
> there.
Summary: An example skeleton spec file that [re]builds securely.
Name: skeleton-spec-file
Version: 1.0
Release: 1
# change the copyright to whatever is appropriate for your package
Copyright: none
# Group, Source, Patch, etc. go here
BuildPreReq: /bin/mktemp mktemp
Buildroot: %(/bin/mktemp -d %{_tmppath}/%{name}-%{version}-root-XXXXXX)
%prep
if [ "x`%__id -u`x" = x0x ]; then
set +x
echo "Error: you should *NEVER* build or rebuild RPMs as root."
echo "Please set up rpm for a regular user account, and build using that account."
exit 1
fi
%setup -q
# rest of prep commands (e.g. patch macros) go here
%build
TMPDIR=`mktemp -d %{_tmppath}/RPM-XXXXXX`
export TMPDIR
# build commands (configure, make, etc.) go here
%__rm -r "${TMPDIR}"
%install
[ -n "${RPM_BUILD_ROOT}" ] && [ -d "${RPM_BUILD_ROOT}" ] || {
set +x
echo "Error: directory ${RPM_BUILD_ROOT} does not exist."
exit 1
}
# install commands ("make install", etc.) go here
%clean
[ -n "${RPM_BUILD_ROOT}" ] && [ "${RPM_BUILD_ROOT}" != / ] && %__rm -rf "${RPM_BUILD_ROOT}"
# This next line is optional; I like to include it because it saves
# naive users from having to deal with a big blob of stuff in the
# BUILD directory when they're done...
( cd "${RPM_BUILD_DIR}" && %__rm -rf "%{name}-%{version}" )
%files
%defattr(-,root,root)
# list files here
%changelog
* Wed Mar 21 2001 James Ralston <ralston@pobox.com>
- created this skeleton spec file as an example
- NO WARRANTY, NO COPYRIGHT: use at your own risk.
--- End Message ---