sendmail 8.13.7 available
Claus Aßmann
Hash: SHA1
Sendmail, Inc., and the Sendmail Consortium announce the availability
of sendmail 8.13.7. It fixes a potential denial of service problem
caused by excessive recursion which leads to stack exhaustion when
attempting delivery of a malformed MIME message. Therefore, the
function mime8to7() has been modified to limit the recursion level
at (the compile time constant) MAXMIMENESTING. Note: This denial
of service attack only affects delivery of mail from the queue and
delivery of the malformed message. Other incoming mail is still
accepted and delivered. However, mail messages in the queue may
not be reattempted if a malformed MIME message exists.
For a complete list of changes see the release notes down below.
Remember to check the PGP signatures releases obtained via FTP or
HTTP.
Please send bug reports and general feedback to one of the addresses
listed at: http://www.sendmail.org/email-addresses.html
The version can be found at:
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.13.7.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.13.7.tar.gz.sig
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.13.7.tar.Z
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.13.7.tar.Z.sig
MD5 signatures:
5327e065cb0c1919122c8cecbeddbc28 sendmail.8.13.7.tar.gz
0d5d94da71e1023b7987f1bd309a3520 sendmail.8.13.7.tar.gz.sig
fff614180192995ff5b2c8660aa86594 sendmail.8.13.7.tar.Z
d53507962af44b6c2858e5b6bf469d84 sendmail.8.13.7.tar.Z.sig
You either need the first two files or the third and fourth, i.e.,
the gzip'ed version or the compressed version and the corresponding
sig file. The PGP signature was created using the Sendmail Signing
Key/2006, available on the web site (http://www.sendmail.org/) or
on the public key servers.
Since sendmail 8.11 and later includes hooks to cryptography, the
following information from OpenSSL applies to sendmail as well.
PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY
SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING
TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME
PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR
COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL
SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE
YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT
AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS ARE NOT LIABLE FOR
ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY.
SENDMAIL RELEASE NOTES
$Id: RELEASE_NOTES,v 8.1777.2.6 2006/06/05 22:32:41 ca Exp $
This listing shows the version of the sendmail binary, the version
of the sendmail configuration files, the date of release, and a
summary of the changes in that release.
8.13.7/8.13.7 2006/06/14
A malformed MIME structure with many parts can cause sendmail to
crash while trying to send a mail due to a stack overflow,
e.g., if the stack size is limited (ulimit -s). This
happens because the recursion of the function mime8to7()
was not restricted. The function is called for MIME 8 to
7 bit conversion and also to enforce MaxMimeHeaderLength.
To work around this problem, recursive calls are limited to
a depth of MAXMIMENESTING (20); message content after this
limit is treated as opaque and is not checked further.
Problem noted by Frank Sheiness.
The changes to the I/O layer in 8.13.6 caused a regression for
SASL mechanisms that use the security layer, e.g.,
DIGEST-MD5. Problem noted by Robert Stampfli.
If a timeout occurs while reading a message (during the DATA phase)
a df file might have been left behind in the queue.
This was another side effect of the changes to the I/O
layer made in 8.13.6.
Several minor problems have been fixed that were found by a
Coverity scan of sendmail 8 as part of the NetBSD
distribution. See http://scan.coverity.com/
Note: the scan generated also a lot of "false positives",
e.g., "error" reports about situations that cannot happen.
Most of those code places are marked with lint(1) comments
like NOTREACHED, but Coverity does not understand those.
Hence an explicit assertion has been added in some cases
to avoid those false positives.
If the start of the sendmail daemon fails due to a configuration
error then in some cases shared memory segments or pid
files were not removed.
If DSN support is disabled via access_db, then related ESMTP
parameters for MAIL and RCPT should be rejected. Problem
reported by Akihiro Sagawa.
Enabling zlib compression in OpenSSL 0.9.8[ab] breaks the padding
bug work-around. Hence if sendmail is linked against
either of these versions and compression is available,
the padding bug work-around is turned off. Based on
patch from Victor Duchovni of Morgan Stanley.
CONFIG: FEATURE(`dnsbl') and FEATURE(`enhdnsbl') used
blackholes.mail-abuse.org as default domain for lookups,
however, that list is no longer available. To avoid
further problems, no default value is available anymore,
but an argument must be specified.
Portability:
Fix compilation on OSF/1 for sfsasl.c. Patch from
Pieter Bowman of the University of Utah.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (OpenBSD)
iQCVAwUBRI7QoR57s8ivlZYlAQJloAP+Kpr2y6M1auuRGeWQErYViepR5UaKShtr
mdK+yUB4dlN710AegelVUlwrBHq5PHxgtyr6kHzpPhOxnbYFq47w2kHtU5b1GUkH
If3w+mD4Z7lzdc+GqzJrShb1mPCKmdixSzxzBbfD4JMpXdvSCmUFtaVudfwmaMYi
mc8VbqhWm5A=
=D+16
-----END PGP SIGNATURE-----
Kelsey Cummings
on mail queues? Sendmail 8.13.6 is working fine here but 8.13.7 isn't -
there is plenty of free space and inodes. Linux environment, nothing
strange in my site.config.m4 - just enabling Milter, starttls, SASL, and
FFR_BLOCK_PROXIES
Jun 14 12:23:38 a sm-mta[21482]: k5EJMoVj021482: low on space
(wingerboy.noc.sonic.net needs 5 bytes + 100 blocks in
/var/spool/mqueue), max avail: 15
-K
Kelsey Cummings
> Anyone else having trouble with 8.13.7 incorrectly detecting low space
> on mail queues? Sendmail 8.13.6 is working fine here but 8.13.7 isn't -
> there is plenty of free space and inodes. Linux environment, nothing
> strange in my site.config.m4 - just enabling Milter, starttls, SASL, and
> FFR_BLOCK_PROXIES
Disabling shared memory resolves the problem, restarting with different
keys did not.
-K
The Doctor
Claus Aßmann <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>Remember to check the PGP signatures releases obtained via FTP or
>HTTP.
>
>
Hmmm! I am using openssl 0.9.8c previews? Are their any compile
issues?
--
Member - Liberal International
This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Beware Linux the MS Windows of Unix! Demand UseNet an integral part of Internet!
Claus Aßmann
> Anyone else having trouble with 8.13.7 incorrectly detecting low space
> on mail queues? Sendmail 8.13.6 is working fine here but 8.13.7 isn't -
It's a regression in 8.13.7, see the website.
Kelsey Cummings
Claus - the patch helps but unfortunately does not totally resolve the
problem. With the patch applied it works fine for a while and then
falls over with the same low on space errors. I've verified the
behavior on two servers but haven't been able to figure out if I can
trigger the behavior. If there is any additional information I can
provide please let me know.
-K
Claus Aßmann
> Claus - the patch helps but unfortunately does not totally resolve the
> problem. With the patch applied it works fine for a while and then
> falls over with the same low on space errors. I've verified the
> behavior on two servers but haven't been able to figure out if I can
> trigger the behavior. If there is any additional information I can
> provide please let me know.
Use
smcontrol.pl mstat
from contrib/ to see the amount of free space, make sure
ControlSocketName
is enabled. Note: the code is now identical again to previous
versions, so this should have happened before too.
Does the problem occur if you disable SharedMemoryKey?
Kelsey Cummings
> Does the problem occur if you disable SharedMemoryKey?
No, it only occurs when SharedMemoryKey is set. Even while the low on
space errors are occuring the output of smcontrol.pl status looks
correct. My builds don't appear to support 'mstat'
Eg, before:
QueueDir free disk space (in blocks): 48325664
During:
QueueDir free disk space (in blocks): 48335632
k5MHf2mX010839: low on space (smtp-vbr11.xs4all.nl needs 0 bytes + 100
blocks in /var/spool/mqueue), max avail: 62
There appear to be plenty of other changes in queue.c between 8.13.6 and
8.13.7 but I haven't digested the code yet -- C is not one of my
strengths. I'll work on this some more.
-K
Steve Hubert
> Claus Aßmann wrote:
>> Kelsey Cummings wrote:
>>> Anyone else having trouble with 8.13.7 incorrectly detecting low space
>>> on mail queues? Sendmail 8.13.6 is working fine here but 8.13.7 isn't
>>
>> It's a regression in 8.13.7, see the website.
>
> Claus - the patch helps but unfortunately does not totally resolve the
> problem. With the patch applied it works fine for a while and then
> falls over with the same low on space errors. I've verified the
> behavior on two servers but haven't been able to figure out if I can
> trigger the behavior. If there is any additional information I can
> provide please let me know.
We may have some clues for this problem, at least for our configuration.
For us here's what goes wrong. Using 8.13.7 plus the 2006-06-14 and
2006-06-15 patches, for the command
date | .../sendmail -C /etc/mail/sendmail.cf <address>
we have
main()
setup_queues()
init_shm()
PtrFileSys = (FILESYS *) OFF_FILE_SYS();
where PtrFileSys[0] is initially set to the already existing shared memory
segment.
However, FILE_SYS_NAME(0) is never set when this happens. It might be that
it is expected it will be set in filesys_find(), for example in
main()
setup_queues()
filesys_setup()
filesys_find()
but filesys_find() returns early because it finds a match at
if (FILE_SYS_DEV(i) == st.st_dev)
return i;
[debugging was in an environment where all queues were in the same
filesys]
One problem this might cause is in filesys_update()
main()
collect()
collect_eoh()
collect_dfopen()
setnewqueue()
filesys_update()
freediskspace(FILE_SYS_NAME(i), ...)
where the call to freediskspace() will have a first argument of zero
instead of a directory name. It may have worked correctly in 8.13.6
because filesys_update() was returning before calling freediskspace() when
ShmId was != SM_SHM_NO_ID.
We think a fix may involve something like this change to filesys_find()
for (i = 0; i < NumFileSys; ++i)
{
if (FILE_SYS_DEV(i) == st.st_dev)
+ {
+ if (!FILE_SYS_NAME(i))
+ FILE_SYS_NAME(i) = name;
+
return i;
+ }
}
This explanation doesn't quite match with the symptoms Kelsey mentioned
but making this change seems to have fixed the similar problems we were
having. Thanks.
Steve Hubert
University of Washington
Kelsey Cummings
> This explanation doesn't quite match with the symptoms Kelsey mentioned
> but making this change seems to have fixed the similar problems we were
> having. Thanks.
Steve - whatever the problem was it appears to have been fixed in
8.13.8.Beta0. Although, now, I'm not convinced it wasn't fixed with the
patches available on sendmail.org -- I may have goofed testing the
patched binary on my end.
--
Kelsey Cummings - k...@sonic.net sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
Steve Hubert
> Steve - whatever the problem was it appears to have been fixed in
> 8.13.8.Beta0. Although, now, I'm not convinced it wasn't fixed with the
> patches available on sendmail.org -- I may have goofed testing the patched
> binary on my end.
It looks like 8.13.8.Beta0 is just 8.13.7 plus the two patches. I believe
that the problem is a real bug and I can reproduce it with the command I
gave in the last posting I sent, and fix it with the patch in that post.
So I'm hoping that or something similar goes into Beta1.
Steve
Claus Aßmann
> We may have some clues for this problem, at least for our configuration.
Does the problem go away if you revert to the 8.13.6 check?
if (ShmId != SM_SHM_NO_ID && DaemonPid != CurrentPid)
instead of (8.13.7):
if (ShmId == SM_SHM_NO_ID || DaemonPid != CurrentPid)
or the patched version (8.13.8.Beta0):
if (ShmId == SM_SHM_NO_ID && DaemonPid != CurrentPid)
Steve Hubert
Yes, it does seem to go away.
However, I'm nervous about this as the entire solution because it is still
the case that FILE_SYS_NAME is never set in this case. It isn't obvious to
me that FILE_SYS_NAME will never be used under these circumstances. For
example, in pickqdir() will fsavail ever be <= 0? If it is,
freediskspace() will be called with a first argument equal to zero. It
seems like making sure FILE_SYS_NAME is set correctly in filesys_update
would be a good thing to do even with the changed test. Thanks.
Steve