Buffer Overflow in Sendmail

ChiefArcher writes "On the footsteps of openssh, Sendmail 8.12.10 has just been released due to a buffer overflow in address parsing. Sendmail states this is potentially remotely exploitable. No updates on the Sendmail site yet, but the FTP site has the release notes."

Use qmail

[DigitalNinja7]

That's why you should be using qmail [cr.yp.to], ya' code monkeys! Seems like this happens every couple months.

OpenSSH as well

[ChiefArcher]

Openssh is also exploitable today. (AGAIN!)
They missed a few from yesterday.

http://www.flyingbuttmonkeys.com/ssh/ [flyingbuttmonkeys.com]
has a few RPMS (9/8/7.3) i just compiled to patch the problem.. (backported).. THe SRPM is also available for those unwilling to trust my patching efforts.

Or you can wait a few hours for official redhat releases.

It's on the site now

[Phaid]

The official announcement is here [sendmail.org].

I've already downloaded and installed it. Thank goodness for Slackbuild scripts :)

Re:Sendmail, huh?

[Anonymous Coward]

Christ, the mods must really have a hard-on for sendmail. Every post critical of it in this thread was instantly downmodded, regardless of the fact that they were TRUE. Sendmail DOES have a long history of serious security flaws, and both Postfix and Qmail (I prefer Qmail) are valid responses to this trend, as neither one of them have exhibited the same problems.

Lazy Story Submitter

[Peridriga]

Just point to the ftp site?
Aight... I'll fill in the blanks

ftp://ftp.sendmail.org/pub/sendmail/RELEASE_NOTE S

8.12.10/8.12.10 2003/09/24
SECURITY: Fix a buffer overflow in address parsing. Problem
detected by Michal Zalewski, patch from Todd C. Miller
of Courtesan Consulting.
Fix a potential buffer overflow in ruleset parsing. This problem
is not exploitable in the default sendmail configuration;
only if non-standard rulesets recipient (2), final (4), or
mailer-specific envelope recipients rulesets are used then
a problem may occur. Problem noted by Timo Sirainen.
Accept 0 (and 0/0) as valid input for set MaxMimeHeaderLength.
Problem noted by Thomas Schulz.
Add several checks to avoid (theoretical) buffer over/underflows.
Properly count message size when performing 7->8 or 8->7 bit MIME
conversions. Problem noted by Werner Wiethege.
Properly compute message priority based on size of entire message,
not just header. Problem noted by Axel Holscher.
Reset SevenBitInput to its configured value between SMTP
transactions for broken clients which do not properly
announce 8 bit data. Problem noted by Stefan Roehrich.
Set {addr_type} during queue runs when processing recipients.
Based on patch from Arne Jansen.
Better error handling in case of (very unlikely) queue-id conflicts.
Perform better error recovery for address parsing, e.g., when
encountering a comment that is too long. Problem noted by
Tanel Kokk, Union Bank of Estonia.
Add ':' to the allowed character list for bogus HELO/EHLO
checking. It is used for IPv6 domain literals. Patch from
Iwaizako Takahiro of FreeBit Co., Ltd.
Reset SASL connection context after a failed authentication attempt.
Based on patch from Rob Siemborski of CMU.
Check Berkeley DB compile time version against run time version
to make sure they match.
Do not attempt AAAA (IPv6) DNS lookups if IPv6 is not enabled
in the kernel.
When a milter adds recipients and one of them causes an error,
do not ignore the other recipients. Problem noted by
Bart Duchesne.
CONFIG: Use specified SMTP error code in mailertable entries which
lack a DSN, i.e., "error:### Text". Problem noted by
Craig Hunt.
CONFIG: Call Local_trust_auth with the correct argument. Patch
from Jerome Borsboom.
CONTRIB: Better handling of temporary filenames for doublebounce.pl
and expn.pl to avoid file overwrites, etc. Patches from
Richard A. Nelson of Debian and Paul Szabo.
MAIL.LOCAL: Fix obscure race condition that could lead to an
improper mailbox truncation if close() fails after the
mailbox is fsync()'ed and a new message is delivered
after the close() and before the truncate().
MAIL.LOCAL: If mail delivery fails, do not leave behind a
stale lockfile (which is ignored after the lock timeout).
Patch from Oleg Bulyzhin of Cronyx Plus LLC.
Portability:
Port for AIX 5.2. Thanks to Steve Hubert of University
of Washington for providing access to a computer
with AIX 5.2.
setreuid(2) works on OpenBSD 3.3. Patch from
Todd C. Miller of Courtesan Consulting.
Allow for custom definition of SMRSH_CMDDIR and SMRSH_PATH
on all operating systems. Patch from Robert Harker
of Harker Systems.
Use strerror(3) on Linux. If this causes a problem on
your Linux distribution, compile with
-DHASSTRERROR=0 and tell sendmail.org about it.
Added Files:
devtools/OS/AIX.5.2

