Message-ID: <3F650396BF7B9985B3073590@143.115.96.204.in-addr.arpa>
Date: Thu, 23 Mar 2006 22:27:53 -0600
From: Eric Allman <eric+bugtraq@...philic.com>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: SendGate: Sendmail Multiple Vulnerabilities (Race
 Condition DoS, Memory Jumps, Integer Overflow)


I have to comment on these allegations by Gadi Evron.

> Tech details:
> Sendmail vulnerabilities were released yesterday. No real public
> announcements to speak of to the security community.

Sendmail, CERT, and ISS Advisories went out.  That's not a "real 
public announcement"?

> SecuriTeam released some data:
> "Improper timeout calculation, usage of memory jumps and integer
> overflows allow attackers to perfom a race condition DoS on
> sendmail, and may also execute arbitrary code."
> More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html
>
> ISS only reported the Race Condition (DoS?). The Sendmail Advisory
> reported the Race Condition DoS, the Memory Jumps and a
> "theoretical" Integer Overflow.
>
> To begin with, anyone noticed the memory leak they (Sendmail)
> silently patched?
> I wonder how many other unreported silently-patched
> vulnerabilities are out there?

There was no memory leak.  Look at the code referred to by SecuriTeam 
(see <http://www.securiteam.com/unixfocus/5SP0M0UI0G.html>):

/* clean up buf after it has been expanded with args */
 newstring = str2prt(buf);
 if ((strlen(newstring) + idlen + 1) < SYSLOG_BUFSIZE)
 {
...
  if (buf == buf0)
   buf = NULL;     <- Memory leak
  errno = save_errno;
  return;
 }

The part they conveniently left out is that buf0 is a local variable. 
If buf == buf0 then you don't need to free it --- freeing it would, 
in fact, be a bug.  This should be obvious to anyone looking at the 
code.

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

It is theoretical because the routines in question (rewrite() and 
rscheck()) are part of the rewriting engine, which always takes a 
fixed size buffer as input.  There just isn't a way for the overflow 
to ever occur.  We fixed it because it was the right thing to do.

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

The "memory jumps" is part of the race condition, not a separate 
problem.  The integer overflow problem came to our attention shortly 
thereafter.

> They also patched many non-security related bugs, added checks and
> more informative error messages, etc.

In 8.13.6?  Are you suggesting that it is irresponsible of us to 
continue to develop code?  If you want just the security patch, apply 
the security patch, which we made available at the same time.

> Sendmail is, as we know, the most used daemon for SMTP in the
> world. This is an International Infrastructure vulnerability and
> should have been treated that way. It wasn't. It was handled not
> only poorly, but irresponsibly.
>
> Here's what ISS releasing the Race Condition vulnerability has to
> say: http://xforce.iss.net/xforce/alerts/id/216
> They say it's a remote code execution. They say it's a race
> condition. No real data available to speak of. I can't see how it's
> remotely exploitable, but well, no details, remember? From what we
> can see it seems like a DoS.

To be blunt, we don't understand much more about it than all of you 
do.  It is an extremely subtle problem that involves making an alarm 
signal occur in a very small section of code as the result of a 
multi-minute timeout.  The signal causes a longjmp that can leave a 
piece of code in an inconsistent state.  ISS explained it to us and 
told us that they had managed to craft an exploit in their lab, but 
frankly we don't see how it can be practical.  This literally 
requires nanosecond precision in the millisecond world of networking.

> Bottom line
> -----------
> What they did behind the smoke-screen is replace a lot of setjmp()
> and longjmp() functions (not very secure ones at that) with goto's
> (interesting choice).

There's a big difference between a synchronous goto in a single 
context versus an asynchronous longjmp() between contexts.

> They changed the logic of the code, replaced everything that
> calculated timeout. Anything that calculated something and returned
> a value now returns a boolean result, when previously they just
> returned void. They used to look at the content rather than success.

When we got rid of the longjmp() we had to propagate I/O errors the 
hard way --- as return values.  This involved adding a lot of 
checking.  Painful, but necessary.

> The int overflow is possibly exploitable, not very sure about the
> jumps. No idea why ISS says the Race Condition is, would love
> insight.

I've already commented on this.

> Public announcement
> -------------------
> FreeBSD were the only ones who released a public announcement of a
> patch and emailed it to bugtraq so far.

Talk to the vendors.  I've seen quite a few of their advisories come 
by.

> The patches
> -----------
> The FreeBSD patch much like the sendmail.org patch is very long,
> complicated and obscure. The release was made along with a ton of
> other patches for FreeBSD. Go figure what's in there.

FreeBSD updated to 8.13.6 rather than using 8.13.5+patches.  This is 
what we are recommending for everyone.

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

You mean the patch to 8.13.5?  Yes, it's large, because of the 
necessity of propagating the error return back.  And we DID release 
the whole program (that's 8.13.6), which is what we STRONGLY 
recommend everyone use.

> ...
> Commentary
> ----------
> One could say ISS and Sendmail did good, obscuring the information
> so that the vulnerability-to-exploit time will be longer. That
> proved wrong, useless and pointless. They failed.

You say that giving you the source code is "obscuring the 
information"?

> After looking at the available data for 30 minutes (more or less),
> we know exactly what the vulnerabilities are. Exploiting them may
> not be that trivial if indeed possible,  but there are most likely
> already exploits out there if it is. When will the first public POC
> be released? Your guess is as good as mine.
> Not to mention the silently patched memory leak.

See above.

> SMTP and Sendmail by extension are critical for the Internet as an
> International Infrastructure. If this ends up being exploitable (no
> details, remember?) both ISS and Sendmail should look good and hard
> at the coming massive exploitation of Sendmail servers.

Yes, that's true.  If it's exploitable and people don't update, then 
those people who choose to ignore the problem will be vulnerable. 
You could say that about every vulnerability that has ever existed.

> With issues relating to the Internet Infrastructure I'd be willing
> to go even with the evil of non-disclosure, as long as something
> gets done and then reported publically when it finally scaled down
> in a roll-back after a couple of years.
> If not, and you are going to make it public, make the effort and
> fix it as soon as you can, and give information to help the process
> of healing. Don't do it a mounth late and obscure data.
>
> It took Sendmail a mounth to fix this. A mounth.
>
> A mounth!

Are you suggesting that it would have been better for us to have 
released the problem without giving vendors any time at all to get it 
integrated?  I think that would be seriously irresponsible.

[remainder of rant deleted].

eric

Powered by blists - more mailing lists