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

Re: RFS: tleds 1.05beta10-9 (was: Packages which aren't getting into "testing")

Hi Russ,

On Wed, Aug 24, 2005 at 03:09:58AM -0700, Russ Allbery wrote:
> Russ Allbery <rra@stanford.edu> writes:
> > Nathanael Nerode <neroden@twcny.rr.com> writes:

> >> tleds (patched security RC bug)
> >>   Needs a QA upload to change maintainer.

> > I'm doing this one now.  Packages will be available for sponsoring in a
> > little bit.

> I've given the package a thorough and much-needed cleaning, applied all
> the patches in the BTS that looked reasonable and that I could test,
> updated standards version, switched to a modern debhelper compatibility
> level, and cleaned up all the lintian warnings and PTS to-do items.
> Hopefully this will make it easier for any future maintainer to adopt the
> package.

> I'd much appreciate it if someone could sponsor the upload.  You can get
> the source package from:

>     deb-src http://archives.eyrie.org/debian unstable main

> or via the corresponding direct paths.

> Thanks!

> (I'm not really interested in adopting it, but it's a rather cute little
> thing.)

The tmp file handling in this version is definitely improved, but it
seems that only root is completely protected from malicious pidfiles:

- the user pidfile is created with a constant name
- when opening the pidfile, the ownership is not checked
- there is a race condition when using -k, where a new pidfile can be
  created after the old tleds process has exited but before the current
  process checks whether it succeeded.  (A rather large race condition,
  too -- tleds -k sleeps for 3 seconds, and no process should take that
  long to shut down on a modern system. :)

So an attack vector here is that the user calls tleds -k, the attacker
replaces the pidfile as soon as it's been removed with one of his own,
and tleds -k returns an error to the user; the user then re-runs tleds
-k without looking, and an arbitrary process belonging to the user is

Do you think this is worth fixing up before considering bug #276789
fixed?  There are probably very few processes that a stray SIGUSR1 can
do damage to on a typical system, but if it's worth protecting root
from, it's probably worth protecting users from as well.  In any case,
this is not the bug that 276789 is primarily concerned with.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: