Christopher, On Thursday July 24, 2003 02:06, Christopher Wong wrote: > On Thu, 24 Jul 2003, Jonathan Gardner wrote: > > Sendmail has a bad rap because many exploits were FOUND and fixed. How > > many pieces of software do you use day-to-day that have many exploits > > that are still in hiding, or worse, only in the hands of the black hats? > > So, does sendmail deserve its bad reputation? Or should it be called far > > more tested and secured than any of its competitors? > > That argument might hold if sendmail's exploits were found in the distant > past, but exploits continued to be fixed as early as this March. By > contrast, no known remote exploits have ever been found for its major > secure competitors (qmail, postfix). > > It looks like past performance and architectural criticisms have been > disqualified with respect to sendmail. I'd turn the question around: given > this we-got-the-last-bug-this-time-honest line of reasoning, is it ever > possible to conclude that sendmail is insecure? So your logic holds that if there are a lot of released security issues over a period of time, that the software is of less quality and diminished value regardless of how it performs it's normal functions? So then by this logic we should check to see how many reported security issues Sendmail has had and what other components are similar so we can all stop using them... For this example I think we should choose a well regarded and long released distribution so that we can have a large (reasonably) data set to work with. So I will use RH 7.3. It's release date was May 6, 2002. This gives us a little over a year's worth of data and since it is still supported by updates, can come all they way up to current (to match your recent exploit criteria). Sendmail Security Advisories : A) 2003-03-31 - vulnerability that allows local and possibly remote attackers to gain root privileges. B) 2003-03-12 - vulnerability that may allow remote attackers to gain root privileges by sending a carefully crafted message. Total : 2 serious issues. (but we know about it's ugly past) Apache Security Advisories : A) 2002-06-28 - vulnerability which can be used to launch a denial of service attack or, in some cases, allow remote code execution. (chunked encoding) B) 2002-11-25 - Three issues fixed in one release. A DoS, an XSS, and remote code execution. Total : 2 serious, 2 moderate issues. (this one has been shady over the years as well) Kernel Security Advisories : A) 2003-07-21 - There were actually 8 security issues with this release. Most minor (like info disclosure) and some moderate (like DoS). B) 2003-06-03 - 2 moderate issues here (DoS) C) 2003-06-02 - Local Root exploit. D) 2003-05-14 - Remote DoS, Local Privilege elevation. E) 2003-02-03 - Minor information leak F) 2002-11-16 - Local DoS G) 2002-08-20 - Bunch O' Stuff from a security audit(~6 issues, considered minor). Total : 2 serious, ~10 moderate, bunch of minor issues. (Don't even get me started on the 2.2 version.) OpenSSL A) 2002-07-29 - several serious buffer overflow vulnerabilities. B) 2002-08-05 - DoS C) 2003-03-06 - potential timing-based attack. D) 2003-04-01 - potential timing-based attack and a modified Bleichenbacher attack. Total : 3 serious, 3 moderate. (not as long a history, but not off to a good start) So please make sure to bash these other fine programs as well, or tell us about their better replacements. Going back further _would_ increase the number of exploits in Sendmail, but would also increase the numbers for all the others as well. Yet, for some reason I never hear "apache is a total piece of crap, don't use it, go get <insert web server here>". The fact is, that all of the open source and free MTAs are for the most part excellent pieces of software that can do the job. And, so long as Sendmail (and the others) continue to _fix_ the problems in a _timely_ manner, they should all still be considered. Pick what works (for you) and is well supported. Now if you want to argue on the basis of configuration... ;) You can now return to your regularly scheduled Emacs v. Vi or KDE v. Gnome flame war. -- Brian Ashe CTO Dee-Web Software Services, LLC. rhlist@xxxxxxxxxxx http://www.dee-web.com/ -- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
