If you haven't already learned about srsh, you may want to read this.

The hard part: Telling people what you've just done. This has has three parts.

• Categorizing the results
  First, log onto network-stats-collector-1.nacs, and if possible, generate a list of hosts that are likely to need to the patch (this isn't always going to be very accurate). EG, if this is a solaris vulnerability, run ~nacsstats/bin/sunos5 > /tmp/sunos5. This takes a while, so go on to the next step before completion of this step.

  On bounce, there's a script called "categorize". cd into the srsh output directory (usually ~srsh/output/generic or ~srsh/output/username). Then mkdir /tmp/something, where something is just a temporary name. EG, For the "ufsrestore" vulnerability, I use /tmp/ufsrestore. Then say categorize /tmp/something.

  categorize will show you the (top of the) first each srsh result in turn (actually, it only shows representative files, not all files - to save time). Select an option from the menu presented, EG "good" if the patch appears to have been applied cleanly, or "bad" if the patch failed to apply, or "conditional" if srsh was unable to connect to the host, or "irrelevant" if this is a machine that didn't need the patch. If the output is just "mail", treat this as "conditional".

  This should leave you with the directory /tmp/something containing files with names like good, bad, and conditional.

  ftp these files over to network-stats-collector-1.nacs, into /tmp.

  By now, the first step is probably completed; you probably have a list of (EG) Solaris machines waiting for you. If not, (you could) wait until that step is completed (I say this to keep these instructions relatively simple - you're free to parallelize as you see fit).

  The set intersection of the files in conditional and in sunos5 are machines that should have been patched, but weren't. The intersection can be generated with the set-intersection command, from dcslib. You should concatenate these hosts onto bad.

• Telling people on nacs_unix@hydra
  Send e-mail to nacs_unix@hydra, saying you've taken steps to patch the ufsrestore (or whatever) vulnerability. This is pretty informal. List the hosts that the patch applied cleanly on. List the hosts that the patch failed on, and mention that manual intervention is needed on these hosts. Tell people what steps were taken to fix the problem - you can probably just give them a copy of the srsh script you used - the purpose of this is mostly so they have some idea where to start, when they go to fix the problem manually.
• Telling machine owners
  This is the most complicated bit; it's a bit formal. If you see a way of simplifying it, without reducing the information presented to machine owners, make sure you suggest it!

  Log onto medusa, as dcs. Save a copy of the vulnerablity description (from the vendor, or from bugtraq, or from linux-security, or wherever) in ~dcs/Mail/security/something, where something is the next higher number available in the directory (this is an MH mail folder).

  Log onto medusa as nacs (or su, whatever). Run ~nacs/bin/update_sec_archive. Hope that mhonarc doesn't glitch again :). Go here, to make sure the message was added to the web archive as it should have been by update_sec_archive. If it wasn't, go fish.

  If it was... it's time to generate the "adrs" files. Go to nsc-1.nacs, and in /tmp (or a subdirectory) say:

  ~nacsstats/bin/mail-addr-list3 < good > good.adrs

  ~nacsstats/bin/mail-addr-list3 < bad > bad.adrs

  Then compose a "good.msg" and a "bad.msg". Here's an example "good.msg":

  Description: ufsrestore can be exploited by local users to gain illegitimate
  root access.
  
  Platform: Solaris 2.5 and 2.5.1
  
  Status: Stripping the set*id bits fixes the problem
  
  Authority: DCS
  
  UCI Resolution: We've stripped the set*id bits on ufsrestore and ufsdump
  on $host.  No further action is required.
  
  Details can be found at http://www.nacs.uci.edu/support/ddcs/security/archive/
  and looking for the subject "ufsrestore vulnerability".
  
  [This notice is a part of NACS' efforts to keep the campus informed of
  potential computer security liabilities.  Please send any questions or
  concerns to us at DCS@UCI.EDU]
  

  Usually "Authority" is something like "Sun Microsystems", and "Status" is like "a patch is available from sun". Type "$host" literally; this is replaced by the hostnames later.

  Here's an example "bad.msg":

  Description: ufsrestore can be exploited by local users to gain illegitimate
  root access.
  
  Platform: Solaris 2.5 and 2.5.1
  
  Status: Stripping the set*id bits fixes the problem
  
  Authority: DCS
  
  UCI Resolution: An automated process failed to correct the problem on $host.
  If you have a HIGH or REG contract with DCS, we'll be fixing this for you, and
  no further action is needed on your part.  If not, then you should make
  arrangements for this to be done.
  
  Details can be found at http://www.nacs.uci.edu/support/ddcs/security/archive/
  and looking for the subject "ufsrestore vulnerability".
  
  [This notice is a part of NACS' efforts to keep the campus informed of
  potential computer security liabilities.  Please send any questions or
  concerns to us at DCS@UCI.EDU]
  

  Now that you have good.adrs, good.msg, bad.adrs, and bad.msg, it's time to send the mail.

  First, double check to be sure you haven't done something silly, because a small mistake here makes us look bad in front of a lot of people.

  Once you're fairly confident everything looks ok... Go to nsc-1.nacs, and run

  • ~nacsstats/bin/bmail good.adrs "ufsrestore vulnerability fixed" good.msg
  • ~nacsstats/bin/bmail bad.adrs "ufsrestore vulnerability not fixed" bad.msg

  You're done.