Re:Patch delivery mechanism

[Moth7]

Does Linux have an Auto-update mechanism similar to windows that indicates when new patches are available for download?

No, it just has intelligent users and a trace level of OS level bugs :p

Re:Patch delivery mechanism

[OrenWolf]

There sure is!

RHN Update Agent [redhat.com]

Re:Patch delivery mechanism

[Jhon]

Depends on your distro. up2date for RH is a good example.

Re:OpenSSH as well

[(startx)]

and it's allready been updated [slackware.com] in slackware [slackware.com] as well. Go Pat!

Re:Sendmail's future

[bourne]

Is it perhaps time for a code rewrite in Sendmail...

IIRC 8.9 was the code rewrite.

maybe a quiet, dignified retirement?

At this point, I'd settle for a noisy drag-it-out-back-and-shoot-it.

Secure alternatives exist - Postfix [postfix.org], qmail [qmail.org]. Other alternatives with better security track records and lower target profiles exist - Exim [exim.org], Courier [sourceforge.net].

Time and past time to move. How many holes is it going to take?

Re:Patch delivery mechanism

[sg_oneill]

apt-get update
apt-get upgrade

Stick it in a cronjob.

Solved :)

Re:"Email Different"

[blchrist]

not all that secure http://www.securitytracker.com/alerts/2003/May/100 6728.html http://www.wired.com/news/business/0,1367,21490,00 .html

Who cares?

[Kevin DeGraaf]

Who cares? Sendmail is obsolete.

qmail [cr.yp.to]
postfix [postfix.org]
exim [exim.org]

This was mentioned on bugtraq

[Anonymous Coward]

Sendmail 8.12.9 prescan bug [securityfocus.com]

attack details:

Local exploitation on little endian Linux is confirmed to be trivial
via recipient.c and sendtolist(), with a pointer overwrite leading to a
neat case of free() on user-supplied data, i.e.:

eip = 0x40178ae2
edx = 0x41414141
esi = 0x61616161

SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242

0x40178ae2 : mov %esi,0xc(%edx)
0x40178ae5 : mov %edx,0x8(%esi)

Remote attack is believed to be possible.
It also seems that a CS student from the university of Sweden has posted a working exploit on this [ctrl-c.liu.se] web site. Scary stuff. So patch your system, people!

Re:How does an overflow work?

[Second_Derivative]

Stack grows downward, buffers on stack grow upward. Overflow a buffer and sooner or later you run into a return pointer on the buffer. Now, if you overflow it in such a way that the function corresponding to that stackgrame doesn't cause a segfault before it returns, the CPU will read in a return address you supplied, which could point to the buffer. CPU then executes the code you put in the buffer. I believe it's traditional to execve /bin/sh at this point.

Google for "Smashing the stack for fun and profit". I don't know too much of the specifics -- I'm not a script kiddie.

Re:*cough*

[Aadain2001]

That's the beauty of the Linux model. At its heart is a network OS and always has been. What the users don't know won't hurt them. Let the tech savvy admins push the updates out to the servers and the desktop computers. Unlike Windows, a Linux computer only needs to be rebooted if the kernel gets updated, so there will be no real preceived downtime for the users. I use Redhat's up2date service for the computers I have a home, it I can push updates out to them through a nice web interface from anywhere in the world. And the corporate version is supposed to be even better about handling large numbers of computers. The same day that the SSH patch came out, I had it waiting to be pushed out to my computers, all with a single click. This is something Windows really lacks, and they have admitted this on many occations.

Re:OpenSSH as well

[Anonymous Coward]

So don't download the latest patch from them, instead use a trusted source, like this [freebsd.org]. Check the latest commits by nectar.

Re:*cough*

[lubricated]

The original blaster patch "fixed" windows from blaster, but now ms released ms-03-039 because the original balaster patch introduced a new vulnerability. It went from being a buffer over run to a NULL variable. Still exploitable.

Re:Patch delivery mechanism

[Chupa]

You obviously have no first-hand experience with Debian systems. Security updates for the current stable branch are always released within a day or two of any sort of advisory (usually on the same day). The security patches are often backported to older versions rather than just using the newest version of the software. This makes life easy many admins, as new versions of software can be non-backwards compatible or behave differently than older versions.

And if you don't mind this, you can always use the "testing" or "unstable" branches for cutting-edge software.

