No translations please!
Do Secure your PC
(and keep up-to-date) instead, if you want to increase your search engine ranking!
Look for patches in
ftp://ftp.support.compaq.com/patches/public/unix/
.
The compaq.com Web and FTP servers may be closed down from Oct
2003, and you should probably look for patches on
http://www.itrc.hp.com
(probably needs free registration) or
ftp://ftp.itrc.hp.com/tru64_patches/tru64/
.
On 28 May 03, patches were released for "CDE Buffer Overflows":
SSRT2373 libDtHelp
SSRT2374 libDtSvc
SSRT2405 dtprintinfo
SSRT2415 dtsession
SSRT2416 dtappgather
On 26 May 03, an old V4.0F patch was re-released (with same filename):
On 28 Apr 03, a bulletin "SSRT3471 dupatch and setld utilities" was released (search for SSRT3471 in http://thenew.hp.com/country/us/eng/support.html).
No patches after over two years of notice, just a workaround: use dupatch and setld in single-user mode only, and verify that there are no symlinks in /tmp or /var/tmp. (Note: bulletin implies to check /var/tmp only, must also check /tmp. Bah...)
On 22 Apr 03, a V5.1B patch was released for "SSRT3533 Cluster Alias/NFS":
On 17 Apr 03, patches were released for "SSRT3498 screend":
Note: Is the V5.0A patch missing?
Note: The V5.1 patch contains several other (DoS and root-access buffer
overflow) fixes also.
On 1 Apr 03, patches were released for:
SSRT2322 Bind resolver exploit in ISC
SSRT2341 calloc() potential overflow
SSRT2384 TCP exploit denies all RPC service
SSRT2412 portmapper hang after port scan with C2 enabled
SSRT2439 xdrmem_getbytes() potential overflow
Note: the V5.0A patch was re-released on 19 Mar 03, with the same filename; then on 27 Mar 03 the V4.0F, V4.0G and V5.0A (again!) patches were re-released, all with the same filename.
On 12 Mar 03, patches were released for "SSRT0845U stdio file descriptors":
On 6 Mar 03, three patches were released for V5.1 (with PK6/BL20) only:
BIND (named) patches released on 5 Mar 03 (for V5.1 and V5.1a only??):
X11/xfs patches released on 4 Mar 03 (for V5.1 only??):
Sendmail patches released on 4 Mar 03:
If using V5.1, then install PK6 (BL20) released on 21 Feb 03:
On 14 Nov 02, Compaq released security patches for IGMP:
On 8 Oct 02, Compaq released security patches for ypserv, ypxfrd and routed:
On 10 Sep 2002, Compaq released security patches for TPC/IP, ARP and ftpd, for several OS versions:
On 30 Aug 2002, Compaq released security patches for several buffer overflows (replacing the 1 Aug patches for just /bin/su):
BEWARE of /sbin/mount in (patch OSFPATC0136901510 within) t64v51b19-c0136901-15143-es-20020817.tar: it sends a SIGUSR1 to mountd (whatever for?), and a mountd earlier than that from (patch OSFPAT00092101510 in PK5/BL19) t64v51b19as0005-20020411.tar will die. Upgrade both mount and mountd, or neither.
(Superseded by
v5.1/t64v51b20as0006-20030210.tar
above?)
If using V5.1, then install PK5 (BL19):
In April 2002, Compaq released a bunch of security patches (then newer versions in May 2002):
At the end of January 2002, Compaq released a bunch of security patches:
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. See the
Digital Defense message on
BugTraq, and
some blurb I 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
26 Sep 03
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.