On 15 August 1998, Philip Guenther <guenther(_at_)gac(_dot_)edu> wrote:
Liviu Daia <daia(_at_)stoilow(_dot_)imar(_dot_)ro> writes:
On 11 August 1998, D.A. Harris <rodmur(_at_)ecst(_dot_)csuchico(_dot_)edu>
wrote:
Maybe the point of the note I saw was that there are numerous
strcpy, strcmp, and strcat's that exist in procmail's source, which
might need conversion to strncpy, etc, etc., so as to minimize
potential future buffer overflows.
Well, as I said before, I don't think anybody in his right minds
would volunteer to dig through the code looking for overflows. But
there is something that could be done about it with relatively
minimal effort: run Procmail against a memory debugger. I happen to
have access to Insure++ here (that's a commercial memory debugger,
similar to but much better than Purify); so if anybody out there
would care to put together a kind of test suite, I'll run it, and
post the results here. If there is enough interest for that I'll
also post the coverage analysis report so that the suite can be
improved. Comments?
Well, I've dug through the procmail source quite a bit, to deduce
procmail's behaviour in various odd ball situations, to track down a
couple bugs, and modify it (I actually have pre-alpha hacks to teach
procmail LMTP, but they're too ugly for sharing).
Yes Philip, you are the exception confirming the rule (whatever that
means these days). :-) Apart from you and another person who wrote me
in private, so far I didn't see anybody claiming to have dug through
the sources actually doing something useful. Given the audience of
Procmail, this is not exactly a crowd, is it? Now, what could be the
reason for this overwhelming interest? :-)
[...]
Okay, other than known overflows, are there any? Possibly. procmail
was written to be as fast as possible given the design decisions, and
it mostly meets that criteria by way of being totally bummed** code.
This remembers me a famous quote about getting the wrong answer
fast. Sorry, I couldn't resist. Wait, if you replace "wrong answer"
with "security exploit", it's almost on-topic...
I'm relatively trusting in it, despite the obscurity of the code, for
a combination of two reasons. Having read the code and banged my head
on it, I can say that its author was very conscientious about the
whole issue (for example, there isn't a single staticly sized string
in procmail itself) and worked hard to be paranoid.
Well, what can I say. I don't know about the author, but personally
I can remember making mistakes before. I can also remember being wrong
at both the conception and the design levels before. Sometimes even
fundamentally wrong.
The other factor that tends to keep me from having nightmares is
that fact that other than the variable expansion problem, no one has
reported one. If you think about how much email is processed by
procmail across the globe, on how many different platforms, this seems
like relatively good evidence.
Actually, I never considered the fact that a lot of people maintain
something as a serious argument. Think f.i. of the Galilei case:
millions of people maintained for thousands of years that the Earth is
flat, right? Ok, closer to procmail, consider the following scenario:
assume I find an exploitable buffer overflow, and I send you a message
taking advantage of it; when I get to execute command on your machine,
I remove all traces of my intrusion (possibly involving just a "rm
-f core"). Procmail usually runs in background, you don't expect my
message, and I know exactly what procmail does when it crashes. Will
you notice anything unusual? Realistically, how many people would
detect my intrusion?
But we are drifting too far away from the initial topic. The fact
is the sources of procmail, as they are now, are enough obfuscated to
make auditing a PITA to almost anybody. I suppose you'll agree this is
a Bad Thing [TM]. Personally, I would feel much better knowing that two
dozen people have understood the sources, and they haven't found any
bug. So far, I didn't see this happening.
I'm not stupid enough to claim that procmail doesn't have any unknown
overflows, but I personally file it below most of libc on the ladder
of buffer overflow risks.
Given the sizes of most most libc's compared to the size of
procmail, you are probably right.
As for developing a test suite for procmail, good luck.
Nah, I was just advocating here, hoping to put other people at work.
As I said in a previous message, I'm not using procmail myself. :-)
I would suggest that you dig up a copy of the source to MH 6.x.x and
read the first two paragraphs of the comment written by Van Jacobson
at the top of sbr/m_getfld.c regarding the hacking of m_getfld().***
Nice. So, if I find a bug in that piece of code and send a bug
report to Van Jacobson (I won't dare trying to fix it myself, in order
to avoid my children "cursing" me), he'll have to change a "heavily
tuned" routine, which is "a bit complex", where "every line [...]
depends on every other line", and where "minor bugs" could result in
"garbaged or lost mail". Right? Not to mention that, somehow, I'm not
exactly convinced Van Jacobson's quote is really appropriate in this
context. :-)
A sample of email, incoming and outgoing, from a random machine on the
Internet would probably be a good start from the coverage angle.
True.
Regards,
Liviu
--
Dr. Liviu Daia e-mail: daia(_at_)stoilow(_dot_)imar(_dot_)ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: finger
daia(_at_)stoilow(_dot_)imar(_dot_)ro