System Patches
[posted 2002/01/22]
In the past week, a handful of our machines were compromised by a cracker exploiting the CDE Subprocess Control Service (dtspcd) buffer overflow vulnerability. PIKT alerted us to the security breach with
Date: Wed, 16 Jan 2002 19:25:24 -0600 (CST)
From: Super-User <root@bucharest.uppity.edu>
To: ...
Subject: PIKT Alert on bucharest: Urgent
PIKT ALERT
Wed Jan 16 19:24:52 2002
bucharest
URGENT:
RootCoreFileExistUrgent
Deal with /core files
/core: ELF 32-bit MSB core file SPARC Version 1, from 'dtspcd'
-rw-rw-rw- 1 root root 547120 Jan 16 19:04 /core
moved /core file to /tmp, after the move:
/dev/dsk/c0t0d0s0 61484 33041 22295 60% /
Before we had a chance to react to this, PIKT reported something perhaps even more worrisome:
Date: Thu, 17 Jan 2002 08:35:30 -0600 (CST)
From: Super-User <root@bucharest.uppity.edu>
To: ...
Subject: PIKT Alert on bucharest: Critical
PIKT ALERT
Thu Jan 17 08:32:15 2002
bucharest
CRITICAL:
RunawayProcCritical
Detect runaway processes, and cpu-hogs
USER TT PID PPID TIME COMMAND
root ? 23757 1 02:08:00 ./m
root ? 23756 1 02:08:58 ./m
root ? 23755 1 02:12:34 ./m
root ? 23754 1 02:06:39 ./m
"m" is a DOS tool, which in this case was being used to attack a host somewhere in Poland.
(PIKT reported various other signs of trouble with bucharest that night--all symptoms of the heavy workload imposed by the four m procs.)
After applying the recently released Solaris dtspcd patch, I was motivated finally to implement an alarm script I've been thinking about for quite a long time. The following is from a new configuration file, alarms/patches_alarms.cfg:
///////////////////////////////////////////////////////////////////////////////
//
// patches_alarms.cfg
//
///////////////////////////////////////////////////////////////////////////////
...
#if solaris
PatchesSystemNotExistWarning
init
status active
level warning
task "Report the absence of critical system patches"
input file "=patches_system_obj"
dat $patch 1
keys $patch
rule // bypass placeholder
if $patch eq "000000-00"
next
endif
rule // every $patch has its own #dn value
set #dn = #daynumber()
rule
set $log = "/var/sadm/patch/$patch/log"
rule // initialize state
set $state = "-"
rule // look for evidence of successful patch
if -e $log
&& #val($command("=grep -c 'was successful' $log"))
set $state = "+"
endif
rule // report if not found or unsuccessful
if $state eq "-"
if $state ne %state // report initial
|| #dn < %dn // repeat weekly
output mail "patch $patch not installed!"
endif
endif
#endif // solaris
...
///////////////////////////////////////////////////////////////////////////////
=patches_system_obj is defined in macros/files_pikt_obj_macros.cfg as
#if solaris patches_system_obj =objdir/PatchesSystem.obj #endif
PatchesSystem.obj sources from the new configuration file patches_system_objects.cfg:
///////////////////////////////////////////////////////////////////////////////
//
// patches_system_objects.cfg
//
///////////////////////////////////////////////////////////////////////////////
#if solaris
PatchesSystem
000000-00 // placeholder to ensure stanza content
/*
// empty template, ready for filling in
# if solaris26
# elsif solaris27
# elsif solaris28
# endif
*/
// dtspcd
# if solaris26
# if ! kiev // lacks prerequisite packages
105669-11
# endif // ! kiev
# elsif solaris27
106934-04
# elsif solaris28
108949-07
# endif // solaris26 ...
...
#endif // solaris
///////////////////////////////////////////////////////////////////////////////
After registering some important security-related system patches in this file, installing on all Solaris systems, and running the PatchesSystemNotExistWarning script (in a Test alert), sure enough, we discovered a few systems with missing patches because
- they were out of action when the patch(es) were applied
- they were new or rebuilt systems, and we forgot to apply the patches
- other reasons
Anyway, this is one more PIKT-based addition to our security toolkit. This
will be refined and expanded as we go along. (Among other things, we need
an automated way to register newly released patch versions in the
patches_system_objects.cfg file.)
For more examples, see Developer's Notes.