era eriksson <era(_at_)iki(_dot_)fi> writes:
I'm on a spam forwarding list* and the other day -- about a week ago
-- there was a message which came in from this list which would make
Procmail dump core. ...
...
I ran gdb on the core dump on a Digital and it was able to tell me
that there had been a segmentation violation inside a (__valloc()
inside a) malloc() but that's it. (The mailhost is a similar machine
but logins are not allowed so it might not be running the same binary
I have here.) The Procmail version on that machine is 3.11pre4.
Running strings(1) on the core reveals an absolutely huge list of
recipients in the To: field.
What I'm wondering now is, is there something in Procmail itself that
is the matter or have I just been careless with my recipes? There are
not many backticks in my recipes but some other things which might be
affected by LINEBUF.
Do you capture anything from the message (say, the value of the To:
field) and then ask procmail to expand it? If so, there's your
coredump, as procmail will do that expansion in a LINEBUF buffer
and your recipe will choke. Note that the following recipe has such
a problem:
TO=`formail -xTo:`
:0
|foo $TO
while this one doesn't:
TO=`formail -xTo:`
:0
|foo $TO;
as the semicolon forces a shell invocation, and the shell shouldn't
have such limitations (if it does, berate your vendor).
Yes, this theoretically (I've never heard of it being done) could
result in someone being able to break into your account by sending you
a wacky binary message that'll make procmail do Bad Things. For this
reason as well as the prevention of those annoying coredumps, I think
procmail should do some buffer checks while expanding. Yeah, Stephen,
it'll make readparse() even uglier, but it would give you an excuse to
remove the "pre" from the version number.
I'll mail the core (42k gzipped -- about half a meg when you unzip it
[it's full of "holes"]) and pertinent .rc files to anyone interested
enough to have a look. I'm no good at debugging myself. (Out of
curiosity, it would be interesting to know if it's possible to extract
the message out of the core, although I already downloaded it from the
spam mailing list's archive and had a look at it myself. It looks
somewhat malformed, BTW.)
The coredumping expansion may have overwritten the beginning of the
message, but the message should be in the core file as one solid chunk.
Try browsing it with emacs (one of the good uses of emacs) -- you can
mark the wanted chunk then M-x write-region.
Philip Guenther