SUPER WORM ANALYSIS MECHANISM

1
SUPER WORM ANALYSIS MECHANISM

• Prof. Jerry Breecher

2
MARKETING REQUIREMENTS DOCUMENT

• PRODUCT MOTIVATION
• This document describes the need for a product
  that will detect suspicious and foreign processes
  running on Super Computer Company Hardware.
  Recent events in the UNIX world have shown that
  undesirable elements can run amok when given
  unlimited processing power. SCC customers have
  expressed great concern that their machines may
  be attacked by such a mechanism.

3
MARKETING REQUIREMENTS DOCUMENT

• PRODUCT DESCRIPTION/REQUIREMENTS
• To meet this need, it is proposed that SCC
  Engineering undertake a project to produce SWAMI,
  the Super Worm Analysis MechanIsm.
• 1. SWAMI should be able to detect the presence of
  a foreign process before it has done serious
  damage to the SCC machines. The procedure for
  doing this is currently undefined and will be
  determined by engineering.
• 2. SWAMI should be a standalone package,
  requiring no other SCC software.
• 3. SWAMI should require no user interaction
  during normal operation only in the case of
  intruder detection should interaction be
  necessary.
• 4. Intruder detection should be signaled in an
  auditory and/or visual and/or sensual fashion.

4
MARKETING REQUIREMENTS DOCUMENT

• PRODUCT DESCRIPTION/REQUIREMENTS
• 5. The intruder must be detected before damage
  can occur.
• 6. Although SWAMI is continually monitoring, it
  is essential that it use less than 5 of the CPU
  on the machine less than 1 would be ideal.
• 7. The time from intruder detection to alert
  received must be less than 5 seconds.
• 8. The time from intruder detection to
  termination of intruder must be such that the
  intruder can do no damage.
• 9. The amount of memory/disk/other resources used
  must be ½ that of the competition.
• 10. The number of false alarms/month allowed is 0.

5
MARKETING REQUIREMENTS DOCUMENT

• COMPETITION
• The_Competition has recently introduced its TGIF
  system (The_Competition Guts Intruders Fast ).
  The_Competition customers have expressed
  satisfaction with the functionality (no intruders
  have been reported in the first three months of
  operation.) These same customers have not been
  happy with performance however hearsay evidence
  has it that TGIF can require up to 10 additional
  CPU power on a The_Competition system.
  The_Competition is reportedly planning a
  performance release to address customer concerns.

6
PROJECT PLAN

• DESCRIPTION OF PROJECT COSTS

DO NOT READ AHEAD UNTIL YOU HAVE COMPLETED THE
EXERCISE FOR THE MRD DO NOT READ AHEAD UNTIL YOU
HAVE COMPLETED THE EXERCISE FOR THE MRD
7
FUNCTIONAL SPECIFICATION

• FUNCTIONAL DESCRIPTION
• In order to keep monitoring activity to a
  minimum, the legality of a program is verified
  when a program is first executed. This is a
  one-time verification cost and was chosen over
  the more costly mechanism of scanning/verifying
  all processes at fixed time intervals.
• Legality of a program to run on a particular
  system is given at either link time or via a
  "legalize_executable" command. In other words,
  an executable becomes legal on a system either by
  virtue of having been linked on that system or by
  being imported and then "legalized" by an
  authorized individual.

8
FUNCTIONAL SPECIFICATION

• GURU
• GURU (Global Universal Resource Unit) is a
  distributed server, running on all machines of a
  system. It is responsible for
• Maintaining and protecting a 100-byte unique
  hardware number, common to all machines in the
  system.
• Producing a magic number that is placed in the
  program image file at link or "legalize_executable
  " time.
• Verifying that the magic number in a program
  image is OK.

9
FUNCTIONAL SPECIFICATION

• VARIOUS DETAILS
• Communication with GURU is via a pipe. Set up
  this pipe with GURU using open_pipe on the file
  gtsystemgtguru_pipe_file.