Besides the fact that Debian is extremely easy to update:

apt-get update
apt-get upgrade

Know what you are talking about before you speak.

Re:Patch delivery mechanism

[metamatic]

Yes.

Debian: apt-get update
Gentoo: emerge sync
RedHat: up2date, or autorpm, or apt-get update
SuSE: you, or autorpm
Mandrake: urpmi update

You can get autorpm to e-mail you a daily summary too.

Re:How does an overflow work? [+LINK]

[danigiri]

I was in obscurity as well until I read this this story [slashdot.org].

It is a story about a detailed PDF on MacOSX/Darwin+PPC specific ways to run malignant code once and if an exploit is found. The posting is somewhat misleading, the PDF is not about vulnerabilities at all but what to do once they are found, as some reply clarifies.

I am pretty sure that similar docs exist for Linux+i386 and a-plenty of other architectures (MS Wind anyone?).

Dani++

Re:How does an overflow work?

[Waffle Iron]

During C procedure calls, the return addresses are placed on the stack in predictable locations. Often, people use fixed-size buffers allocated on the stack in their procedures. For example:

void foo() {
char buf[100];
gets(buf);
--- do stuff ---
}

By feeding in a string longer than 100 characters, you go up the stack and can overwrite the return address to the call to 'foo'. You might replace the address with a pointer to code you've embedded in the oversized string. When the call returns, it jumps into your code rather than the calling procedure.

Why sendmail anyway?

[ArchAngelQ]

