Slashdot Mirror
Sendmail Hit by Data Interception Flaw
ricepudd writes "Computer Weekly reports that Internet security researchers have discovered a serious flaw in Sendmail. The flaw could allow remote attackers to take control of users' PCs. The Sendmail Consortium urged users to upgrade to version 8.13.6 of the software, which contains a fix to the problem. Computer Weekly seems to think that the fact that the Windows version isn't affected will help curtail the threat."
Ah, the WINDOWS version is NOT affected! How ironic!
As everyone who follows the Slackware changelog, new packages were available yesterday. It seems there is still no exploit for this flaw, and it's somehow hard to exploit. That's the impression I got from the changelog entry. I'll paste it here:
t ml- 2006-0058
n/sendmail-8.13.6-i486-1.tgz: Upgraded to sendmail-8.13.6.
This new version of sendmail contains a fix for a security problem
discovered by Mark Dowd of ISS X-Force. From sendmail's advisory:
Sendmail was notified by security researchers at ISS that, under some
specific timing conditions, this vulnerability may permit a specifically
crafted attack to take over the sendmail MTA process, allowing remote
attackers to execute commands and run arbitrary programs on the system
running the MTA, affecting email delivery, or tampering with other
programs and data on this system. Sendmail is not aware of any public
exploit code for this vulnerability. This connection-oriented
vulnerability does not occur in the normal course of sending and
receiving email. It is only triggered when specific conditions are
created through SMTP connection layer commands.
Sendmail's complete advisory may be found here:
http://www.sendmail.com/company/advisory/index.sh
The CVE entry for this issue may be found here:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
(* Security fix *)
All I hear from CERT is how insecure Sendmail is.
Next time, I'm using Postfix.
Can you tell us the file and line number that causes the problem and the mitigating circumstances under which it occurs. Jesus, it is open source ya know.
How we know is more important than what we know.
http://www.frsirt.com/english/advisories/2006/104
They say that the Sendmail Consortium says that some 70% of the world's email uses their services, but the fact that Windows isn't affected by the flaw will help curtail the effect?
Who the hell thought that was even a smart thing to say? I mean, that's like saying that because Mac OSX and Linux aren't affected by the Sasser virus that this will curtail the effects of any worm.
WHAT CRACK ARE YOU SMOKING AND WHY AREN'T YOU SHARING?!
I am unamerican, and proud of it!
The difference between "Serious" and "Highly Critical"...
(Yes, tongue is firmly in cheek here...)
Why would this qualify as serious if there isn't even a known way to exploit it yet? Or was there one in there I missed?
I'm a fiscal conservative, it's a pity we don't have a political party anymore
So the FBI was wiser than we thought in withholding e-mail accounts...
An email I received from the FreeBSD security mailing list seems to imply to me that this might be more of a concern for multi user systems.
- security
From: Claus Assmann <freebsd+security@esmtp.org>
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:13.sendmail
Date: Thu, 23 Mar 2006 10:31:20 -0800
On Thu, Mar 23, 2006, Bigby Findrake wrote:
> Does an attacker need network access to the machine, or does the attacker
Yes.
> merely need to be able to get an SMTP message to the machine?
He needs to control the timeouts (AFAICT).
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
Work bio at MMWD
OOOLLLDDD NEWS!!
That the Windows version is or isn't vulnerable doesn't enter into it. I doubt that 1 in 10000 windows boxes would run an email server. (Okay somebody do the sales of Exchange divided by total Windows boxes and show me to be wrong. ;-)
.. paranoid crackpot leftover from the days of Amiga.
Yay! I've been meaning to upgrade my mail server anyway... I'll just do it with more urgency now.
Further info of this security advisory available on CVE-2006-0058 and from Security Focus
Just don't create a file called -rf.
Yes, I realize this is too late for those of you running Sendmail now, and please don't take this as criticism for using it.... it's a solid mail program. But it was written when the Net was a much nicer place, and it's proving, once again, that retrofitting security is either very difficult or impossible. For a long time, it seemed like practically every third exploit was for Sendmail... it got pretty frustrating.
The two major alternatives are Qmail and Postfix; Courier is sort of an up-and-comer, but they've had quite a number of security holes in those packages. (of course, that may also be related to the fact that Courier does a lot more than just deliver mail.) Of the three, I prefer Postfix. It's exceedingly solid, very fast, and fairly easy to configure. The initial learning curve is a little steep (mostly because there's about a billion things you can set), but the config files are readable when you're done. You don't have to relearn the whole program every six months. It's also very secure... I'm only aware of two security problems in its entire history. (I don't remember the details, but I think one was minor, and the other was moderately serious.)
QMail is also solid, fast, and secure. But the author has decided that Unix machines should be configured a particular way, with files in particular places, and he uses his code as a weapon to try to force you to do things the way he wants. So I won't run it unless I have to. I don't deny that he's a brilliant coder and forty-eight times smarter than I am, but I refuse to be dictated to.
Postfix can take a beating.. it is Truly Great Software. It will handle any load that Sendmail will handle, it's easier to administer, and the security is better. And, of course, it's truly free... Wietse won't try to make your administration decisions for you.
Actually, QMail is the one designed with security in mind. As far as I'm aware it's never had any vulnerabilities. See security guarantee.
people use sendmail on windows?
There are also multiple ways of configuring sendmail when compiling it, which tells me that whilst an upgrade may be important, it may be much more important for some users than others.
Also, saying it doesn't affect Windows is unclear. Does it not affect Windows when you use some official
The report, as described, is about as useful as saying "we think we know a way by which under certain circumstances that we know, another may think they know a way by which you might have an increased chance of being struck by an asteroid". If you don't know what the way is, or what those circumstances might be, the information has little value. Sure, it has some in that they provide a bugfixed release, but we don't know how long the bug has existed and therefore have absolutely bugger all way of quantifying what the risk is that a server has already been compromised. It only prevents uncompromised servers from being attacked by this method in future.
Just because the press release is dated XYZ does not mean that every Black Hat under the sun hasn't got a CD-ROM filled with exploits for it and a list of backdoors on cracked sites from three years back. XYZ is merely the date the rest of us know about it. You don't maintain a secure system by assuming all crackers only know the exploits you've fixed. You maintain a secure system by assuming at least one cracker has the means to discover the exploits you've neither heard of nor have patches for - ie: by assuming you're running buggy software and taking the necessary steps to limit what those bugs can do.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
A little heavy on the linebreaks son?
and millions of exim users too :) and tens of milions of postfix users...
Denying the existence of security holes (qmail's preferred way of "fixing" them) doesn't make them stop existing.
Coincidence? I think not...
Shared codebase? Hmm?
Blearf. Blearf, I say.
Or you could just use the system-switch-mail command and move over to postfix.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Wait a minute, does this mean that there is software other than Microsoft's that has security issues? I'm flabbergasted.
The following statement is true
The preceding statement is false
I didn't say I was gloating (I haven't ever installed an MTA!), but 1 bug that can be easily worked around (instead of requiring a patch) which 99% of the users won't even come across, in 9 years is awfully impressive.
Did you ever notice that *nix doesn't even cover Linux?
Yeah I'd say that in 1981 the net was a different place.
A few clarifications:
Sendmail is BSD licensed, thats pretty 'free'.
and
IIRC this is the first major security advisory since ~1997, give it a rest, one "serious" bug a decade isn't exactly every other week.
I ignored posts like this for years, figuring it was like the Linux vs. BSD debates -- just a bunch of zealots. I was wrong.
/. peer pressure and switched to Postfix. It's just like Sendmail, only it doesn't suck. I didn't know Sendmail sucked until I used Postfix. It's easy, it's secure, and my servers haven't once been 0wn3d because of the ubiquitous MTA flaws of Sendmail.
Years after I mastered mc files and learned the magic of m4, back around 2002, I succumbed to
Some day I'll try Qmail. Baby steps.
-Waldo Jaquith
Damn this got modded down right fast. And right above a "CHECK OUT OTHER MTAS DUMMY" comment that got modded up to 3...
Courier is a Great idea. One mail application. Not an MTA and seperate MDAs. Just one. Unfortunately, trying to figure out how to set up just SMTP+POP3 for a single machine with multiple aliases and a few virtual users seems to require knowing how to configure everything
(If I'm wrong, and there actually is a guide telling how to do this, someone please post a note, I'd like to finally migrate to the new server we got 1.5y ago.)
Wow, I thought only Microsoft wrote imperfect code! It's going to take me a while to get over this.... /.
Hopefully this means there will be a reduction in pointless Microsoft bashing on
I mean, really. People have been struggling with Sendmail exploits since the 1980s. Dump the turkey. And pull it from every Linux distro. It's time to kill this thing off.
https://rhn.redhat.com/rhn/errata/details/Details. do?eid=3971 (rhn login required)
I worked on a research project for my proffesor that had to do with sendmail so I am pretty familiar with the data structures and how sendmail works. I don't understand how sendmail's timeout (control.c implementation) works.
If the problem is in sm_syslog() (in the conf.c file) and it has to do with a static variable I would link it to static char *buf = NULL;
Later in the function buf gets set to char buf0[MAXLINE];
I don't know why but that's the first thing tha popped into my head. The damn sendmail code it too much and hard to follow. Plus I don't have much experience with "write(ing) data to invalid parts of the stack (or heap in some scenarios)".
Using sendmail is anomalous to asking for trouble.
This sentence alone shows what an idiot you are. Go look up anomalous and then come back.
Back? Okay, good. Let's move on.
We still use sendmail because it meets our needs and because to those of us who actually know how to use it, it is less of a pain in the ass than your "better" alternatives. Sendmail had a whole slew of security problems many years ago before alternatives were even available, but in recent years, it has really not notably more security issues than any of the other options.
Face the facts here. Qmail and Postfix certainly have their uses, and are both excellent MTAs, but neither is "way better" than Sendmail for all installations. We each have our own requirements, and Sendmail meets those requirements for a lot of my installations.
postfix and qmail have been around for 1/10th the time of sendmail?
I guess if '10' is binary you're close.
If you mean ten decimal... you're way off.
Oh only almost every major corporation in the whole world.
Go back to your mom's basement.
look at the source code of sendmail: big tangled ball(s) of twine. Then look at the source code of some competing systems, strange, they're actually well-designed and modular! then look at the memory consumption of a sendmail process, vs. what qmail or postfix takes (20% of a sendmail process). I used to use sendmail in the 90's, but I'm glad I've long ago given up that bloated, hard to configure crap.
We've been playing with this bug for a few hours now. We can independently confirm it is exploitable. We will be releasing details about it to the Daily Dave list later tonight.
This is a funny one to exploit though. It'll take up to two hours to pull off on a stock install. Who ever releases the PoC exploit should include a game of Tetris in the exploit for the poor pen-tester to play while waiting =)
Cheers,
Robert E. Lee
Dyad Security
I hope you're not running red hat 9. I'm still running it on one system just because it's a production server for about 600 users. Had to recompile gcc from 3.2.2 to 3.2.3 (not a quick process on a dual xeon 700) to get to sendmail 8.13.6 (from fedora 4 mind you) to build at all. -fpie was the culprit. was running sendmail 8.13.1 purely for greetpause.
I used to be a Qmail fan. I had a couple of Qmail+Patches mailservers that stayed up and fairly secure for years. For the past few years though, it's Postfix all the way for me.
/services cruft! Xinetd? Nahh fuck it, I'll write "ucspi-tcp" instead and force that down everyone's throat. Configuration files in /etc? Nahh, we'll create some wierd-ass Bernstien World hierarchy for that too.
You need to apply about 50 patches to get a decent Qmail MTA, at which time all the security guarantees vanish. This is a problem because Dan seems unwilling to apply the patches that make Qmail a usable MTA. Big concurrency patch anyone?
wtf is it with Dan Bernstien's World?
He couldn't use standard SysV init scripts to start Qmail, no... we need the "supervise" and
Dr B's software is mostly useful in theory, not in practise.
Just use Postfix or Exim: you'll save yourself a lot of pain. It doesn't treat your Unix box like it's just a mere application launcher.
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
Results 1 - 10 of about 119,000 for yo mama exploit. (0.23 seconds)
Does that mean she's twice as secure as the leading mail transport agents?
It is obvious the author left out the word 'knows'. If you couldn't tell this, you are a bit slow in the head. If you could, you are an asinine prick. Your choice.
They're there affecting their effect.
http://www.jcb-sc.com/qmail/guninski.html0 _ tut.pl?tutorial_name=Qmail_vulnerabilities.html&fa ct_color=doc&tag=
http://secunia.com/advisories/10649/
http://secunia.com/advisories/15533/
http://www.frsirt.com/english/advisories/2005/049
http://www.frsirt.com/english/product/3207
http://www.saintcorporation.com/cgi-bin/demo_full
http://www.securityfocus.com/columnists/331/1
... that there's a bug in Sendmail?! Who would have thunk of such a thing?!?! Ok, ok, sarcasm aside, as much as people say that Sendmail is a configuration nightmare and a clunky and huge application, it is a very powerful tool and is quite mature, as things go. If only there were a configuration tool that allowed its full power (or close to it) to be used without causing too many headaches, Sendmail would kick every other MTA's butt.
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. I
Oddly, this is the first security fix I can remember for Sendmail in about two years. Just to check my memory, I looked at Secunia's report and they only list 5 vulnerabilities since January 2003.
2 in March 2003
1 in August 2003
1 in September 2003
1 in March 2006
2.5 years between vulnerabilities? Not too shabby, IMHO.
There is, however, one unpatched vulnerability, though the worst it can do is hide details from the log.
Regarding your sig -
shouldn't that be 'watashi wa nihongo ga wakaranai'?
IIRC, you 'nihongo o hanasu' or 'nihongo de hanasu',
but you 'nihongo ga wakaru'
The flaw could allow remote attackers to take control of users' PCs.
Um, unless they mean take control of end user's PCs, what about the sendmail servers that are sending and receiving the email?
I have to wonder how far Slashdot is going with the whole "linux is da bomb for the desktop!" ccrowd.
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
An attacker needs interactive access to the port sendmail is listening on. I'm not sure what your definition of "multi-user system" is trying to imply. If you were running a desktop distro that had sendmail available to the network, an attacker could exploit it.
Robert E. Lee
Dyad Security
The average desktop does not run sendmail or anything other than simple mail clients that use their ISP's SMTP sever. Their ISP won't let them. There's a good chance that server will be running sendmail, so users of nicer distributions are thwarted twice by "security measures", but that's all a different issue. Yes, Exim under Debian was easy to set up and worked great for desktop users.
In any case, Linux desktop users are still far better off than Windoze users. Kmail, Evolution and Thunderbird are all much better packages than Outlook and other Windoze only mail clients. Even when a dozer bothers to look outside their start menu and gets Thunderbird or some other nice mail program Bill Gates wants to break, the dozer has only plugged one of hundreds of holes. Windoze has a half life of 12 minutes on any network, sooner or later the user suffers. When they do, they have to pull out their "original" software and then get hosed before they can finish downloading the patches. A free software user who's suffered some kind of failure will download a brand new CD image or do a net install and have the latest and greatest every time. Free software quality and diversity will prevent the kind of universal exploits of the Windoze world, regardless of "market share".
Friends don't help friends install M$ junk.
...it uses SMTP-over-ultrasonics! And the admins are vampires. And it flies best after dark.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
People use Windows?
I must admit, it's sad to see that Dan hasn't patched the qmail-smtpd portability problem. I don't think you can call it anything but a bug.
If it's a vulnerability, it's a *very* unlikely one, for the simple reason that almost no configuration on earth gives a single qmail-smtpd 2GB+ of memory.
If I were Bernstein, I'd have given the $500 away and renewed the guarantee. I'd have said that the bug was tremendously unlikely to ever work, and impossible for it to work if you followed good practices in your installation. I'd have stated that the $500 was given away simply because it was a gray area.
But hey, I'm not Dan. What I am is a proud qmail user. It's still beyond a doubt the most secure MTA on the planet.
A lot of people rave about Postfix, but I'll never forget just how 'secure' that mailer originally was. The reason this qmail stuff is getting much attention at all is precisely because of qmail's great fame for its security. If someone found a 64 bit portability problem in Windows (hell, there are probably a zillion), you'd never hear about it. Just the way the cookie crumbles I guess.
You need to apply about 50 patches to get a decent Qmail MTA, at which time all the security guarantees vanish.
/services cruft! Xinetd? Nahh fuck it, I'll write "ucspi-tcp" instead and force that down everyone's throat.
/service is just an easy way to run things ... link a folder under there and have a ./run file in it and you're good.
You need to apply one: netqmail. Or qmail-ldap,which I prefer.
He couldn't use standard SysV init scripts to start Qmail, no... we need the "supervise" and
His software came out before xinetd. And even so, that implementation isn't standard across distros. Plus
ucspi-tcp is good too because it has easy mechanisms for black/whitelisting people.
I was going to ask why you waste your time like that... and I realized that I'm two times dumber by replying. Whatever.
Jack from Dyad Security just posted this link:n dmail.html
;]
h ingy.tar.gz
http://www.rapturesecurity.org/jack/exploiting_se
Quoted:
written in a rush, pardon the mess
not that ive gotten that far but here is my (confirmed by mark, thanks) attack....
step 1)
connect to sendmail server say something like
helo me\r\n
mail from: myemail@hotmail.com
rcpt to: root
data
step 2)
wait for server to say go ahead
send about 32767 characters inside a header
note what time it is
step 3)
wait until you get:
451 4.4.1 timeout waiting for input during message collect
step 4)
note what time it was when that message happened
step 5)
youll be dropped back into smtp command mode, now there is a static pointer inside sm_syslog thats your attack vector, youll need to recreate the collect timeout and race into sm_syslog
resend the helo crap
step 6)
wait for server to say go ahead
send about 32767 characters inside a header
and wait the time delta from the earlier 2 measurements
step7)
send more header data (so that its now greater than 32768 bytes)
hopefully sendmail will now race and crash inside sm_syslog because:
a) we just sent sendmail into sm_syslog due to the fact that we sent > the max amount of header data
b) we have a timeout (SIGALARM, longjmp thingy) that should be pending about the same exact time that
we entered sm_syslog
Also posted is a PoC to test if you are vulnerable. This needs a lot more work, and is not an exploit, but is a start:
http://rapturesecurity.org/jack/sendmail_tester_t
Sendmail 8.13.6 for RedHat 9, Fedora Core 1 through 5, and RHEL 3 and 4 (and CentOS) is available here:
http://www.city-fan.org/ftp/contrib/mail/
Phil
Not by force or design
/etc/rc.local
/var/qmail/rc ]; then
/etc/inted.conf
/var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd
#
if [ -x
csh -cf '/var/qmail/rc &'
fi
#
smtp stream tcp nowait qmaild
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
How hard can it be to move mail from A to B? Speaking as someone who's never written a mail server, I didn't think it was complicated enough to have so many security holes... (Serious explanations of what it does to warrant the complexity would be appreciated~)
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Generally they use their own built-in SMTP server to do it, rather than use the host's server.
Sendmail use YOU!
You're just upset because you spent a great deal of time learning its configuration by heart only to find out there are now better programs. That has nothing to do with the fact that Sendmail actually does suck compared to other MTAs. If that hurts your feelings, tough break... *shrug*
READY.
PRINT ""+-0
Security flaws in sendmail dæmon, when did that become news? :p :D
Who uses sendmail anymore hehe... qmail/postfix/exim/etc etc, all sendmail compatible.
Don't be square slashdot, get with the flow biatch!
A security hole? In Sendmail? Now you're just talking crazy talk.
Read my blog.
According to the Sun security advisory related to this (thanks SANS Internet Storm Center), Solaris 8 isn't vulnerable, although it comes with Sendmail 8.11.x or 8.12.x (depending on your patch frequency)--versions in the vulnerable range.
I've been a Solaris admin for a long time and I find this to be a rather bizarre inconsistency. Why would Sun claim non-vulnerability when mere cursory examination of installed release shows vulnerability?
Any /.ers with more insight into Sun's reasoning out here? If so, can you share it?
Welcome to the Panopticon. Used to be a prison, now it's your home.
Actually it's the Microsoft Exchange Server that does alle the security.
It's got an 80% downtime and keeps lagging out, so if you check back in a few years when the mail gets through we'll maybe have a problem. But then we'll be like all Windows Vista n shit, and sendmail will be all transparent, so you can see where the error is.
The real question is whether they'll remove sendmail from Duke Nukem Forever because of this?
Defining Statistics and Social Research
The upgrade script erases your sendmail.cf! Make sure you do a "chattr +i /etc/mail/sendmail.cf" before doing the "apt-get dist-upgrade" to protect yourself. You'll see an error message when Debian tries to destroy your sendmail.cf, but you can safely just ignore it.
+5 Informative
the hardest part of the process was making sure that I'd be awake at 8:00 AM (PST).
:)
Try man at.
Face the facts here. Qmail and Postfix certainly have their uses, and are both excellent MTAs, but neither is "way better" than Sendmail for all installations. We each have our own requirements, and Sendmail meets those requirements for a lot of my installations.
No, what you mean to say, is neither is a complete replacement for Sendmail. And that's true- Sendmail does things that Qmail and Postfix don't do.
Unfortunately, that's [also] part of the problem. Sendmail is so much more complicated, that it's harder to audit- and being a single giant ball unnavigatable feces, you should never reprimand anyone for trying to get away from it- nay, you should be attempting to get away from it yourself!
The trick is to see if your messaging infrastructure can be expressed in terms of Qmail and Postfix. If it can (and it usually can) then you'll be much happier because your infrastructure will be much simpler and easier to audit.
It'll also show you exactly what needs to change- for me, it was stronger controls over delivery scheduling. But because Qmail is modular, I could simply change that part and wasn't tied otherwise to the crap that is Sendmail.
When you take time to update Sendmail, also consider adding some hard coded relay blacklist entries. This is an access-based RBL that hangs up on known broadband DUL space containing zombies. A nice addition to a well tweaked Sendmail setup.
I couldn't have expressed it better myself. When all the hooplah about Qmail surfaced many years ago, I jumped on the bandwagon. It was fast, but the software is, in a word, arrogant as hell. It expects to be set up a specific way, which is not a prerequisite for the max efficiency, security or compatibility it purpports to claim.
I seem to recall reading the manual where it said something like, "If you don't understand how to set this program up, use another MTA."
http://www.kb.cert.org/vuls/id/834865
http://www.kb.cert.org/vuls/id/MIMG-6MPUH2
Solaris 8 will be patched to update sendmail to version 8.13.6+Sun following the 8.11.7p2+Sun patches.
...only old people use sendmail
The advantage of the MAC system was that it created virtual systems per user per program (as the effective MAC had to be the intersection of the two sets of rights, as MAC prohibits someone from inheriting a right they wouldn't otherwise have) but requires very little overhead, as it's all managed in a single instance of the OS. There's no overhead from virtualization.
MAC has two drawbacks - to be thorough (and fast), you do need specialized hardware. It's also non-trivial to write thoroughly. SELinux, for example, is only a tiny subset of what would be needed even to reach the old B1 standard. As far as I know, there are NO patches or combinations thereof for Linux that meet that criteria, and I'm absolutely certain we're not going to see a B3-compliant Linux any time soon (that's when the standards get really strict).
Virtualization takes some of the load off MAC, but unless you're prepared to run a few hundred virtual machines, won't be able to sandbox on anything like the scale you'd want to get decent security. It does limit the need for some of the specialized hardware, though, which will make things easier.
The "ideal" is to get as close to EAL7 (Orange Book A1) standard, where there is mathematical evidence that the software is fully sandboxed, as possible. However, that isn't easy and would take a lot of VERY skilled mathematicians a LONG time to do well.
To get it perfect, you'd need to generate the complete OS formal specification, then rewrite Linux completely from scratch from that specification. It's doable, but I'm estimating you'd need 100,000+ mathematicians and another 10,000 coders to be able to re-engineer and re-code the kernel fast enough for it to still be relevent. When you add in thigns like GCC, Glibc, X11, KDE/Gnome, and all the other major pieces of software, you might easily be looking at a quarter of a million individuals needed - about 25 billion dollars a year.
The US Government could afford that, but I seriously doubt it could get hold of that much manpower. Not without crippling every industrialized country in the northern hemisphere in the process.
As perfection is not practical, then we should look at how close we can get there before it goes beyond the resources that exist. Virtualization will be a major part of that, MAC will be another, source validation (by as many means as possible) will be yet another.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)