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...)