Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
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