However beware that later megapatches may NOT contain these fixes:
the announcement
v5.1a/t64v51ab01as0001-20020116.README
contains the bizarre warning:
Core dumps follow symlinks, even for setuid programs (fixed in Jan 02
patches).
Create directory /core with no permissions:
mkdir /core; chmod 0 /core
Put the following line into the file /sbin/rc3 (this is a sh
script; most processes run by users are descendants of this):
ulimit -h -c 0
(WE DID NOT DO THIS YET: INVESTIGATE) Modify /etc/inittab to read
something like:
s3:3:wait:sh -c 'ulimit -h -c 0; exec /sbin/rc3 < /dev/console > /dev/console 2>&1'
cons:1234:respawn:sh -c 'ulimit -h -c 0; exec /usr/sbin/getty console console vt100'
(WE DID NOT DO THIS YET: INVESTIGATE) Since we protect descendants of rc3,
maybe only console logins (via the serial port on the back) are
un-protected. Can we restrict console logins to root only by adding
v_users=root
to
edauth -g -dv console
? Maybe that would prevent display :0 logins too.
(WE DID NOT DO THIS YET: INVESTIGATE) With C2 security, disable core dumps
on a "per user" basis by adding
:u_rlimit_core#0:
to the default database
edauth -dd default .
Wrap /sbin/init with binary (maybe cannot use a shell script at
that level; compile this with 'cc -non_shared -s'):
Still you may end up with core files: from root processes, which
specifically raise the core limit. Note that dxaccounts may do this
(AM_rlimits in /usr/shlib/libaccmgr.so) (so you do not freak out)...
Though not documented, DEC's xterm honours the '-l' and '-lf name'
(log, and logfile name) options; you can toggle logging via the 'Main
Options' menu (ctrl-LeftMouse); or use -xrm '*logging: true' -xrm
'*logFile: name'. This may be dangerous, see the
BugTraq message.
(I have tried to 'break in', without success, so maybe the DEC logfile
open is safe after all. I used the reported method, and tried repeatedly in
a loop, running for about 1/2 hour. The test is not conclusive as success
depends on timing of the replacement of the symlink.)
I noticed a bug in the DEC xterm on V5: it does not 'close' the wtmp file
(i.e. does not write a correct entry) upon exiting (so 'last' will think
that the user is still logged on); my version gets this right.
DEC's xterm is also vulnerable to VT100 escape sequences. Some
blurb (sent to AusCERT in August 98, AUSCERT#55208):
The recent discussion on mailer vulnerabilities reminded me of VT100 escape
codes: an ENQ or 'ESC Z' sent to the terminal causes it to send an
identification string, essentially as if the user had typed it on the
keyboard. Thankfully this identification string is short (and ugly) so may
not be exploitable, unless the user has commands named 1 or 2c in his PATH.
As a design mistake, xterm and descendants also implement and honour the
VT100 escape codes. While I am reasonably happy for xterm to accept codes
to act upon (resize window or move cursor), I see no justification for it
to return strings as if the user had typed them. (Programs should use fcntl
calls instead.) In environments where command names may be numeric, even
"cursor position report"-s may be exploitable.
To illustrate the problem, type the following command at a shell prompt
within a dtterm:
Note that it should be possible to include the appropriate string in an
email message, or even in the Subject: line. This would then make dtterm
and ucb-mail users vulnerable.
On the platform I use (DEC Alpha, dUNIX V4.0B), xterm or dxterm do not seem
to be able to return arbitrary strings like dtterm does; however xterm
might honour more escape sequences on other platforms. (The description of
the sequences I used for dtterm comes from XFree86.) I did not investigate
trying to define function keys to send arbitrary strings (execute arbitrary
commands).
I realize that the above is a design, not an implementation issue, so would
affect just about all vendors of X-windows, as well as VT100 terminals and
emulators. Unless these vendors are made aware of the problem, we may soon
see VT100 exploits emailed around. Will we create filters to suppress VT100
codes, like MIME headers may be filtered now?
There is no dxsession at V5, get hold of the V4 files:
Check/set SRM console variable:
Set secure_console on ('man sulogin' for more):
Set flag so /sbin/init.d/savecore will not leave you in single-user mode:
Use Enhanced (C2) security.
Use tcp_wrappers: see
porcupine.org
or the
AusCERT mirror.
Use identd: I use my version of pidentd
pidentd-2.7b3p.tgz
Use cleantmp instead of
'find /tmp ... -exec rm ...' constructs in root cron jobs, maybe also in
/sbin/init.d/rmtmpfiles.
Fix /usr/share/lib/tmac/tmac.an for security (paranoia):
You must upgrade Netscape to version 4.77
(obliterating whatever DEC had in place).
Still, get all users to disable Java in their Netscape browsers (check all
~/.netscape/preferences and ~/.netscape/preferences.js files).
Use the latest version GhostScript gs6.50.
Paul Szabo
psz@maths.usyd.edu.au
1 Feb 02
useg_reng cannot account for Tru64 UNIX patches placed on the internet by
other groups. If you have accepted Tru64 UNIX OS, ASE, or TCR patches from
other groups you must work with them to determine if their patches have been
superseded by this patch kit.
Problems with core files
They fill up users' file space; root daemon processes fill up /.
Protection against core files
> It seems also that if you do not have read privileges on a program that
> you execute, it will not core dump. So another quick fix to this problem
> would be to take read permissions away on all your suids.
We could do that reasonably easily with protect_software, but it would be
ugly; we would depend on another quirk (bug?) of the OS; and would not work
for setuid binaries in /usr/local (due to some NFS weirdness, which
requires read access). Also, for wrapped utilities like crontab (where
crontab is a setuid wrapper which then execs crontab.real), which file must
be unreadable? (Probably the wrapper, as crontab.real is already
execute-only.)
#define REAL_PROG "/sbin/init.real"
#include <stdlib.h>
#include <stdio.h>
#include <sys/resource.h>
void main( int argc, char* argv[] ) {
struct rlimit rl;
rl.rlim_cur = 0;
rl.rlim_max = 0;
if ( setrlimit( RLIMIT_CORE, &rl ) ) {
perror ( "Init wrapper, problem with setrlimit" ); }
execv( REAL_PROG, argv );
perror( REAL_PROG );
exit( 1 ); }
(While
sh -c 'ulimit -h'
shows "coredumpsize 02768 kbytes", that must be a bug in formatting:
csh -c 'limit -h'
and
ksh -c 'ulimit -H -a'
are correct and in fact core files are not written.) All the other, above
methods are superfluous, but some are left in place for historical reasons
and to make things more robust.
sendmail
We avoid using sendmail where feasible. Instead we use our own SMTP daemon,
running as a non-root user after port 25 is open - it is too dependent on
local conditions to be publicly released.
named
We use the latest BIND,
running as a non-root user.
xterm
I use my own /usr/bin/X11/xterm (modified from
XFree86): xterm.tgz . This uses my
ptyfix package ptyfix.tgz , so
does not need to be setuid root.
ksh -c 'print "\033]0;;bad-cmd;\007\033[21t"'
This will set the window title to ";bad-cmd;", then type it (as if the user
had typed it); bad-cmd will be executed if the user then presses [RETURN].
CDE (Common Desktop Environment)
Do not use, because it is full of bugs.
Replace some files:
LPRng
I use LPRng, replacing
the DEC lpr/lpd.
Wrap setuid programs
Use the security wrapper
sec_wrapper.c
to protect against command-line buffer overflows: use as a front-end
wrapper for setuid programs like lpr. Maybe the following will do:
#!/bin/ksh -
# Wrap a few utilities
for FILE in /usr/bin/X11/dxconsole /usr/bin/X11/dxterm /usr/bin/at /usr/bin/crontab; do
case "$FILE" in
*/at ) DX='-DMAX_ARG_LENGTH=30';;
*/crontab ) DX='-DMAX_ARGC=3 -DMAX_ARG_LENGTH=100';;
* ) DX=;;
esac
cc -o wrap.exe -DREAL_PROG="\"$FILE.real\"" $DX sec_wrapper.c
mv -i $FILE $FILE.real
chmod 711 $FILE.real
mv -i wrap.exe $FILE
chown root.bin $FILE
chmod 4755 $FILE
done
rm -f /usr/bin/X11/xconsole # Use -f, or get 'rm: override protection 711?'
ln /usr/bin/X11/dxconsole /usr/bin/X11/xconsole
# The originals needed wrapping; now we just point them elsewhere (which are in fact wrapped).
# (lpc was not wrapped, we simply took setuid off.)
for FILE in /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/sbin/lpc; do
NAME="${FILE##*/}"
mv -i $FILE $FILE.real
chmod 711 $FILE.real
ln -s /usr/local/lib/LPRng/bin/$NAME $FILE
done
Set sane permissions
I use the shell script
protect_software
to set correct permissions on system software: turn off setuid bits and the
like. Look within the script as to what, and in comments as to why, is being
set. This script is highly customized for my environment, and is likely to give
endless complaints elsewhere.
Sanitize inetd.conf
Disable unwanted things from /etc/inetd.conf, possibly with:
perl -i.bak -pe 's/^/#/ unless m/^#/ or m/^(ftp|telnet|backup|auth|logid)\s/' /etc/inetd.conf
init.d daemons
Turn off unwanted daemons, e.g. with:
#!/bin/ksh -
for F in nsrd common_agent evm insightd smauth smsd snmpd; do
mv /sbin/init.d/$F /sbin/init.d/$F.BLOCKED
done
Fix insecure /tmp file handling (some, but not all, fixed in Jan 02
patches):
perl -i.bak -pe '
s/^/#/, print "### Insecure PSz 3 Nov 00\nerrtmp=/etc/sbin_inet_\$\$.tmp\n" if m:^errtmp=/tmp/:
' /sbin/init.d/inet
perl -i.bak -pe '
print "### Insecure PSz 27 Nov 00\n" if m:Unlocking:;
s:/tmp/pty_list:/etc/pty_list:g;
' /sbin/init.d/rmtmpfiles
perl -i.bak -pe '
if (/<<.*EOF/) {
chomp; s/ *<<.*//; ($x,$c)=/^(\s*)(.*)$/; $l="";
while (<>) {
if (/EOF/) { print "${x}{ $l} | $c\n"; $_=""; last; }
chomp; s/"/'"'"'/g; s/^\s*//; $l .= "echo \"$_\"; ";
} }
' /sbin/init.d/savecore
Add nfsportmon to nfs startup:
perl -i.bak -pe '
$p= print "\n### Added PSz 4 May 98\n\t/usr/sbin/nfsportmon on\n" if /;;/ and not $p;
s/-i.$/-i -s\"/, $q= print "### Option -s added PSz 14 Dec 98\n" if /MOUNTOPTS/ and not $q;
' /sbin/init.d/nfs
inittab startup
Turn off unwanted things in /etc/inittab (fixed in Jan 02
patches):
perl -i.bak -pe 's/^/# / if m:/sbin/it:' /etc/inittab
fstab
Unless you really need it (used by ladebug and Java compilation and/or
runtime), disable /proc procfs:
perl -i.bak -pe 's/^/#/ if m/proc/' /etc/fstab
Patch suidperl
If you use suidperl, up to version 5.6.0, then you need to patch it:
cd /usr/local/bin
cp -i suidperl suidperl.ORIG
perl -pe 's/mail root/NOmailZZZ/' < suidperl.ORIG > suidperl
chmod 4711 suidperl
(Your file may be named sperl or sperl5.6.0 or whatever, and permissions or
ownership may vary. Beware.)
Miscellaneous settings
You may want to include in your /etc/ntp.conf file (even after the
May 2001 patch of xntpd):
##Do not use this: it makes the disk spin up hourly
##driftfile /cluster/members/{memb}/etc/ntp.drift
server ntp.domain.com version 3
## Security. Would just the two lines:
# restrict default noquery
# restrict 127.0.0.1
## do the trick?
# Do not serve time or stats to anyone
restrict default ignore
# Get time from server (must be IP address)
restrict 123.45.67.89 noquery
# Need to talk to myself at startup...
restrict 127.0.0.1
>>> set auto_action boot
rcmgr set SECURE_CONSOLE YES
rcmgr set SAVECORE_FLAGS M
cat <<'EOF' >>/usr/share/lib/tmac/tmac.an
.\"
.\" Security additions PSz 28 Jul 99 (based on BugTraq messages)
.\" For other nroff implementations, also beware of open, opena, pso and !
.rm sy pi
.de pi
.tm file \\n(.F, line \\n(.c: unsafe to execute request `.pi \\$1'
..
.de sy
.tm file \\n(.F, line \\n(.c: unsafe to execute request `.sy \\$1'
..
.\" End of change
EOF
Third-party software
Be careful of what third-party software you use. In particular:
Disclaimer
Only issues of relevance to my departmental machines are listed. Many
security issues not covered here, either because I never knew about them,
or because I did not think they were relevant to my setup (our network is
behind a firewall). Do not rely solely on my advice. Conversely, following
any advice here may render your computer inoperable. Use at your own risk.
- Please let me know if I missed something obvious, or if any of the advice
above gave you trouble.