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:
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.
Core dumps follow symlinks, even for setuid programs (fixed in Jan 02 patches).
> 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)...
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?
There is no dxsession at V5, get hold of the V4 files:
#!/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
perl -i.bak -pe 's/^/#/ unless m/^#/ or m/^(ftp|telnet|backup|auth|logid)\s/' /etc/inetd.conf
#!/bin/ksh - for F in nsrd common_agent evm insightd smauth smsd snmpd; do mv /sbin/init.d/$F /sbin/init.d/$F.BLOCKED doneFix 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
perl -i.bak -pe 's/^/# / if m:/sbin/it:' /etc/inittab
perl -i.bak -pe 's/^/#/ if m/proc/' /etc/fstab
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.)
##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
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