Bug 499252 - (CVE-2009-1490) CVE-2009-1490 sendmail: long first header can overflow into message body
CVE-2009-1490 sendmail: long first header can overflow into message body
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 499447 499448 499449 499450
Blocks: 512878
  Show dependency treegraph
Reported: 2009-05-05 15:49 EDT by Vincent Danen
Modified: 2013-05-08 13:37 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512878 (view as bug list)
Last Closed: 2013-05-08 13:37:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch taken from upstream changes (517 bytes, patch)
2009-05-06 11:11 EDT, Vincent Danen
no flags Details | Diff
better patch taken from upstream changes (914 bytes, patch)
2009-05-06 17:18 EDT, Vincent Danen
no flags Details | Diff

  None (edit)
Description Vincent Danen 2009-05-05 15:49:13 EDT
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.
Comment 1 Vincent Danen 2009-05-05 16:05:35 EDT
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.
Comment 2 Vincent Danen 2009-05-05 16:38:08 EDT
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
Connected to localhost.localdomain (
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
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).
Comment 3 Tomas Hoger 2009-05-06 07:00:04 EDT
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)
Comment 5 Vincent Danen 2009-05-06 11:09:56 EDT
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.
Comment 6 Vincent Danen 2009-05-06 11:11:41 EDT
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.
Comment 8 Vincent Danen 2009-05-06 17:18:37 EDT
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.
Comment 9 Mark J. Cox 2009-05-06 17:37:33 EDT
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.
Comment 15 Vincent Danen 2009-05-07 00:49:04 EDT
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.
Comment 18 Mark J. Cox 2009-05-07 04:21:09 EDT
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:
+            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';
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).

Note You need to log in before you can comment on or make changes to this bug.