Common Vulnerabilities and Exposures assigned an identifier CVE-2009-1490 to the following vulnerability: Name: CVE-2009-1490 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1490 Assigned: 20090430 Reference: MISC: http://www.nmrc.org/~thegnome/blog/apr09/ Reference: CONFIRM: http://www.sendmail.org/releases/8.13.2 Heap-based buffer overflow in Sendmail before 8.13.2 allows remote attackers to cause a denial of service (daemon crash) and possibly execute arbitrary code via a long X- header, as demonstrated by an X-Testing header.
I'm confused by this one. I tested it with Fedora 10 and also with Red Hat Enterprise Linux 4 (the latter is supposed to be "vulnerable" because it is version 8.13.1). Mail is delivered, and the mail itself looks identical whether it's 8.13.1 or 8.14.3. I see no denial of service here. The 8.13.2 changelog indicates: 8.13.2/8.13.2 2004/12/15 Do not split the first header even if it exceeds the internal buffer size. Previously a part of such a header would end up in the body of the message. Problem noted by Simple Nomad of BindView. But this is exactly what is happening with 8.14.3. I'm trying to obtain more information from MITRE regarding this, and also find out why this wasn't assigned a 2004 CVE name since that is when it was originally reported and fixed.
Ok, I get this more now. This definitely affects Red Hat Enterprise Linux 4 and probably earlier. Pasting in an X-Testing header containing 8k characters (could probably get away with less, but the sample in the blog posting doesn't trigger it), makes the telnet session unresponsive and sendmail does nothing; it is most definitely hung up. Nothing in the logs, but no heavy CPU usage either. To test: [vdanen@odvrhel4]~% telnet localhost 25 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 odvrhel4.annvix.ca ESMTP Sendmail 8.13.1/8.13.1; Tue, 5 May 2009 13:26:04 -0700 mail from:vdanen@localhost 250 2.1.0 vdanen@localhost... Sender ok rcpt to:root@localhost 250 2.1.5 root@localhost... Recipient ok data 354 Enter mail, end with "." on a line by itself X-testing: [paste contents of perl -e 'print "A"x8000;'] On Fedora 10, sendmail happily accepts the whole thing and allows you to QUIT. On RHEL4, sendmail gets tied up and the session is unresponsive. I am not sure if this is exploitable or not, but the reporter indicates it is (you have to read both blog posts to get the entire jist of the situation; I had only read the first part).
Hung telnet session may actually be some problem of telnet. I do not see any delay / hang for scripted connection. What I can get is: - if all message headers are too long, this is reported: 552 5.6.0 Headers too large (32768 max) (this is sum of all headers, not a limit on single header line) - if long X-Testing header is not the first header, it gets truncated to a total of 2048 characters - if long X-Testing header is the first header, it's truncated to 2048 chars too but part of it appears as part of body, all subsequent headers appear in body too (this seems to be a fix mentioned in the above upstream changelog message)
You're right, the telnet case was bad as it hung after I patched sendmail. Using a scripted test, it completes in both cases and the mail is delivered. Pre-patch, the body gets filled with the overflow of the long X-Testing header; post-patch it is discarded and X-Testing header is truncated. Pre-patch, the X-Testing header is truncated to 2047 characters, post-patch it's truncated to 2048.
Created attachment 342673 [details] patch taken from upstream changes This patch prevents the long header from overflowing into the body of the email, taken from a diff between 8.13.1 and 8.13.2.
Created attachment 342730 [details] better patch taken from upstream changes This patch includes one possibly-relevant missing hunk from the upstream changes between 8.13.1 and 8.13.2.
We're working on an emergency update with this patch for the Red Hat Enterprise Linux 2.1, 3, and 4 versions of sendmail that it affects. Although this flaw has been reported as being able to cause a heap overflow of Sendmail, the Red Hat Security Response Team have not yet been able to reproduce this claim based on a technical analysis of the code and some attempts at reproducing it. We're putting our effort into getting a set up updates ready to go out should our continued investigation look like this could possibly lead to an overflow.
Based on upstream comments, the initial patch (comment #6) is the correct patch to fix the long X header issue, and the obuf changes are not a part of that issue at all.
The Red Hat Security Response Team have performed a technical review of this flaw. We have verified there was a bug which can cause a malformed header to wrap into the body of an email, but our review of this bug did not find an exploitable security issue (heap or buffer overflow) in our currently shipping versions of this code. Here is a summary: The flaw disclosed is caused by connecting to sendmail and sending a malformed first header line, that line ends up split with part of it in the body of the email. This bug was disclosed by the reporter to sendmail and fixed by sendmail upstream with a patch in 8.13.2 and the following release note: 8.13.2/8.13.2 2004/12/15 Do not split the first header even if it exceeds the internal buffer size. Previously a part of such a header would end up in the body of the message. Problem noted by Simple Nomad of BindView. Here is the patch used by upstream to correct that issue: --- sendmail-8.13.1/sendmail/collect.c.org 2009-05-06 08:25:43.000000000 -0600 +++ sendmail-8.13.1/sendmail/collect.c 2009-05-06 08:26:53.000000000 -0600 @@ -513,15 +513,12 @@ bufferchar: case MS_DISCARD: continue; } + SM_ASSERT(mstate == MS_UFROM || mstate == MS_HEADER); /* header -- buffer up */ if (bp >= &buf[buflen - 2]) { char *obuf; - - if (mstate != MS_HEADER) - break; - /* out of space for header */ obuf = buf; if (buflen < MEMCHUNKSIZE) The removed check for MS_HEADER state corrects the "header overflow into body" issue. This is because the first line of the email message is usually the initial "From" line, which the code handles slightly differently, and so for this first line of the message we are in MS_UFROM state, not MS_HEADER state. So if the first line of the message is actually a header that is too large for the static buffer (the buffer starts at 2048 bytes), the old code breaks immediately to the end-of-line handler, instead of growing the buffer as it would do for any other header. At that point in the code it's then handled like a normal header, and so remaining part of the line (the bit that didn't fit in the static buffer) it taken to be the start of the next line. This new line no longer looks like a header, and as a result is output into the body, along with any subsequent headers. This piece of code: 587 if (istate == IS_BOL) 588 break; 589 } 590 *bp = '\0'; 591 592 nextstate: ensures that the first line, although truncated, is still properly terminated and will therefore be handled safely. So the upstream patch above fixes this issue by expanding the buffer if needed for the first line just as it would for any other header. Based on this analysis this issue has no security consequences and does not lead to a buffer overflow. Instead, a carefully crafted connection to sendmail can cause information in the header to appear in the body, but this is just a bug (and there are also other ways in which malformed headers would cause sendmail to treat the rest of the headers as the body).