The following was posted on bugtraq: Date: Mon, 22 Nov 1999 23:48:17 -0800 Reply-To: Gregory Neil Shapiro <sendmail+gshapiro@SENDMAIL.ORG> Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM> From: Gregory Neil Shapiro <sendmail+gshapiro@SENDMAIL.ORG> Subject: Re: Sendmail 8.x.x - any user may rebuild aliases database X-To: Michal Zalewski <lcamtuf@IDS.PL> X-cc: BUGTRAQ@SECURITYFOCUS.COM, sendmail-bugs@sendmail.org To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <lcamtuf.4.05.9912122118210.4246-100000@nimue.ids.pl> X-UIDL: d3d08b1a16cd01ca35681b18bae9ed46 -----BEGIN PGP SIGNED MESSAGE----- lcamtuf> Sendmail up to recent 8.9.x versions - any user may pass -bi lcamtuf> parameter to /usr/sbin/sendmail. This will result in aliases lcamtuf> database rebuild. IMHO there's no reason to allow such things, but lcamtuf> no matter - something rather stupid is done during rebuild: lcamtuf> 5366 open("/etc/aliases.db", O_RDWR|O_TRUNC) = 6 lcamtuf> What a bad luck! There's approx 0.1 sec delay due to /etc/aliases lcamtuf> processing (on my system). Meantime, luser might deliver any lcamtuf> signals to sendmail process... SIGKILL is quite good. After that, lcamtuf> /etc/aliases.db will be left in unusable state (no EOF marker), lcamtuf> causing DoS: Thank you for bringing this to our attention. We have limited the newaliases command to root and trusted users for 8.10.0.Beta7. We have also deprecated the AutoRebuildAliases option since if set, a similar attack may be possible. We intend to remove the AutoRebuildAliases functionality in a future version. I've included a patch against sendmail 8.9.3 for those who want to protect against this denial of service attack. As always, we encourage mailing bug reports, including documentation or release notes bugs, to sendmail-bugs@sendmail.org. Security issues can be mailed to sendmail-security@sendmail.org and encrypted with the sendmail-security@sendmail.org PGP key: Type Bits KeyID Created Expires Algorithm Use pub 1024 0x16F4CCE9 1999-06-23 ---------- RSA Sign & Encrypt uid Sendmail Security <sendmail-security@sendmail.org> The sendmail 8.9.3 patch: --- main.c~orig Sat Jan 9 15:31:13 1999 +++ main.c Wed Nov 17 19:04:44 1999 @@ -984,6 +984,18 @@ usrerr("Permission denied"); finis(FALSE, EX_USAGE); } + if (OpMode == MD_INITALIAS && + RealUid != 0 && + RealUid != TrustedUid && + !wordinclass(RealUserName, 't')) + { + if (LogLevel > 1) + sm_syslog(LOG_ALERT, NOQID, + "user %d attempted to rebuild the alias map", + RealUid); + usrerr("Permission denied"); + finis(FALSE, EX_USAGE); + } if (MeToo) BlankEnvelope.e_flags |= EF_METOO; Fix: See patch posted by Gregory Shapiro of sendmail.org to BUGTRAQ above. It would be nice to have this committed before 3.4 is released. You may wish to remove the AutoRebuildAliases option too. How-To-Repeat: See description.
Responsible Changed From-To: freebsd-bugs->imp I'll look into this
Cy.Schubert@uumail.gov.bc.ca wrote: > I've included a patch against sendmail 8.9.3 for those who want to protect > against this denial of service attack. > See patch posted by Gregory Shapiro of sendmail.org to BUGTRAQ > above. It would be nice to have this committed before 3.4 is > released. I've committed this to both -current and 3.x-stable. > You may wish to remove the AutoRebuildAliases option too. I haven't done this for now as it requires the sysadmin to have edited the /etc/aliases file. We can turn it off by default though in the .cf/.mc's that we ship. Cheers, -Peter
Responsible Changed From-To: imp->peter I think Peter fixed this a while ago. Over to him for confirmation.
Responsible Changed From-To: peter->gshapiro Assigned to sendmail maintainer.
State Changed From-To: open->closed sendmail 8.11.0 has been imported into -current. The new version fixes the problem.