Attachment 14903 Details for Bug 47214

mails on vendor-sec; Summary from Mark Cox and reply from DaveJ.

fetchmail-mails.txt (text/plain), 4.52 KB, created by Roman Drahtmueller on 2003-10-14 22:22:21 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Roman Drahtmueller

Created: 2003-10-14 22:22:21 UTC

Size: 4.52 KB

patch

obsolete

>From mjc@redhat.com Tue Oct 14 16:20:24 2003
>From: Mark J Cox <mjc@redhat.com>
>To: Nalin Dahyabhai <nalin@redhat.com>, vendor-sec@lst.de
>Cc: Eric S. Raymond <esr@thyrsus.com>
>Date: Tue, 14 Oct 2003 13:10:53 +0100 (BST)
>Subject: Re: [vendor-sec] Remote DoS in Fetchmail (exploit #2)
>
>Has anyone else looked in detail at these fetchmail issues?  Our QA folks
>noticed some inconsitancies and I've just taken a look through the source
>to try to figure out why and I think I've spotted some things we missed 
>the first time.
>
>So I originally allocated CAN-2003-0790 to the rfc822.c issues that the
>OpenBSD folks patched, based on the "diefetchmail.txt" trigger.  Dave said
>that the patch cured the problem, however testing 6.2.4 with the rfc822.c 
>patches, this test email still causes the corruption of headers.
>
>Therefore I believe that diefetchmail.txt is not a trigger for
>CAN-2003-0790.
>
>Secondly, I allocated CAN-2003-0792 for the issues that Nalin patched in
>transact.c, based on the "diefetchmail2.txt" trigger.  The patch fixes a
>problem where the code relies on the length of a line being unchanged
>after calling reply_hack().  Testing with 6.2.4, adding Nalins patch does
>fix this issue.  It also fixes the "diefetchmail.txt" trigger.
>
>However the code at fault in 6.2.4 is not present in previous versions -
>they use strlen(line) after calling reply_hack rather than relying on a
>strlen done before.
>
>Summary:
>
>	CAN-2003-0790 is for the OpenBSD patches which fix a potential
>	issue that may or may not be exploitable (I've not looked into
>	this yet).  All versions of fetchmail contain this issue.
>
>	CAN-2003-0792 doesn't affect 6.2.2 or previous.  It might not
>	affect 6.2.3, I didn't bother checking since we've never shipped 
>	that and it looks like it has other issues that were fixed in 
>	6.2.4.  So 6.2.4 is definately vulnerable, and those test mails 
>	can be used to trigger it.
>
>Anyone agree?
>
>Thanks, Mark
>-- 
>Mark J Cox / Red Hat Security Response Team
>
>
>
>
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From davej@redhat.com Tue Oct 14 16:20:29 2003
>From: Dave Jones <davej@redhat.com>
>To: Mark J Cox <mjc@redhat.com>
>Cc: Nalin Dahyabhai <nalin@redhat.com>, vendor-sec@lst.de,
>     Eric S. Raymond <esr@thyrsus.com>
>Date: Tue, 14 Oct 2003 15:06:12 +0100
>Subject: Re: [vendor-sec] Remote DoS in Fetchmail (exploit #2)
>
>On Tue, Oct 14, 2003 at 01:10:53PM +0100, Mark J Cox wrote:
>
> > So I originally allocated CAN-2003-0790 to the rfc822.c issues that the
> > OpenBSD folks patched, based on the "diefetchmail.txt" trigger.  Dave said
> > that the patch cured the problem, however testing 6.2.4 with the rfc822.c 
> > patches, this test email still causes the corruption of headers.
>
>Interesting. What corruption are you seeing ? For me, the segfault
>disappeared with this patch, and I didn't notice anything odd in the
>headers of the arrived mail (Though I don't recall looking too closely tbh)
>
> > Therefore I believe that diefetchmail.txt is not a trigger for
> > CAN-2003-0790.
>
>Unless it 'fixes' it as a side-effect. Like I said, it cures the
>segfault at least.
>
> > Secondly, I allocated CAN-2003-0792 for the issues that Nalin patched in
> > transact.c, based on the "diefetchmail2.txt" trigger.  The patch fixes a
> > problem where the code relies on the length of a line being unchanged
> > after calling reply_hack().  Testing with 6.2.4, adding Nalins patch does
> > fix this issue.  It also fixes the "diefetchmail.txt" trigger.
>
>Hmm, I've not tested with 6.2.4 + just Nalin's fix.
>
> > 	CAN-2003-0790 is for the OpenBSD patches which fix a potential
> > 	issue that may or may not be exploitable (I've not looked into
> > 	this yet).  All versions of fetchmail contain this issue.
>
>Depends on your definition of 'exploitable'. Remote DoS is certainly
>possible as I demonstrated. (If it wasn't I wouldn't have been aware of
>this issue at all).
> 
> > 	CAN-2003-0792 doesn't affect 6.2.2 or previous.  It might not
> > 	affect 6.2.3, I didn't bother checking since we've never shipped 
> > 	that and it looks like it has other issues that were fixed in 
> > 	6.2.4.  So 6.2.4 is definately vulnerable, and those test mails 
> > 	can be used to trigger it.
>
>For the record, I only tested using 6.2.4, both self-compiled, and
>Debian's 6.2.4 packages.  I don't run earlier versions anywhere to test.
>
>
>		Dave
>
>-- 
> Dave Jones     http://www.codemonkey.org.uk
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Actions: View

Attachments on bug 47214: 14903