• When a machine comes on line within a system, a
  mechanism is provided which will synchronize the
  GURU programs running on each machine and
  guarantee that they all have the same hardware
  number.
• A system call, get_guru_hardware_number allows
  the GURU server to obtain the hardware number
  stored in the system. The Operating System
  guarantees that it really is GURU asking for this
  information.

10
FUNCTIONAL SPECIFICATION

• LEGALIZATION
• Program legalization occurs either at link time
  or at "legalize_executable" time. The steps used
  are as follows
• Either the linker or the legalize-pm program
  sends a pipe request to GURU using msg_send, with
  the "message" parameter containing
• The key word "LEGALIZEltnullgt".
• Creation time in ASCII format YY-MON-DDHHMMSSltn
  ullgt.
• The program name followed by a ltnullgt.
• The complete pathname of the directory, in which
  the executable file will be placed, followed by a
  ltnullgt.
• The linker or the legalize_executable program
  receives a reply back from GURU using
  msg_receive_reply, with the "message" parameter
  containing
• The 100 byte magic number that is to be placed in
  the program image file.

11
FUNCTIONAL SPECIFICATION

• VERIFICATION
• Program verification occurs at execution time.
  The steps to be followed include
• 1. The Operating System sends a request to GURU
  using msg_send, with the "message" parameter
  containing
• The key word "VERIFYltnullgt".
• Creation time in ASCII format YY-MON-DDHHMMSSltn
  ullgt.
• The program name followed by a ltnullgt.
• The complete pathname of the directory, in which
  the executable file is located, followed by a
  ltnullgt.
• The 100 byte magic number that was found in the
  program image file.
• 2. The system obtains an answer from GURU using
  msg_receive_reply, with the "message" parameter
  containing
• "MAGIC NUMBER VERIFIEDltnullgt" or "MAGIC NUMBER
  INVALIDltnullgt".

12
DESIGN SPECIFICATION

• DO NOT READ AHEAD UNTIL WE HAVE COMPLETED THE
  EXERCISE FOR THE FUNCTIONAL SPEC
• DO NOT READ AHEAD UNTIL WE HAVE COMPLETED THE
  EXERCISE FOR THE FUNCTIONAL SPEC

13
DESIGN SPECIFICATION

• DESIGN DESCRIPTION
• GURU
• (Global Universal Resource Unit) is a distributed
  server, running on all machine of a system. It
  is responsible for
• Maintaining and protecting a 100-byte unique
  hardware number, common to all machines in the
  system.
• Producing a magic number that is placed in the
  executable file at link or "legalize_executable"
  time.
• Verifying that the magic number in an executable
  is OK.

14
DESIGN SPECIFICATION

• LEGALIZATION AND VERIFICATION
• GURU receives requests using a msg_receive the
  parameters received were described in the
  functional spec.
• If the keyword is "LEGALIZE", then
• Multiply together the ASCII values of the
  creation_time, program name, and creation
  directory.
• Multiply the product just obtained with the
  100-byte hardware number to produce the magic
  number.
• Use a msg_send_reply to return the magic number.

15
DESIGN SPECIFICATION

• LEGALIZATION AND VERIFICATION
• GURU receives requests using a msg_receive the
  parameters received were described in the
  functional spec.
• If the keyword is "VERIFY", then
• Multiply together the ASCII values of the
  creation_time, program name, and creation
  directory.
• Multiply the product just obtained with the
  100-byte hardware number to produce the magic
  number.
• Compare the magic number produced here, with the
  magic number submitted by the requestor.
• Use n msg_send_reply to return the appropriate
  answer to the requestor.

16
DESIGN SPECIFICATION

• INITIALIZATION
• When GURU is initialized upon machine startup, it
  obtains the 100-byte hardware number using a
  get_guru_hardware_number. It opens pipes with
  the GURU incarnations on all the other machines
  of the system and broadcasts its 100-byte number.
  The other servers respond either with an "OK" or
  with a "WE'VE GOT A PROBLEM". In the latter
  case, the system administrator will get involved
  and sort everything out.