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

[Philip Guenther <guenther () sendmail com>]

A coworker of mine on vuln-dev forwarded Ehud's message to me.
I'm not on the list, so please cc:guenther () sendmail com in your
replies.

> We have made few security checks on procmail and here is what we found,
> please read carefully and follow the instructions in order to
> re-produce:
<sending an unanticipated SIGALRM results in a segv>

The problem still exists in the current version.  It's 'just' a
NULL dereference if a unexpected ALRM is received.  I don't see
anyway to trick it into dereferencing anything but that or a valid
string, so while it's something to fix, to the best of my knowledge
it's not exploitable.  (Anyone know of a way to exploit a pure NULL
derefence?)

As for contacting the author, Stephen's currently on vacation,
which is why they haven't gotten a response.  bug () procmail org is
the prefered address for reporting bugs in procmail.

I don't know why they're testing such an old version.  RedHat at
least was notified of real security problems in versions before
3.15.2, so if they haven't released an updated RPM, it's their own
fault.


> The weird thing is that it segfault only with sigalrm (signal 14)
> we yet understand why exactly its happening, it could be a problem
> with the libaries handling the sig alrm.

Uh, it segfaults because a variable used by procmail's SIGALRM
handler is set to NULL except between the time procmail calls
alarm() and when it receives it or cancels the alarm.  Outside of
that period, procmail's SIGALRM handler will dereference a NULL
pointer.  The libraries are innocent.


Philip Guenther
guenther () sendmail com
Procmail Maintainer
--------
Information and opinions expressed above are not those of Sendmail, Inc.