Vulnerability Development mailing list archives

Re: bug in procmail (ver 3.14 maybe others?)


From: Philip Guenther <guenther () sendmail com>
Date: Sun, 24 Feb 2002 11:18:18 -0800

Ehud Tenenbaum <analyzer () 2xss com> writes:
Philip Guenther wrote:
...
(As a (long) side note: the only way I know to send a SIGALRM to a
setuid process is to exec it directly, leaving an alarm pending past the
exec, and even then new enough OSes don't even allow that.  It worked
under gdb because tracing disables setuid execution, but otherwise I
don't know how you would do it.  You can send 'tty signals' (INT, QUIT,
TSTP, HUP, WINCH, INFO) to setuid processes if it's in one of your
sessions.  That extends to some other signals (KILL and STOP), at least
some of the time, but I don't see how to arbitrarly send other signals
to setuid processes.)

On the other hand I disagree with you on this one, sigalrm is occur when
using alarm() in a program and therefor can be reproduced even without
the tracing (that how BOS found it in the first place) this has nothing
to do with gdb.

When a setuid process gets SIGALRM because it called alarm(), that isn't
'arbitrary'.  That's expected and (presumably) planned for: if a program
crashes from its own alarm() call, then it's simply a bug.  Perhaps it
would have been clearer if I had said that I don't see how to send an
arbitrary and _unexpected_ signal to a setuid process.  When I try to do
so under OpenBSD, I get EPERM errors.

<pause>

Ick, I see that this is an area where OpenBSD is more paranoid than
others, as both FreeBSD 4.2 and Linux 2.2.17 allow you to send more than
just tty signals to setuid processes in your session.  Seems like a bug
to me, but one we'll have to live with a goodly while.  Ah well, yet
another thing to audit in user programs.


As for procmail crashing from the SIGALRM it sent itself with alarm(),
you should upgrade to 3.15.2 and see if the problem is gone: versions
before then definitely could be made to do unsafe things in signals
handlers.  I'll fix for the next version the "lastexec==NULL in
ftimeout()" problem you pointed out so that procmail won't crash when
sent unexpected SIGALRM; if you find other problems in 3.15.2, please
email them to <bug () procmail org>.  Ditto for 3.22, though you should
probably wait til 3.23, to be released Real Soon Now, before spending
time banging on it.


Philip Guenther
Procmail Maintainer


Current thread: