Re: [Mutt] #2846: Security vulnerability in APOP authentication
#2846: Security vulnerability in APOP authentication
Comment (by Brendan Cully):
{{{
On Saturday, 07 April 2007 at 21:22, Matthias Andree wrote:
> Brendan Cully <brendan@xxxxxxxxxx> writes:
>
> > On Sunday, 18 March 2007 at 17:36, Rocco Rutte wrote:
> >> I was looking at some mutt code for this issue and other issues that
> >> report broken threading upon invalid message-ids. It seems that mutt
> >> happily accepts the following syntax: '<.*>' which is just plain
wrong.
> >>
> >> I looked at rfc822.c to try to reuse address parsing for parsing
> >> message-ids but failed since I didn't have much time and the quote
is
> >> quite complex.
> >>
> >> Even though adopting your code for mutt would be quite easy, I'm not
> >> yet sure what to do in case of validation errors.
> >>
> >> Say we get '<foobar>' during APOP authentication; should be really
> >> reject that and report failed authentication? If a message has
> >> '<foobar>' as message-id and others have it in their References:
> >> header, should we really ignore it and break threading?
> >
> > Here's a patch that does a really minimal check that the message ID is
> > of the form <x@y> where x and y are between ASCII 0 and 127. I hope
> > that it's enough to thwart the MD5 collision attack, but liberal
> > enough to tolerate the range of broken POP servers out there. The @y
> > test could be easily removed if necessary.
>
> May I again offer to use my code here which I deem a *COMPLETE*
> RFC822-validation:
> <http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/rfc822valid.c>
I'm afraid that doing heavy validation may introduce interoperability
problems with some buggy POP servers. Since odd timestamps are
generally harmless in this context, I'd rather do the minimum needed
to suppress this vulnerability than enforce strict compliance with the
RFC.
}}}
--
Ticket URL: <http://www.mutt.org/ticket/2846#comment:>