Bugzilla – Bug 47214
VUL-0: CVE-2003-0792: remote vulnerability in fetchmail
Last modified: 2021-10-09 15:07:46 UTC
It came via vendor-sec, it will be released at 16th Oct. I deleted the original mails, but when I followed the thread correctly, this is the fix: * When rewriting a header to qualify email addresses, update the length (the header must not contain NUL bytes) to account for newly-added text so that we avoid chopping off data when the line is stored in the headers list. Originally based on a patch against 6.2.4. diff -uNr fetchmail-6.2.4/fetchmail.h fetchmail-6.2.4/fetchmail.h --- fetchmail-6.2.4/fetchmail.h 2003-08-05 23:30:16.000000000 -0400 +++ fetchmail-6.2.4/fetchmail.h 2003-10-09 15:36:07.000000000 -0400 @@ -508,7 +508,7 @@ void close_warning_by_mail(struct query *, struct msgblk *); /* rfc822.c: RFC822 header parsing */ -unsigned char *reply_hack(unsigned char *, const unsigned char *); +unsigned char *reply_hack(unsigned char *, const unsigned char *, int *); unsigned char *nxtaddr(const unsigned char *); /* uid.c: UID support */ diff -uNr fetchmail-6.2.4/rfc822.c fetchmail-6.2.4/rfc822.c --- fetchmail-6.2.4/rfc822.c 2003-10-09 15:38:42.000000000 -0400 +++ fetchmail-6.2.4/rfc822.c 2003-10-09 15:36:33.000000000 -0400 @@ -39,10 +39,11 @@ #define HEADER_END(p) ((p)[0] == '\n' && ((p)[1] != ' ' && (p)[1] != '\t')) -unsigned char *reply_hack(buf, host) +unsigned char *reply_hack(buf, host, length) /* hack message headers so replies will work properly */ unsigned char *buf; /* header to be hacked */ const unsigned char *host; /* server hostname */ +int *length; { unsigned char *from, *cp, last_nws = '\0', *parens_from = NULL; int parendepth, state, has_bare_name_part, has_host_part; @@ -193,6 +194,7 @@ if (outlevel >= O_DEBUG) report_complete(stdout, _("Rewritten version is %s\n"), buf); #endif /* TESTMAIN */ + *length = strlen(buf); return(buf); } diff -uNr fetchmail-6.2.4/transact.c fetchmail-6.2.4/transact.c --- fetchmail-6.2.4/transact.c 2003-08-05 23:30:19.000000000 -0400 +++ fetchmail-6.2.4/transact.c 2003-10-09 15:28:40.000000000 -0400 @@ -693,7 +693,7 @@ } if (ctl->rewrite) - line = reply_hack(line, ctl->server.truename); + line = reply_hack(line, ctl->server.truename, &linelen); /* * OK, this is messy. If we're forwarding by SMTP, it's the
<!-- SBZ_reproduce --> No idea, probably by some odd headers.
Vinil, is Stanislav on vacation? Roman.
Yes. Ask Tomas Crhak instead. Already in CC. Does it work for you?
I have created the patches, no I'm thinking of the text for putonftp and patchinfo. Do you know what the attacker can do? Make fetchmail segfault, run malicious code?
Hallooo, the packages are ready, I only need to write the putonftp and patchinfo files. Could anybody enlight the questions of Comment #4. Or at least translate to German: This update fixes a remote vulnerability of fetchmail by means of malicious headers. EOT It would be nice to have the update before 16th Oct. Thanks
Created attachment 14903 [details] mails on vendor-sec; Summary from Mark Cox and reply from DaveJ.
marking this critical. Tomas, I have added an attachment to this bug with two mails for verification if all bugs are fixed. A brief look at it is appreciated. CVE IDs for the two issues are CAN-2003-0790 and CAN-2003-0792. putonftp following...
putonftp (please don't forget to change the two occurrences of the distribution version!): ALL 7.3-ALL %UPDATE7.3 dxp Security update: This update fixes buffer overflows that can cause a Denial of Service (DoS) to fetchmail if a specially drafted email is being transferred. EOT Sicherheitsupdate für das fetchmail-Paket: Durch einen Pufferüberlauf kann fetchmail beim Transport einer speziell geformten email abstürzen (DoS-Angriff). EOT
To comment #4: We don't know if it is exploitable, and we can't tell as long as there is no exploit. However, it's easier to fix than to exploit it.
Tomas, may I assign this bug to you for as long as you are taking over from Stanislav? Just to make sure that nothing gets lost and everything is in good hands... Roman.
Additional info from vendor-sec: Date: Tue, 14 Oct 2003 13:10:53 +0100 (BST) From: Mark J Cox <mjc@redhat.com> To: Nalin Dahyabhai <nalin@redhat.com>, vendor-sec@lst.de Cc: Eric S. Raymond <esr@thyrsus.com> 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 proSecondly, 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. blem, however testing 6.2.4 with the rfc822.c patches, this test email still causes the corruption of headers. 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. Therefore I believe that diefetchmail.txt is not a trigger for CAN-2003-0790.
Hm, when I look at this issue, we have a fix for CAN-2003-0792. Looks like 0790 is only for OpenBSD? If not we miss a fix somewhere.
Yes, it seems we have CAN-2003-0792 only. Moreover, from the attachment in Comment #6 I understand that only 6.2.4 (and possibly 6.2.3) is affected. I looked in the code of transact.c in more detail: the patch from Initial Comment would do nothing with 6.2.3 (SL 9.0) and I expect the same for SL < 9.0. Should Comment #9 be interpretted as "let us apply the patch anyway" (It is prepared as I've already noted, but I did not scrutinize the code then)? What about 0790? I was not able to find nothing adequate on the net so far.
I will asked the RH dudes. They confuse me plus theyx had some odd posting regarding some QA stuff they noticed. I will ask them to send us all of the latest patches.
I talked to them. 0790 is a non issue. It is some OpenBSD stuff. 0792 is only an issue if it is 6.2.4. Which version do we have?
<= 6.2.3 only
So, this is not an issue for us then. I will close this case now.
CVE-2003-0792: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)