The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #246 [DANGER: UUCP *can* propogate the Worm] (1 message, 1797 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/246.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: ames!pyramid.pyramid.com!csg@ea.ecn.purdue.edu (Carl S. Gutekunst)
To: phage
Date: Fri 20:51:58 11/11/1988 EST
Subject: DANGER: UUCP *can* propogate the Worm
References: [Thread Prev: 245] [Thread Next: 249] [Message Prev: 240] [Message Next: 241]

Thanks to some simple and brilliant observations by Romain Kang (nice to be
able to call someone besides Morris "brilliant"), we verified that the Send-
mail debug option can be exploited via UUCP. The hole is /bin/rmail, which
noiselessly passes anything on its command line through to sendmail. One of
those things can be the -d option, which invokes sendmail debugging. You can
follow from there. You could not use sendmail to send such a letter bomb,
since it requires that the envelope and the header contain different strings;
you'd have to directly call uux. Small comfort.

I tried invading one of our machines that way, and it worked just dandy.

At least the following fixes seem necessary:

- Modify /bin/rmail to not trust its command line arguments. /bin/rmail is not
  supposed to accept any options, therefore it should not accept any arguments
  that begin with a hyphen. It should also strip all quoted arguments.

- Restrict the debug option to wizardly users (from the wizards table in the
  .cf file), or to user root. The latter would still be unsafe on sloppily-run
  systems when uucico gets started by cron and runs under root; but if that's
  true, then *this* will be the least of their security holes. (Note: this
  isn't a problem with HoneyDanBer or 4.3BSD UUCP.)

- Don't allow mail to pipes, even when debugging is on. Actually, this was the
  part about sendmail that I didn't know prior to the Worm. I can see where it
  might be a *LITTLE* help when debugging. Very little help. I vote to nuke
  it, and allow mail to pipes only in the aliases and .forward files.

I have made the /bin/rmail fix (and installed it on pyramid!), and will post
the new rmail.c to this list, once I get permission from Keith Bostic. Also,
Romain pointed out that rmail's use of popen was highly questionable; we took
care of that, too, although we couldn't come up with a way to propogate the
worm by that means. (Uux eats all the characters that make popen() dangerous.)

One *could* remove the debug facility from sendmail completely (it's just a
#define in sendmail.h), as DEC did in Ultrix 2.0. I don't like this, because
the debug option is such a big help when debugging the .cf and alias files.

The following patch will turn off pipes in sendmail, except when aliases are
being used:

*** /tmp/,RCSt1021654	Fri Nov 11 16:36:55 1988
--- recipient.c	Fri Nov 11 16:32:09 1988
***************
*** 196,202
  	{
  		a->q_mailer = m = ProgMailer;
  		a->q_user++;
! 		if (a->q_alias == NULL && !tTd(0, 1) && !QueueRun && !ForceMail)
  		{
  			usrerr("Cannot mail directly to programs");
  			a->q_flags |= QDONTSEND;

--- 196,202 -----
  	{
  		a->q_mailer = m = ProgMailer;
  		a->q_user++;
! 		if (a->q_alias == NULL && !QueueRun && !ForceMail)
  		{
  			usrerr("Cannot mail directly to programs");
  			a->q_flags |= QDONTSEND;

Any sendmail wizards out there know if it is safe for pipes to be allowed when
returning dead mail (ForceMail flag is set)? Or is someone going to send mail
to bad addresses, and slip shell scripts into the From: line?

Are Eric Allman and/or Bill Nowicki reading this list?

<csg>

END OF DOCUMENT