A coworker of mine on vuln-dev forwarded Ehud's message to me. I'm not on the list, so please cc:guentherat_private 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. bugat_private 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 guentherat_private Procmail Maintainer -------- Information and opinions expressed above are not those of Sendmail, Inc.
This archive was generated by hypermail 2b30 : Sun Feb 24 2002 - 21:23:45 PST