Slashdot Mirror
Security-Fix Sendmail 8.12.9 Released
bahamutirc writes "Yet another security problem was discovered by Michal Zalewski in Sendmail 8.12.8, 'a buffer overflow in address parsing due to
a char to int conversion problem which is potentially
remotely exploitable.' Apparently somebody jumped the gun and posted before Sendmail had a chance to notify anyone, so they had to release it today. Go grab your source." Here's the CERT advisory.
long int foo = 87;
//???
long int foobar = 2;
long int foofoobar = 0;
foofoobar = (long int)foo / foobar;
Saskboy's blog is good. 9 out of 10 dentists agree.
I'm glad they kept this SM exploit fairly quiet. You would have thought it would become public and cause lots of mischief, but now that there is a fix, I suspect they will release what the problem was in more detail.
If this was a Microsoft problem and they kept it quiet you would have been ranting and raving right now, right?
I switched to postfix last time! MWAHAHAHAHA!
Sendmail: The IIS of Open Source.
This is the straw that breaks the camel's back. I'm changing to another MTA.
NO CARRIER
"Providing hackers with security holes for DECADES" --jeff++
ipv6 is my vpn
I fought with the M4 format of sendmail.cfg for a while in setting up a complex system before switching to qmail. Ive tried postfix too, but I still see diehard sendmailers around.
For one, sendmail is really not intuitive. If youre given a server youve never seen before and have to alter some fancy configs in it, could you do it faster than if it were say qmail? Maybe if I stare at M4 pinfo I could begin to get it, I gave up early there.
Secondly these security problems.
So beside the fact that sendmail is the standard, quite mature and very flexible if you know how to config it, does it have any big edge over postfix or qmail that everyone should know about?
And can the sendmail developers be brave trailblazers and finally change the config file syntax to just text words like httpd.conf?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Developers recently have been getting fed up with security "advisories", that include an exploit, being posted on most "security" websites before they have even been notified. Unfortunatly this leads to many script kiddies getting their kicks from "owning" a popular site before they have been patched, and probably many of the websites that exist exist purly for this purpose. Sendmail are just the latest people to fall victim from this.
See, they give you much needed practice of patching services at a proper pace! Patching it every 2 weeks or so is great practice for every administrator. Every good admin should have at least 1 box with sendmail on it. See, a few years ago I put on qmail. Now my patch skills are severely lacking. When this advisory for sendmail came out today, I said "that's enough, I'm falling behind. I'm going back to sendmail." I think I'll be much more happier now.
Thank you,
--The rest of the fucking Internet
--sdem
Why? For the love of SMTP, why??? j/k
-Kevin
But that still doesn't make sendmail bad. Software has bugs. Your precious MTAs have bugs too. As a matter of fact, sendmail works. It has worked for decades. It's still around. And it will stay around for decades more.
Before y'all jump up and say: "Look! a possibly remote exploit!". Read the advisory. This will be VERY hard to exploit, besides your test lab where you control the address space and eventual host naming that just MIGHT overflow something, and then you need to figure out if it's even possible to do something more fun other than let some sendmail spawned child crash, whoopdeedoo.
Although it's not impossible to do, I still maintain that admins should patch their systems, but you don't have to rush. I don't see script kiddies exploting this one in the coming time yet. And besides, my data isn't worth crap either, so I'm harly a target.
So qmail and postfix zealots, shut the hell up please. We know. Yes, qmail and postfix are nice, and yes, they have some merits over sendmail and yes, I sometimes choose to prefer them for some jobs, but the inverse is also true. Right tool for the job and all that. Now be happy with your MTA and be done with it. Geez, it's only a mail server.
You need a password to get root access through telnet!
*ducks barrage of rotten fruit*
But seriously, and without the bad humor, it makes me wonder why everyone allways sees X as the bloated, non-scensical, anacronistic piece of junk that is holding LINUX/BSD back. Hell at least I can understand a XF86Conf-4 file (although the old style XF86Conf file is still rather infuriating).
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
I can't understand why any general-purpose distros still ship sendmail. Qmail is good too, though I prefer postfix.
Sendmail takes (on my system) a thousand-line config file just to have sane settings for the modern world. It has a horrendous security history.
Postfix has non-dumb defaults, is quite secure, and I cannot see why anyone wouldn't use it.
May we never see th
Is your sendmail buggy? Would it be time to change to Postfix?
Only $0,00.
This one bug doesn't make sendmail bad. The fact that it's had scores of bugs does.
It's "only" a mail server, but what about a company whose email contains very sensitive information? They may feel safe using, say, smtps and imaps, but if sendmail isn't secure, they're sunk. In addition, getting on a mail server may allow access to a local network filled with insecure windows boxes. Oops.
You seem to be way too attached to sendmail. There are better alternatives available, so why not use them? I broke off from sendmail years ago, happily.
You should not create such an attachment to software; I use OpenSSH currently because it's free and works. I won't pretend it's not bug-ridden, though, and if something better comes along, I will switch because I care about security. I don't care if I've been using OpenSSH for years.
After researching sendmail, postfix, and qmail, I settled on qmail for it's speed and security. I can't count the number of times I had to upgrade sendmail in the past. I have never heard of a single remote exploit affecting qmail.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
It does not.
This is new.
55 flaws in the code, 55 flaws in the code....
Take one down debug it around 58 flaws in the code...
http://saveie6.com/
This is just a really quick overview because there are a few things I would have to lookup again for postfix, and don't quite have time to write a fully detailed essay(good for postfix 1.11).
Main Configuration/Documenation
Most of the configuration is done with /etc/postfix/main.cf and /etc/postfix/master.cf. The first sets configuration variables,
and the second one sets up the various daemons which are used for queuing, delivering, sorting, and sending mail. The primary
documentation are the man pages that come with it, and /usr/<documentation directory>/postfix. Also see www.postfix.org for
FAQ's, HOWTO's and mailing lists.
Tables
Postfix supports a wide variety of Table types. sendmail uses "hash" I think.. But you can also have tables based around mysql or ldap, for example. I use LDAP almost exclusively. So my knowledge is very much specialized about that behemoth. Anyway, when I say specify a table this is done in the form
The Type is the type of table/format being used. The Location is simply one of several things
For backwards compatibility, hash:/etc/alias is normally setup as an alias database.
Virtual Stuff
Also note the following distinctions that I used, I hope this doesn't confuse anyone reading the other documentation.
Fallback Address or "Catchalls"
Catch-alls operate like in sendmail, add an entry to a virtual user table in the variable virtual_maps with the "key" @domain.com. However, since virtual mailboxes are done after virtual_maps they aren't very compatible with catchalls.
Configurable bounce errors
I'm not sure this there is a way to completely customize the return error, but adding an entry domain.com (not @domain.com) the actual data doesn't matter, just the entry is importent,so set it to "unknown" for readability. This creates a postfix-style virtual domain which should reject unknown users with the appropiate error. see virtual(5).
Delivery to a piped process
Yes you can. You have to edit the /etc/postfix/master.cf in order to setup the service for delivery.
Here are some examples:
Backup mail spooling
In postfix there is a transports map that has three fields: domain(key), transport(servic
Sendmail gets a bad name sometimes from folks who gave up on it for various reasons (Too hard?). Sometimes some of these "administrators" can't tell the difference between a Message store and an MTA. /var/mail is not sendmail!
.com) and having an open relay was normal. Think ARPAnet.
/var/mail, etc...). Think scale and way beyond systems for only 10s of thousands or less.
I personally like the way the sendmail community handles these issues when they arise. 2 reports in a row is a bummer, but the frequency is exaggerated. I respect the fact that there are other open source MTAs and think they can be made to work well too (postfix, qmail, exim, etc...).
Please keep in mind that this MTA was around when the network was more of a community (not a lot of
Sendmail pioneered lots of the AntiSPAM/AntiSPAMMER features that are taken for granted today (advanced relay control, ip to dns a record verify, DNS blacklisting etc...).
There are reasons why many (think mega sized corporations around the world) use sendmail in front of their message store systems (Exchange, Notes, Cyrus,
It has/provides:
The ability to use LDAP information for routing.
The ability to use LDAP instead of a flat Alias file.
LDAP intelligence at the port 25 gateway (Think not have unreturnable bounce messages traveling all the way into the network and then getting stuck at your message store) A smart MTA at the gateway will break the connection and not waste time trying to pass the message through.
Pass based (w/crypt options) SMTP Authentication
Certificate base SMTP authentication
Unlimited relay control options (rule sets and milters)
Built in SMTP encryption (TLS/SSL) with support for PKI systems
Multiple queues and deterministic queuing (queue groups)
Fallback MX (this is huge for failover)
Mid-protocol conversation filtering (Milter, do all of your attachment stripping and message scanning without adding extra hops).
Capable of sending email just as fast as any other MTA without violating RFCs (do you really not want to commit your data to stable storage?) and putting your data at risk.
SMTP pipelining (why open a new connection each time?)
Active development with developers developing to the RFC/IETF's standards and the needs of today's internet.
Ability to be configured to avoid port 25 Denial of service attacks that other MTAs are vulnerable to.
My 2 pennies, just another opinion, now leaving verbose mode...
1) Qmail doesn't follow convention. Forget inetd, DJB uses his own, goofy "tcpserver". Never mind any other services you have on the machine, and pray to god they don't conflict. You *can* get qmail to work with xinet.d, but good luck getting all the (much needed) features working, since with xinet.d you get an open mail relay by default.
/etc/rc.d/init.d/sendmail restart takes care of most of it.
2) There are like 5 different programs, each with different user accounts (qmaild, qmaill, qmailp, qmialq, qmailr, qmails, vmail, etc) - all running from the same !@#!@ bin directory! Talk about confusing as !@#! hell when you want to audit permissions!
3) Qmail has a truly hideous license. Yeah, it's "open source", but you can't redistribute changes!!?!
This means:
4) If you want something decent (such as LDAP support,antivirus filtering or integration with SpamAssassin, etc.) you have to apply 57 god-knows patches to the "official" qmail source, and in just the right order to get everything working.
5) The log format is different than sendmail's. While this is understandable, it means that all these neat reporting tools for sendmail can't be used.
And finally,
6) Administering Sendmail on RH Linux is a breeze. up2date sendmail;
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Interesting how we just had this article the other day.
I know some places process alot of mail with sendmail and need all the speed they can get, but the monster sites seem to have gone to qmail anyway. Considering the speed of my computer vs. the speed of my 'net pipe, I don't have much of a load on my mailserver, which leads me to ask:
Does anybody know of a good mailserver written in a higher-level language?
This is what, the 82nd remote root-exploit in sendmail due to C coding problems? Let's see something written in Perl or Python or Java, even.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)