15.7 Early Security Problems with UUCP

UUCP is one of the oldest major subsystems of the UNIX operating system (older than the csh), and it has had its share of security holes. All of the known security problems have been fixed in recent years. Unfortunately, there are still some old versions of UUCP in use.

The main UUCP security problems were most easily triggered by sending mail messages to addresses other than valid user names. In one version of UUCP, mail could be sent directly to a file; in another version of UUCP, mail could be sent to a special address that caused a command to be executed - sometimes as root! Both of these holes pose obvious security problems. [8]

[8] Interestingly enough, these same problems reappeared in the sendmail program in recent years. People designing software don't seem to be very good about learning from the past.

Fortunately, you can easily check to see if the version of UUCP you are running contains these flaws. If it does, get a software upgrade, or disable your version of UUCP. A current version of BNU UUCP can be licensed from AT&T if your vendor doesn't have one.

To check your version of UUCP, follow the steps outlined here:

1. Your mail system should not allow mail to be sent directly to a file. Mailers that deliver directly to files can be used to corrupt system databases or application programs. You can test whether or not your system allows mail to be sent to a file with the command sequence:

   $ mail /tmp/mailbug
   this is a mailbug file test
   ^D

   If the file mailbug appears in the /tmp directory, then your mailer is unsecure. If your mailer returns a mail message to you with an error notification (usually containing a message like "cannot deliver to a file"), then your mail program does not contain this error. You should try this test with /bin/mail, /bin/rmail, and any other mail delivery program on your system.

2. Your UUCP system should not allow commands to be encapsulated in addresses. This bug arises from the fact that some early uuxqt implementations used the system ( ) library function to spawn commands (including mail). Mail sent to an address containing a backrsquoed command string would cause that command string to be executed before the mail was delivered. You can test whether or not your system executes commands encapsulated in addresses with the command sequence:

   $ uux - mail 'root `/bin/touch /tmp/foo`'
   this is a mailbug command test
   ^D
   $ uux - mail 'root & /bin/touch /tmp/foo'
   this is another test
   ^D

   The system should return mail with a message that /bin/touch /tmp/foo is an unknown user. If the mailer executed the touch - you can tell because a foo file will be created in your /tmp directory - then your uux program is unsecure. Get a new version from your vendor.

3. Check both types of addresses described earlier for mail that is sent by UUCP as well as for mail that originates locally on your system. For example, if the machines prose and idr are connected by UUCP, then log onto idr and try:

   $ mail 'prose!/tmp/send1'
   Subject: This is a mailbug test
   Test
   ^D
   $ mail 'prose!`/bin/touch /tmp/foo`'
   Subject: This is a mail bugtest #2
   Another test.
   ^D