On Fri, Nov 04, 2005 at 09:51:19AM -0500, Noah Meyerhans wrote: > > Where was that talk done? I've been the one auditing that and there have > > been > > DSAs for most of the bugs I've reported to the audit team. Granted, they are > > not being issued inmediately (I usually provide the report and a patch), but > > they are on the queue as far as I know. > > Yes, your numerous reports are what lead to this discussion, which > happened within [EMAIL PROTECTED] Basically somebody was like "whoa, we'll > never be able to fix all of these! And why should we, anyway, since the > problems are so minor?" So it was proposed to at least provide an > additional layer of safety so we can say that this class of bugs > generally does not affect our default configuration.
The problem is, there are some issues which are *not* minor. Packages
that hardcode /tmp are either, from my experience:
- old stuff that was written when /tmp/something.$$ was believed random
enough and safe. Easily fixed with a proper patch.
- new stuff that has been coded in a sloppy way, reviewing that code usually
brings up a lot of other security bugs.
Sometimes, the /tmp bugs are more serious that one might believe at first
sight because:
a) they are predictable, i.e. a cron task runs the code or a daemon does it
periodically. For an example, see #256381
b) the code is run as root, not as $RANDOM user. For an example, see #249616
It's even worst if a) and b) happen together, for example see #256377, or
#329384. Those kind of bugs should have a DSA, they are not minor bugs.
> > The problem is, there's lots of those. And when I mean lots I mean that I
> > have a list of ~4780 binary packages of which at least ~2300 make use of
> > insecure tempfiles for sure and the others need to be reviewed (as the
> > script
>
> So can we really be expected to release ~2300 DSAs to fix all these
> things? Even with patches to fix them, it's going to be an insane
> amount of work. This is exactly why we want libpam_tmpdir.
You will have to, regardless of libpam_tmpdir. As I've said, those have
hardcoded /tmp paths in them so libpam_tmpdir will not prevent the attack.
From what I've seen, those that make use of TMPDIR (either explicitly or
because they use 'mktemp -d' or 'tempfile') seldom have race conditions.
IMHO, the use of $TMP or $TMPDIR should be mandated first in order for the
introduction of libpam_tmpdir to be really effective.
> You may be right that a policy change would be required. Packages would
> need to respect $TMP or $TMPDIR in order for this proposal to work. As
> has been pointed out earlier (Joey Hess mentioned CUPS breaking), this
> may result in a number of bugs.
A number is an understimation. There's lots of programs out there with
hardcoded /tmp stuff that are _not_ vulnerable to symlink attacks which would
need to be found and fixed.
A final point for consideration: libpam_tmpdir is not going to drive symlink
attacks through temporary files away. There are packages that use temporary
directories but are _not_ tmp. Some examples: the system's /var/lock/ and
/dev/shm/, php4'as /var/lib/php4 (see #257111 for some discussion about
this), php5's /var/lib/php5, transcriber's /var/lib/transcriber/ (fixed, see
#257112), apache-common's /var/lib/apache/mod-bandwidth/ (see #257108, which
was "fixed" with a simple note in the README.Debian file), tetex-base's
/var/cache/fonts/{pk,source,tfm} and /var/spool/texmf/{pk,source,tfm}. All
those are possible targets for security vulnerabilities for the programs that
use them and will not be covered by the introduction of libpam_tmpdir.
Regards
Javier
signature.asc
Description: Digital signature
