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