SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

Thu Mar 23 18:15:29 UTC 2006

On Thu, 23 Mar 2006 03:41:52 CST, Gadi Evron said:

(I feel obligated to mention that there's 16 mentions of my name in the Sendmail
release notes, and zero of Gadi's.  This of course influences my opinions and
commentary, and possibly Gadi's as well...)

> ISS only reported the Race Condition (DoS?). The Sendmail Advisory
> reported the Race Condition DoS, the Memory Jumps and a
> "theoretical" Integer Overflow.

Well, it *is* mostly a theoretical overflow - for it to work, a site would have to:

a) Override the default value of "O MaxHeadersLength=32768" to something in the
billions *and*

b) Be running on a box with enough RAM/swap to allow a call to malloc(2**31) or
so to succeed.

Then the attacker actually has to (c) *send* some 2 gig of headers.

Well, OK.  If you can find somebody still running something pre-8.10.0 (2000/03/01),
you can bypass (a) - still need (b) and (c) though...

> To begin with, anyone noticed the memory leak they (Sendmail) silently
> patched?

I suspect it's not as silently as you think.  If you actually bothered to ask
Claus, he'll probably be able to tell you which RELEASE_NOTES entry the leak
was attached to, or why it wasn't listed (see below).

And it's hard for them to be *too* silent, given that anybody and their pet
llama Ralphie can get the 8.13.5 and 8.13.6 sources and diff them.

There's also the *practical* aspect.  Well over a quarter of the actual code
changes were due to the API change of *one* function.  You start change-logging
all this in the release notes, important things become easier to overlook...

> I wonder how many other unreported silently-patched
> vulnerabilities are out there?

It depends how you define "silently patched vulnerabilities".  I've found my
share of Sendmail bugs - and 100% of the ones I've reported that ever shipped
in a non-beta version are in the RELEASE_NOTES file.  (Those bugs others and I
swatted in new, as-yet-unshipped code in alpha and beta versions are *not* in
there - 8.12's multiple queue support didn't just spring forth essentially
bug-free, for instance.  Also, bugs found and fixed by Sendmail Inc employees
aren't listed - although if reported from outside, they will get a "problem
noted by" entry).

A bigger problem is that quite often, what gets fixed is a simple *bug* (for
instance, two I found in 8.12.2).  Are they vulnerabilities?  Good question.
Some of the "bugs" I've found could possibly be extended into a DoS (for instance,
what I *reported* in 8.12.2 was spontaneous queue-runner hangs due to losing a
timer event - but that *could* be crafted into a DoS if an attacker found a way
to control when things happened to force a timer event loss).

So was that a "silently patched vulnerability"? Or just a plain bug?

> Second, the Integer Overflow is practical, not theoretical.

You have an actual exploit that works on a config that isn't especially set
up to allow it to work (i.e. out of the box defaults, and a non-absurd amount
of network traffic)?  Or can you at least point out enough details of what
the exploit would have to do to convince me it's not just hand-waving?

In particular, how do you get past the MaxHeadersLength check?

> ISS reported the Race Condition last mounth. There is NO data available on
> when the other vulnerabilities were discovered. Any guesses?

The code drop for the fix of your "practical integer overflow" happened between
the Alpha0 on Dec 23 and Alpha1 on Feb 12.  You'll have to ask either Phil
Brass or Claus when that one got reported.

> Sendmail.com's patch is so big they may as well have re-released the whole
> program.

I don't know what shipped to sendmail.com's paying customers, but in fact,
sendmail.org *did* "re-release the whole program", as a quick check of
ftp://ftp.sendmail.org/pub/sendmail/ would have revealed....

And in fact, if you actually *diff* the two trees to create a patch, it's not
that large at all:

(numbers fudged very slightly to remove the diff of 2 versions of a Postscript
documentation file (doc/op/op.ps), which by itself was well over half the total
changes):

% diff -ur sendmail-8.13.[56] | wc -l
5253
% diff -ur sendmail-8.13.? | diffstat | grep change
58 files changed, 1411 insertions(+), 886 deletions(-)
% wc sendmail-8.13.6/*/*.[ch] | grep total
 122092  394315 2780756 total

Yeah. Whatever. Hell of a lot of code churn there.  Almost 2%.  A very large
chunk of it looking like:

@@ -4546,10 +4569,12 @@ 
        {       
                if (bitset(MCIF_INHEADER, mci->mci_flags))
                {
-                       putline("", mci);
+                       if (!putline("", mci))
+                               goto writeerr;
                        mci->mci_flags &= ~MCIF_INHEADER;
                }
-               putline("<<< No Message Collected >>>", mci);
+               if (!putline("<<< No Message Collected >>>", mci))
+                       goto writeerr;
                goto endofmessage;
        }

(and another 104 similar fixes of putline alone - that *by itself* is about 30%
of the code changes).

But of course, I'm writing this having actually *looked* at the diff, and having
bothered to ask Claus and Greg what the policy was for listing fixes in the release
notes...

Also, it would help if instead of FUD-mongering, you actually went to Claus
(or asked somebody else to) with *specific suggestions* of how to improve the
process.  He may be stubborn about the way he does things, but if you include
specific changes, and show how those changes make *visible* improvements to
the product, he'll listen.

(visible improvements - saying "It Would Be Nice If" doesn't cut it.  On the other
hand, replacing the IWBNI with "If X were done, then the security community would
be able to do Y, and the network operations community could do Z, with benefits
A, B, and C" - now *that* might get some traction...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060323/1abc6ef7/attachment.sig>