Sendmail has remote exploits every couple of months at best. Why is anyone suprised any more? It's not as if it's easy to set up, administrate or is horribly high performance. It's about as middle of the road as you get. As many have pointed out before I'm sure, this is exactly why we complain about software from microsoft (and I mean just the software, not it's licences nor the biz tactics associated with it).

So why not look for alternatives, all you sysadmins out here? I for one prefer qmail [cr.yp.to]. There are plenty of others.

I know it's hard to switch to a new system when you've gotten profficent in configuring something well, especially when you are so busy using it that you don't have time to play with something new to see if can work for your setup. But I can't see that running a frequently exploited mail server will cause anything but more work.

This is getting silly

[jd]

Sendmail badly needs a severe audit. Maybe Stanford can run their validating compiler over it, or something. Either way, you shouldn't be seeing such basic, fundamental flaws in software that has been around for a long time.

Especially software that is semi-commercial. They're getting paid to check for these issues, after all.

Ok, credit given where credit is due. The problem has been recognised within a short time of being detected. That's better than Hotmail's "check the password? what for?" bug, that persisted for six or seven months, and remained in effect for several days after the media ran the story.

But that's where the credit ends. It shows that the program isn't being routinely tested and verified with overflow detectors, or (if it is), that the testing procedure is inadequate.

It shows why rival MTAs (eg: Postfix) are gaining popularity, when Sendmail could have kept absolute control of the market, merely by being the best.

Re:Use qmail

[Dysan2k]

Bah! And I'll say it again, Bah!

Use Postfix [postfix.org]! Ok, use either really, just stop using Sendmail. I run Qmail at work (due to legacy and converting Qmail's Maildir to Cyrus' Maildir just seems neigh impossible) and Postfix at home. Postfix is really straight-foward on setup and has TONS of documentation in the conf files.

Qmail, on the other hand has tons of docs on the site and lists a number of different ways to perform various tasks.

It's really a crap-shoot as to which you prefer. Just STOP USING SENDMAIL!

Re:Use qmail

[bongoras]

PLEASE PLEASE PLEASE read the fucking article...

from the release notes:

"Fix a potential buffer overflow in ruleset parsing. This problem
is not exploitable in the default sendmail configuration;
only if non-standard rulesets recipient (2), final (4), or
mailer-specific envelope recipients rulesets are used then
a problem may occur. "

http://www.sendmail.org/8.12.10.html

While I agree it's necessary to patch systems, this is hardly like the Blaster worm. I'm going to go way out on a limb here and say that 99.99% of all sendmail installations in the world don't use these rulesets. And anyone who IS using them is likely to be a sendmail weenie anyhow and they'll just take a break from writing their AI Chess program in sendmail.cf and patch it themselves.

Re:Sendmail's future

[Nevyn]

I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.

So are you saying it is designed with security in mind?

A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today.

So you saying (agreeing) it is designed without security in mind.

It's been years since the internet operated where everyone allowed relaying to help everyone else out. And go look at the code, they still use NIL terminated char *'s [and.org] all over the place. Mostly with limited length APIs like strlcpy(), but even a few strcpy()s.

Now go look at postfix or qmail, but have fully dynamic string APIs [and.org] and use them everywhere. And supprise supprise neither has had a buffer overflow.

Re:Patch delivery mechanism

[cayenne8]

"Does Linux have an Auto-update mechanism similar to windows that indicates when new patches are available for download? That would be a very useful feature. The number of patches on all OSes are getting ridiculous these days."

Well, a little explanation time here. Linux is the OS...the kernel. This patch is NOT for Linux. It is a patch for a problem in an independent application that you can run on Linux or other Unix type systems.

This is an important distinction from Windows, where most all the important apps that run on windows are also made by MS..and tightly integrated and dependent on each other. Since the OS and the app. comes from the same source, and the OS and app are often dependent on each other in code sharing...the concept of patching the OS/application is blurred in the MS case, whereas the OS and the application are independent from each other for the most part on a Linux OS based system. So, in general, there can be no ONE auto-update because each part usually comes from different sources.

Now, with that being said, many distributions, such as with RedHat, since they bundle a lot of the apps with the OS in their package...they do have 'auto update' functionality that will warn you to update if you choose to have this turned on in your system. I don't think most people want to AUTO update...especially on servers, but, it IS nice to have messages to tell you they are available and needed. That way, you can look into the problem and the options, and tell them to run.

Also, with one distro, Gentoo, they have all the apps and OS stuff in a downloadable tree structure called portage. Portage is used whenever you want to install an application generally...you do 'emerge (app name)', and off it goes to download the source, take care of lib dependencies...compiles and installs it.

Gentoo tries to keep the latest versions available for all apps...so, the neat thing is, you can do emerge -u world if you want, and it will update everything to the latest version (I prefer to update things as needed)...so, when a version is put out to foil an exploit..just update it..and your good to go.

HTH to make a little distinction with reference to the question...

cayenne8

Re:To all the Microsoft bashers out there....

[gtaluvit]

Um...they're called the following:

emerge (Gentoo)
up2date (Redhat)
apt-get (Debian)

I know on the Gentoo side, they had the SSH fix out the same day. There are distribution methods in place, just depends on the distro you use. So just cause Windows Update notifies you that there's an update or even does it automatically, that doesn't stop you from croning the above commands.

Re:difference between MS bugs and OS bugs

[realdpk]

But only because Microsoft is big on "no disclosure", instead of the superior "full disclosure" method of distributing security information. MS feels better being able to suppress bug announcements, indefinitely, until they think it's appropriate to issue a patch. Which is why I could never use an MS OS and expect security...

Exploit already known half a year ago?!

[Anonymous Coward]

There is a patch for the "prescan" bug in:

http://ftp.pg.gda.pl/pub/software/sendmail/

Isn't it the same as this bug? BUT LOOK AT THE DATE! It was written in march. Has this bug been known for half a year?

Re:Before the Microsoft defenders say it...

[TheNetAvenger]

But there is another kind of security problem for which Microsoft is deservedly bashed. The problem Microsoft is bashed for having poor security is when their system is insecure in its design. (It may not have been a design goal.)

Although you have good motives in this post, you have no idea what you are talking about in regard to Microsoft's OS architectural security and its history.

Sure Win9x and Win3.x and DOS are INHERENTLY insecure, as they were designed with a closed system architecture in mind and an evolution of a closed system OS. Just like Mac System software has almost no inherent underlying security. (i.e. they were not designed for security or rigid network security since many of the networking concepts that are common today were not available or widely used when they were originally designed in the 80s. As most home users concepts of networks were CompuServe and BBSes.)

However, the NT architecture and security model that it was designed upon had security as a main priority from its original designs. In fact the Object Oriented/Token based security model that is in the NT base (and the original NT 3.1) are not only conceptually more advanced than the *nix security model, but they also have been successfully implemented to be one of the most secure OS designs in history.

The designers of the NT security model took 'conceptual' ideas of the 'ideal' methodologies for a robust and strong underlying security structure and designed these into the OS from day one.

This is why people like Dave Cutler and other 'respected' Unix and OS engineers at the time that were hired by Microsoft ABANDONED the *nix security models to build an OS using the new theories of OS security and implement them in the NT kernel architecture.

As for backing my claims, I suggest an original text like "Inside Windows NT" - The original 1993 release and the recent updated releases that cover the newer NT code bases - Windows 2000, XP, and 2003.

The OS designers at Microsoft had full control to make NT based upon *nix concepts and technologies if that was what they thought was the most advanced conceptual OS engineering; however, they rejected taking the *nix route and instead went for OS architectural concepts that were on the forefront of technological theory and hadn't even been implemented in a real OS to the extent they were in NT.

As you can see from many of my posts here, I am not a hard core Microsoft or NT zealot, but when I see people just dismiss technologies because they take the popular misconceptions I feel the need to respond.

Even if you hate NT and Microsoft, I truly do hope you will explore what TRULY is in NT in terms of security and its security model for your own knowledge.

Especially considering any information you or someone else reading this post gain from it might be compelled to use some of the Microsoft NT concepts in other OS coding and designs to create richer OS environments for everyone, whether it be MacOSX, Linux, or BeOS.

Even if you take odds and dismiss the intellectuals that designed NT, there is always the chance the Microsoft team did do something innovative or right that can also benefit future OS architectural models.

Take Care,
TheNetAvenger

Re:Use qmail

[ChaosDiscord]

That's why you should be using

qmail [cr.yp.to], ya' code monkeys!

Great idea! I'll just download a package from my favorite distribution that's tuned qmail to mesh nicely with how my system is configured.

Hmm, they don't supply packages for qmail. Why not? They're not allowed to [cr.yp.to]. If I take the time to make up such a package, I'm not allowed to give it to my friend.

Quoth Bernstein:

But that's a decision for the Apache maintainers, not the UNIX integrators!

Darn those pesky integrators, attempting to make their system internally consistent and trying to please their users!

I've heard great things about qmail, it's great that is available with source for no cost. But it's proprietary software, putting me at the mercy of Bernstein. If you want someone else to maintain a fork with features you desire, you're out of luck. It's fine if you're willing to accept that, but it's not acceptable to everyone. Fortunately there are other [exim.org] options [postfix.org] available.

patch applies to old versions of sendmail

[named]

In case anyone is forced (by legacy apps & shit) to be running old versions of sendmail, the patch supplied applies nicely to version 8.9.x of sendmail. It even continues to work after it's patched.

Not like anyone is going to find this comment so late in the discussion, but...

qmail install HOWTO and RPMs

[getnuked]

Here is a HOWTO [linuxvds.com] and a tarball [linuxvds.com] containing all of the files necessary to replace sendmail with qmail on an RPM based system.

There are *TWO* bugs

[V. Mole]

Actuall, more than two: the changelog includes several fixes. Right above the fix you quote, there's one that *is* exploitable, which is why they've gone ahead and released it:

8.12.10/8.12.10 2003/09/24
SECURITY: Fix a buffer overflow in address parsing. Problem
detected by Michal Zalewski, patch from Todd C. Miller
of Courtesan Consulting.

The fact it's separate bugs is clear from the indention in the original (Fscking /. doesn't support PRE)

