Date: Thu, 28 Mar 2024 20:06:00 -0400 (EDT) Message-ID: <84490071.529.1711670760271@windcrest.sei.cmu.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_528_615478248.1711670760269" ------=_Part_528_615478248.1711670760269 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A complete revision history is at the end of this file. See als= o CA-96.24.sendmail.daemon.mode.html for information about additiona= l vulnerabilities in sendmail.
The CERT Coordination Center has received reports of two security proble= ms in sendmail that affect all versions up to and including 8.7.5. By explo= iting the first of these vulnerabilities, users who have local accounts can= gain access to the default user, which is often daemon. By exploiting the = second vulnerability, any local user can gain root access.
The CERT/CC team recommends installing vendor patches or upgrading to th= e current version of sendmail (8.7.6). Until you can do so, we urge you to = apply the workaround provided in Sec. III.C. In all cases, be sure to take = the extra precautions listed in Sec. III.D.
For beta testers of sendmail 8.8: The vulnerabilities described in this = advisory have been fixed in the beta version.
We will update this advisory as we receive additional information. Pleas= e check advisory files regularly for updates that relate to your site. In a= ddition, you can check ftp://ftp.cert.org/pub/latest_sw_versions/sendmail to ident= ify the most current version of sendmail.
There are two vulnerabilities in all versions of sendmail up to and incl= uding sendmail 8.7.5. The first vulnerability is a resource starvation prob= lem and the second is a buffer overflow problem.
When email is forwarded to a program using a .forward file or an :includ= e: statement within a .forward or alias file, that program is executed as t= he owner of the .forward file or the file referenced by the :include: state= ment. Similarly, if email is forwarded to a file, that file is opened as th= e owner of the .forward file or the file referenced by the :include: statem= ent. The file owner is called the "controlling user."
If the message cannot be delivered immediately, the name of the controll= ing user is written into the queue file along with the other delivery infor= mation so that the appropriate permissions can be acquired when the mail qu= eue is processed.
Only the name of the controlling user is written in the queue file. This= name is derived by calling the system routine getpwuid(3) on the us= er id of the file owner. If getpwuid fails, the sendmail default user (defi= ned by the DefaultUser option in 8.7 and by the "u" and "g" options in olde= r releases) is assumed.
In some cases, the system can be forced into resource starvation, thus f= orcing getpwuid(3) to fail even though an entry exists in /etc/passw= d corresponding to that uid. Since getpwuid has no way of portably returnin= g an error meaning "resource failure" as distinct from "user id not found,"= sendmail has no way of distinguishing between these cases; it assumes that= the uid is unknown and falls back to the default user.
By starving sendmail of specific resources, sendmail will create files o= wned by the default user. Once created, these files can be used to access o= ther files owned by the default user. In addition, these files owned by the= default user can be used to leverage access to other privileged users on t= he system.
There are several buffer overflows present in sendmail version 8.7.5 and= earlier. Some of the buffer overflows could result in local users gaining = unauthorized root access.
Significant work has been done on sendmail version 8.8 (now in beta test= ) to eliminate the problem, and the code changes originally planned for 8.8= have been backported to 8.7.6 to address these vulnerabilities.
Anyone with access to an account on the system can run programs or write= files as the default user. The danger of compromising the default user dep= ends primarily on the other files in your system owned by that user.
For example, on many systems the line printer spool directory (e.g., /va= r/spool/lpd) is owned by daemon; because the line printer subsystem runs se= tuid root, it may be possible to gain additional privileges. However, some = other systems have no files owned by user daemon on the default system, and= the only files owned by group daemon are not writable by that group; hence= , the danger is minimal.
Anyone with access to an account on the system can gain root access.
Install a patch from your vendor if one is available (Sec. A) or upgrade= to the current version of sendmail (Sec. B). Until you can take one of tho= se actions, we recommend applying the workaround described in Sec. C. This = workaround addresses the resource starvation problem but not buffer overflo= ws.
In all cases, you should take the precautions listed in Sec. D.
Note to beta testers of sendmail 8.8: The vulnerabilities described in t= his advisory have been fixed in the beta version of 8.8.
Below is a list of the vendors who have provided information about sendm= ail. Details are in Appendix A of this advisory; we will update the appendi= x as we receive more information. If your vendor's name is not on this list= , please contact the vendor directly.
Install sendmail 8.7.6. This version is a "drop in" replacement for 8.7.= x. There is no patch for 8.6.x. If you are using version 8.6 or earlier, yo= u need to upgrade to the current version and rebuild your sendmail.cf files= . Upgrading to version 8.7.6 addresses both vulnerabilities described in th= is advisory.
Sendmail 8.7.6 is available from
ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz
ftp://ftp.cert.org/pu= b/tools/sendmail/sendmail.8.7.6.tar.gz
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz= a>
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/se= ndmail/*
MD5 (sendmail.8.7.6.tar.gz) =3D 4a1f2179c53c9106bc8d7738f4d55667
Also in that directory are .Z and .sig files. The .Z file contains the s= ame bits as the .gz file, but is compressed using UNIX compress instead of = gzip. The .sig is Eric Allman's PGP signature for the uncompressed tar file= . The key fingerprint is
Type bits/keyID Date User ID pub 1024/BF7BA421 1995/02/23 Eric P. Allman <eric@CS.Berkeley.EDU> Key fingerprint =3D C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F= 45 29 Eric P. Allman <eric@Reference.COM> Eric P. Allman <eric@Usenix.ORG> Eric P. Allman <eric@Sendmail.ORG> Eric P. Allman <eric@CS.Berkeley.EDU>
We strongly recommend that when you change to a newXS version of sendmai= l you also change to the configuration files that are provided with that ve= rsion.
Significant work has been done to make this task easier. It is now possi= ble to build a sendmail configuration file (sendmail.cf) using the configur= ation files provided with the sendmail release. Consult the cf/README file = for a more complete explanation. Creating your configuration files using th= is method makes it easier to incorporate future changes to sendmail into yo= ur configuration files.
For sites that use the ampersand character ('&') in the gecos field = of /etc/passwd, they should be aware that this may cause the full name retu= rned to be corrupted or empty. (See man (4) passwd for further details on t= he purpose of the ampersand character in the gecos field.) Therefore when c= onfiguring sendmail, sites may also wish to ensure that information in the = gecos field is explicitly complete, rather than rely on name expansion usin= g the ampersand character.
Finally, for Sun users, a paper is available to help you convert your se= ndmail configuration files from the Sun version of sendmail to one that wor= ks with sendmail version 8.7.x. The paper is entitled "Converting Standard = Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of = Texas Instruments Inc. It is included in the distribution and is located in= contrib/converting.sun.configs.
Eric Allman, the author of sendmail, has provided the following workarou= nd to the resource starvation vulnerability.
Using smrsh as "prog" mailer limits the programs that can be run as the = default user. Smrsh does not limit the files that can be written, but less = damage can be done by writing files directly.
The damage can be almost entirely constrained by ensuring that the defau= lt user is an innocuous one. Sendmail defaults to 1:1 (daemon) only because= that is reasonably portable. A special "mailnull" account that is used onl= y for this purpose would be better. This user should own no files and shoul= d have neither a real home directory nor a real shell. A sample password en= try might be:
mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/d= ev/nullA corresponding entry should be made in /etc/group:=20
mailnull:*:32765:These assume that there are no other users or groups with id =3D 327= 65 on your system; if there are, pick some other unique value.=20
NOTE: When allocating a numeric uid to the "mailnull" user you should be= careful to ensure that this value is less than the value of the UID_MAX ke= rnel variable, if your system implements this variable. To check whether yo= ur system implements this variable (and the value that it uses), check for = a reference to it in the "limits.h" header file, which should be located in= the directory /usr/include, or one of its subdirectories. For further info= rmation on the use and content on the "limits.h" header file, see the man (= 4) limits.
After creating this user, change the line in /etc/sendmail.cf reading
O DefaultUser=3D1:1to read=20
O DefaultUser=3DmailnullIf you are running 8.6.*, you will have to change the lines reading= =20
Ou1 Og1to read=20
Ou32765 Og32765
Finally, if you are using the m4(1)-based sendmail configuration scheme = provided with sendmail 8.7.*, you should add the following line to the m4 i= nput file, usually named sendmail.mc:
define(`confDEF_USER_ID', 32765:32765)
The actual values should, of course, match those in the passwd file.
With *all* versions of sendmail, use the sendmail restricted shell progr= am (smrsh). You should do this whether you use vendor-supplied sendmail or = install sendmail yourself. Using smrsh gives you improved administrative co= ntrol over the programs sendmail executes on behalf of users.
A number of sites have reported some confusion about the need to continu= e using the sendmail restricted shell program (smrsh) when they install a v= endor patch or upgrade to a new version of sendmail. You should always use = the smrsh program.
smrsh is included in the sendmail distribution in the subdirectory smrsh= . See the RELEASE_NOTES file for a description of how to integrate smrsh in= to your sendmail configuration file.
smrsh is also distributed with some operating systems.
Use mail.local
If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with mail.= local, which is included in the sendmail distribution. It is also included = with some other operating systems distributions, such as FreeBSD.
Although the current version of mail.local is not a perfect solution, it= is important to use it because it addresses vulnerabilities that are being= exploited. For more details, see CERT advisory CA-95.02.
Note that as of Solaris 2.5 and beyond, mail.local is included with the = standard distribution. To use mail.local, replace all references to /bin/ma= il with /usr/lib/mail.local. If you are using the M4(1)-based configuration= scheme provided with sendmail 8.X, add the following to your configuration= file:
define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
WARNING: Check for executable copies of old versions of mail program= s
If you leave executable copies of older versions of sendmail installed i= n /usr/lib (on some systems, it may be installed elsewhere), the vulnerabil= ities in those versions could be exploited if an intruder gains access to y= our system. This applies to sendmail.mx as well as other sendmail programs.= Either delete these versions or change the protections on them to be non-e= xecutable.
Similarly, if you replace /bin/mail with mail.local, remember to remove = old copies of /bin/mail or make them non-executable.
Below is a list of the vendors who have provided information for this ad= visory. We will update this appendix as we receive additional information. = If you do not see your vendor's name, please contact the vendor directly.= p>
Source:
Software Security Response Team
Copyright (c) Digital Equipment Corporation 1996. All rights reserved.
08.SEP.1996
At the time of writing this document, patches (binary kits) for Digital'= s UNIX related operating systems are being developed. Digital will provide = notice of availability for remedial kits through AES services (DIA, DSNlink= FLASH), placed in the public FTP patch service domain and also be availabl= e from your normal Digital Support channel.
ftp://ftp.service.digital.com/public/{OS}/{vn.n} | | | |--version |--osf or ultrix
- DIGITAL EQUIPMENT CORPORATION
9/96
An official FreeBSD security advisory, including patches to close this v= ulnerability in FreeBSD 2.1.5 will be available shortly. The security advis= ory will appear at
ftp://freebsd.o= rg/pub/CERT/patches/SA-96:18/ when available.
HEWLETT-PACKARD SECURITY BULLETIN: #00059, 30 April 1997
Description: Sendmail patches for HP-UX releases 9.X thru 10.20
Security Bulletins are available from the HP Electronic
Support Center via electronic mail.
User your browser to get to the HP Electronic Support
Center page at:
http://us-support.external=
.hp.com
(for US, Canada, Asia-Pacific, & Latin-America)
http://europe-support.=
external.hp.com
(for Europe)
APAR - IX61303 IX61307
To determine if you have this APAR on your system, run the following com= mand:
instfix -ik IX61162 IX61306
To determine if you have this APAR on your system, run the following com= mand:
instfix -ik IX61304 IX61305
http://service.s= oftware.ibm.com/aixsupport/
or send e-mail to aixserv@aust= in.ibm.com with a subject of "FixDist".
IBM and AIX are registered trademarks of International Business Machines= Corporation.
Debian Linux: not vulnerable (uses smail)
Red Hat and derivatives:
ftp://ftp.redhat.com/pub/redhat-3.0.3/i38=
6/updates/RPMS/sendmail*
OSF's OSF/1 R1.3.2 is vulnerable to the buffer overflow problems. We wil= l address the problem in our next maintenance release.
SCO Internet FastStart release 1.0.0
SCO OpenServer releases 5.0.0 and 5.0.2
This SLS provides a pre-release version of sendmail release 8.7.6 for th= ese platforms. SCO hopes to have a final version of sendmail 8.7.6 availabl= e to address both issues mentioned in this advisory in the near future.
Note that only SCO Internet FastStart uses sendmail as the default mail = system. All other SCO operating systems use other mail systems such as the = Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr" mai= l system as the default, and as such are not vulnerable to this problem unl= ess otherwise configured to use sendmail.
SCO intends to provide a similar patch for SCO UnixWare release 2.1.0 in= the near future.
When configured to use a version of sendmail provided by SCO, releases p= rior to the ones mentioned here are also vulnerable, but no plans have yet = been made concerning patches for these earlier releases.
You can download SLS oss443a as shown below.
Anonymous ftp (World Wide Web URL) ftp://ftp.sco.COM/SSE/oss443a (SLS image)
ftp://ftp.sco.COM/SSE/oss443a.ltr.sse (c=
over letter/install notes)
The phone numbers available for interactive transfer from SOS are:
1-408-426-9495 (USA)
+44 (0)1923 210 888 (United Kingdom)
sum -r ------ 13804 630 oss443a 35304 14 oss443a.ltr.sse MD5 --- MD5 (oss443a) =3D 549260a71ca76f4e98dd38bccb72748c MD5 (oss443a.ltr.sse) =3D 7475d83f0db64a1af69eb66cd392a9d3Be sure to keep track of the README file at ftp://ftp.sco.COM/SSE/README for updates to this suppl= ement.
USA/Canada: 6am-5pm Pacific Daylight Time (PDT)
1-800-347-4381 (voice)
1-408-427-5443 (fax)
Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific Dayligh= t Time (PDT)
1-408-425-4726 (voice)
1-408-427-5443 (fax)
Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT)
+44 (0)1923 816344 (voice)
+44 (0)1923 817781 (fax) XS
Please refer to Silicon Graphics Inc. Security Advisory, "IRIX mail(1)/r= mail(1M)/sendmail(1M) Security Vulnerabilities," Number: 19980604-02-PX, di= stributed September 29, 1998 for additional information relating to this vu= lnerability.
The primary SGI anonymous FTP site for security information and patches = is sgigate.sgi.com (204.94.209.1). Security information and patches are loc= ated under the directories ~ftp/security and ~ftp/patches, respectively. Th= e Silicon Graphics Security Headquarters Web page is accessible at the URL = http://www.sg= i.com/Support/security/security.html.
Copyright 1996 Carnegie Mellon University.
Dec. 9, 1998 Updated vendor information for Silicon Graphics, Inc. Aug. 24, 1998 Updated vendor information for Silicon Graphics, Inc. Oct. 20, 1997 Appendix A - updated vendor information for Sun. Sep. 24, 1997 Updated copyright statement May 8, 1997 Appendix A - updated vendor information for Hewlett-Packard. Nov. 21, 1996 Introduction - Added a pointer to CA-96.24 for information on more sendmail vulnerabilities. Nov. 19, 1996 Appendix A - Updated Hewlett-Packard information to address both problems. Sep. 21, 1996 Sec. III.B - added instructions on configuring sendmail at sites that use '&' in the gecos filed of /etc/passwd. =09 Sec. III.C - added a note on uid for "mailnull" user. Sep. 19, 1996 Sec. III.B - added URL in Australia for sendmail Acknowledgements - included reference that had been omitted earlier.
Appendix, FreeBSD - added an entry.
Sep. 18, 1996 Appendix, BSDI - added an entry containing patch information= .