On 13 Feb 2002, Phil Brutsche wrote:
> I can verify the segfault with the command line, and parts of the patch
> make sense (ie replacing strcpy with strncpy).
No, that doesn't always make sense. strncpy insists on filling the
output buffer with zeros if the source is shorter than the destination.
That is a waste of resources if the output buffer is large. strncpy is
NOT a suitable function for "copy this string to this buffer, which is
this long".
> I would wait to hear from Philip Hazel before I do anything rash like
> apply it, though.
I am about to take a detailed look. I've received an analysis from an
Exim user which concluded that most of the strcpy->strncpy changes are
bogus. I rather suspected that myself.
> My only question is: why didn't contact Philip Hazel before sending it
> off to bugtraq? That is the most logical course of action.
Indeed, I sent a mild reproof to the authors along those lines. However,
I also thanked them for doing the tests, because I've said for a long
time that I welcome any security auditing of Exim - even if some of the
conclusions are bogus. :-)
So far, the worst that I've heard this can do is for a local user to be
able to call Exim and make it crash. That isn't very high up on my scale
of priorities for "panic, must fix it immediately" bugs. Of course,
there may be something I've missed.
Most likely I'll sort something out and put out a new release sometime
next week. I am away at the FOSDEM meeting in Brussels from tomorrow
until next week. In an attempt to keep future scanners at bay, I will
insert comments into the source at points where I judge the proposed
changes are bogus.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