Re:Use qmail

[Pointer80]

I used perl with Mail::IMAPClient to convert from Maildir (Sendmail/Procmail w/modified qmail-pop3d) to Cyrus.

Here [mikecathey.com] is the most relevant part of the perl module I wrote to handle the migration.

Please not that there are several system dependent settings in this function. Our spool was hashed to depth two. I will probably end up rewriting this module to proxy for the user, authenticating as cyrus, which would be much cleaner.

We've been using Postfix/Cyrus in production for a while now and we're really happy with it.

/pointer

Re:Can you read?

[ComputerSlicer23]

Uhhh, check the MD5SUM off the original site (Downloading the MD5SUM off the original site, is less load, off the mirror if they have it)? Off the BugTraq list? Off any number of sites. You check the signature of the MD5SUM is from someone you *TRUST*, like the original author, like a security expert on a mailing list, like your distributor. Maybe possibly that's who you would check the signature from? If you go to the trouble of mirroring the original patch, you should grab the *signed* copy of the MD5SUM from the original author (Lots of authors sign their MD5SUM's, the tarballs and patches are all have a signature file on kernel.org for instance). That's how I check all of my ISO's I download, even when it is from the original site. RedHat publically lists them, I just grab the MD5SUM list from them, and I check the signature of the MD5SUM file.

You should do that no matter who you download it from, even from the original site, not that long ago the OpenBSD sites, and the GNU sites we're compromised. So just assuming they had good source, wasn't safe. Then at least you know that whoever wrote the patch, also has the private key of whoever signed it (which hopefully is the person whom you trust). If you are a good little author, you sign with a private key on a machine that you sneaker net the source code to, sign there, then sneaker net it back to the public network (or you just drag the MD5SUM there, instead of the original source). At no point, would you ever put the private key on a machine that has ever been connected to the internet (then you just have to physically secure the machine). It's much, much safer that way. Then nobody can get your key except by crytoanalysis, which needs the force of a major gov't behind it to break 4096 PGP encryption last time I checked.

Honest, I'm not as stupid as you think I am.

Kirby