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

[Eric Allman <eric+bugtraq () neophilic com>]

Theo,

> > 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.
>
> I know the guy who exploited it.  He's better than you think he is.

I'm sorry, I was not trying to imply in any way that Mark was blowing 
smoke.  I believe he can do it.  Take my statement literally: /we/ 
don't /see/ how it can be practical.  Perhaps I should have said 
"understand" instead of "see".  The point was that this is not a 
trivial problem to exploit.  But yes, I do believe it is real, and I 
think (hope) I made that clear in my message.

> On average it takes him 100 connects to a machine, and he wins the
> race.  Since the child process is a clone of the parent, he gets to
> try it over and over.
>
> That's the problem, everyone says the race can't be won.  If you
> don't win it, you try again.  Eventually you win the race.

And I totally understand that.

> If eventually was 1,000,000 attempts, ISS would not be paying him
> (since he gets paid extra for proven bugs).

If eventually were 1,000,000 attempts, it would still be real.

> Their process requires a working exploit before they will disclose.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I do think you made a serious mistake in writing an advisory based
> on the standard boiler plate that many vendors use to make it
> appear as if the bug is less serious.  You avoided saying "This is
> a remote root" hole.  Because it is!  ISS told you quite clearly, I
> am sure. But instead, you went with the standard boiler plate which
> tries to muddle the situation.

First, it was not my (speaking for myself) intent to minimize the 
concern.  But at this point I certainly hope that everyone is running 
sendmail with the RunAsUser option set, at least on their gateways 
--- we've been urging that for years now, so people who are 
sufficiently security-focused should not have a remote /root/ exploit 
(although I also understand that getting into any uid on a system 
makes getting room much easier).  We did mention that in our 
comments, if I recall correctly (I'm on an airplane right now and 
don't seem to have the text with me).

I stick to my original position: this is a real problem, but it is 
very hard to exploit.  Even having been told all the details I don't 
think I could write it.  Does that mean that someone won't do so? 
No, I'm quite certain they will.  But the truth is that we know of no 
exploits in the wild right now, and we believe that it will be hard 
enough to craft that people shouldn't panic.  They should upgrade, 
and promptly.  If they aren't using RunAsUser, they should take this 
opportunity to do so.

> And THAT is why people are upset with you.  You should take that
> criticism to heart and next time not release a muddled boilerplate
> kind of muddle.  Be men.  Take a little bit of responsibility -- and
> people will slightly praise you but most definately not attack you
> as they are.

I'll have to take responsibility for not being more insistent on 
bluntness in our text.  I was not the one who wrote it, although I 
did get a chance to provide input.  And I'll certainly try to be more 
adamant about clarity and directness should this come up again.

But again, I have to say:

We did not attempt to hide this problem.

Much of the lack of clarity in our statement was because we didn't 
(and still don't) completely understand the details of the exploit 
ourselves (although we are satisfied, and ISS has confirmed, that we 
have eliminated the use of problematic alarm-based I/O timeouts that 
were the root of the problem).

We didn't try to slip in other changes without saying anything.

We feel that we responded promptly and appropriately, although it's 
also clear that we could definitely have done a better job of it. 
We/I always learn something, and try to do better next time.

Thanks for your comments.  Really.

eric