Secure your Digital UNIX (Tru64) Alpha

You may want to make your DEC/Digital/Compaq Alpha, running Tru64 UNIX, more secure. Please see the disclaimer at end.

A Belorussian translation is available at http://www.designcontest.com/show/securedu-be.

Obsolete

This page is not up-to-date since May 2003: because I was busy with Windows nonsense, and because we have abandoned Tru64 and migrated to Debian Linux. Sorry.


Contents


Keep up with patches

At long last, DEC/Compaq/HP seem to be working steadily to fix problems and releasing patches; unfortunately it is a drag to keep up with them ...

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:

Were the previous (routed, ypxfrd/ypserv and IGMP, 8 Oct and 14 Nov 02) patches left out of PK6?


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:

I have not yet checked its contents: it is meant to replace v5.1/t64v51b19as0005-20020411.tar and include all other patches mentioned below. I do not know whether there are analogous megapatch fixes for other OS versions.


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:

Apparently, V5.1 with PK5 (BL19) and V5.1A with PK2 (BL2) or higher, are not affected.


On 30 Aug 2002, Compaq released security patches for several buffer overflows (replacing the 1 Aug patches for just /bin/su):

Make sure you install these: exploits have been posted on public mailing lists.

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):

as it seems to contain the patches mentioned below, and it also fixes the mkdir(2) system call. I do not know whether there are analogous megapatch fixes for other OS versions.


In April 2002, Compaq released a bunch of security patches (then newer versions in May 2002):

Make sure you install these or equivalents. (Compaq stopped supporting versions of DecUNIX older than V4.0F or 5.0A.)


At the end of January 2002, Compaq released a bunch of security patches:

Make sure you install these (or equivalent) patches.

However beware that later megapatches may NOT contain these fixes: the announcement v5.1a/t64v51ab01as0001-20020116.README contains the bizarre warning:
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 /.

Core dumps follow symlinks, even for setuid programs (fixed in Jan 02 patches).

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.)

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'):

#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.

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)...


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.

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:

        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].

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?


CDE (Common Desktop Environment)

Do not use, because it is full of bugs.

There is no dxsession at V5, get hold of the V4 files:

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

Check/set SRM console variable:
>>> set auto_action boot

Set secure_console on ('man sulogin' for more):
rcmgr set SECURE_CONSOLE YES

Set flag so /sbin/init.d/savecore will not leave you in single-user mode:
rcmgr set SAVECORE_FLAGS M

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):

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:

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.


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.


Paul Szabo psz@maths.usyd.edu.au 26 Sep 03