Lecture 7: Software vulnerabilities and introduction to viruses

1
Lecture 7 Software vulnerabilities and
introduction to viruses

• We will cover
• security vulnerabilities that come from common
  software errors
• terminology of malicious code
• typical virus structure and operation
• Reading - Pfleeger, chapter 3

2
Buffer/array overflows

• With normal variables, including record
  structures, you have to give the name of the
  variable (or record variable and field) in order
  to identify what data item to access. This means
  that the compiler can assign numerical addresses
  to these data items (even if they are relative to
  the start of the program code) - loading and
  linking still leaves these data items having
  specific addresses in memory.

3

• Problem with buffers and arrays is that unlike
  other data elements they can be accessed by
  computing an offset value from the start of the
  buffer/array - an expression is evaluated (may
  just be evaluation of index variable value) to
  give offset
• Problem is that it is easy for the evaluation to
  result in an offset value that is outside the
  range of the buffer/array
• This usually occurs because a process attempts to
  put more values in an array than there are array
  locations

4

• Some programming languages have run-time
  environments defined which will automatically
  check and catch any attempt to access array
  elements outside of the array. But some
  programming languages do not have this built in,
  and it is left to the programmer to check it.
  Checking array bounds is quite expensive and
  often seen as a waste of time and thus some
  programmers may not do it.
• If bounds checking is not done, then it may be
  possible for a user to do something unusual in
  order to access values outside the bounds of the
  array array overflow

5

• An array may be
• 1. preceded/followed in memory by other data
  items that belong to the program that is running
  - in which case those data items may be accessed
  directly - effecting that program - BUT if OS
  buffer that is overflowed is in an OS program
  then this might be OS data
• 2. preceded/followed in memory by program code of
  program that is running - in which case program
  code can be read and altered directly - could
  change execution of the program - again if it is
  an OS program then this has serious implications
  as the user could insert as values into memory,
  instruction code values that will be executed as
  part of OS program and that code will execute
  with high OS privileges

6

• 3. preceded/followed by code or data of some
  other program in memory - again it might be some
  other user application that might have data items
  or code changed or it might be some OS program
  that has data/code changed - most modern OS
  should prevent this access, but not all do this
  as well as they should
• the above is also true for stacks - stack sizes
  are dynamic and hence stack locations relative to
  the top of the stack change - stack access is
  frequently computed as an offset relative to top
  of stack (held in a stack pointer), but as with
  arrays the offset values if not checked may
  permit stack overflow i.e. allow access to other
  items in memory beyond stack that attacker might
  then read/change, etc.

7
Incomplete mediation

• Code to process inputs expect inputs to meet
  certain requirements e.g. be a date, or be an
  integer
• if input does not match those requirements then
  program might crash or malfunction in
  unpredictable ways or ways that are exploitable
  by an attacker
• hence we use validation to check appropriateness
  of values input by users or restrict range of
  values that can be input (e.g. drop down lists) -
  this is called mediation of the input

8

• However, sometimes programmers
• fail to validate input data at all when it is
  necessary, or
• even if they perform some check or restrict range
  of values user can input, after
  validation/restricted choice the input values are
  left accessible for user to alter
• thus mediation is incomplete - program may trust
  inputs even though inputs may be incorrect
• Either way data may interfere with proper
  execution of program - in a way that might then
  be exploited

9
Time-of-check to time-of-use error

• to access an item on the computer system it is
  first necessary to make a request to the OS to
  access that item - the OS needs to
• 1. check that the requesting program has the
  permissions to access that item and in the way
  requested
• 2. grant access - give direct access to item
• problem is that there may be a delay between
  checking the access permissions and granting
  access to item during which the access request
  may itself be changed by the requesting program
  if the OS does not prevent this

10

• For example - user program makes requests for
  access by filling in values in a data structure
  before calling OS
• assume that the OS uses the access request data
  structure that was filled in by the user program,
  as the record of item to be accessed
• while OS is checking access rights, the user
  program may be able to change name of item in the
  access request data structure so that when OS
  then grants access, access permission would have
  been given to an entirely different item from
  that initially requested and that OS thinks it
  has granted access to
• the checking and granting/denying of access
  rights should be implemented as an atomic action

11
Backdoor/trapdoor

• backdoors are entirely appropriate in code during
  software testing and development
• source for inputs and sink for outputs of unit
  would normally be other code in final program or
  the user of the program but even then still
  mediated by other program code
• However in unit testing the unit is being tested
  in isolation, thus it must get test inputs and
  put outputs for tester to check somewhere that is
  specifically set up for testing purposes - code
  that gets test inputs and outputs test results is
  test driver code. This test driver code is
  incorporated into code for unit being tested.

12

• debugging code likewise may accept values
  directly and output values in a way different
  from normal I/O of program
• So test driver code and debugging code is code in
  unit that will accept input values and output
  values (including hidden intermediate values) via
  route that is different from that which code uses
  when unit will be running normally (or make
  accessible to change values that are not
  specified as subject to outside change)
• developer may invoke test driver code or
  debugging code by input of special control
  sequences, or simply using calls to
  driver/debugging methods of code interface - but
  the methods do not form part of the specification
  for program

13

• Of course problem is that
• 1. backdoors are not always removed by
  programmers when all testing/debugging is
  completed - not just laziness, often it is not
  clear when development has finished and company
  may want to continue to develop current release
  version of the program (to release patches later)
  and so does not want to remove the backdoors
• 2. such backdoors/trapdoors allow direct access
  to operation of code of program that may allow
  attacker to subvert proper operation of program
• so backdoors allow a way in - if you can find out
  where and how to access them and what they do

14
Malicious code - terminology

• Malicious code code that has undesired effects,
  caused by an agent intent on damage
• agent writer or distributor of program
• virus program that can pass on malicious code
  to other programs by modifying them (infection)
• Trojan horse code has an advertised effect and
  a hidden malicious effect
• Trojan horse may be a stand-alone program that
  only has malicious effects that just disguises
  itself as something else that you want to execute
  e.g. an e-mail attachment that uses a name like
  good-pics.jpg .exe so
  that the .exe part is not seen in a normal
  width file listing, but if you open the file, the
  file will execute!!

15

• logic bomb (and time bomb) code that awaits
  some specific condition to occur (or time to be
  reached) before it initiates its malicious
  effect.
• worm stand-alone program that replicates itself
  - usually across networks
• Backdoor/trapdoor entry point to program code
  that does not form part of specification of
  program and hidden from user
• Although already discussed sometimes a backdoor
  is set up deliberately for later exploitation by
  an attacker e.g. By a trojan horse program and in
  such cases is malicious

16
File infector virus

• File infector virus may be -
• executable - attaches and runs whenever the host
  executable file is run - classic virus - we will
  look mostly at this type
• interpreted - incorporated into a file as a macro
  or script - virus is interpreted rather than
  executed directly - often simply called document
  or macro viruses

17
Virus placement strategies

• Virus can be copied into infected file at 3
  locations
• 1. prepended to a file - most common because
  execution sequence will start at beginning of
  file (as default) and virus can then gain control
  as soon as host program is run
• 2. appended to file - less common - easy to do,
  but it will require insertion of a jump
  instruction to divert execution of code from host
  program code proper to virus code
• 3. integrated with code of host program -
  requires detailed knowledge by virus writer of
  format of file that is being infected to know
  where best to insert virus code

18
Virus execution strategies

• by becoming part of host code - executes when
  host runs
• by replacing host code on disk - file system
  points to file on disk, but now it points to
  virus program which runs instead of host program
• by changing file system structures so that they
  now point to location of virus as the location of
  target file, not the real location of masqueraded
  file
• by changing program invocation sequence to invoke
  virus rather than host code/masqueraded code e.g
  insert into vector table to redirect interrupt
  calls to service routines, etc.
• by placing code in host code to spawn virus
  program as a child process

19
Virus hiding strategies

• Stealth virus - attempts to conceal infection of
  files e.g. 2 methods
• 1. the additional code of the virus changes size
  of a file and the last modification date, so a
  stealth virus may change directory entries of
  file to keep values in directory the same as they
  should be or may intercept calls to read the
  directory structure and report back the values
  that should be there.
• 2. Virus can compress the host file by enough so
  that overall size has not changed - it just means
  that virus will have to uncompress any compressed
  part of host file before host program runs - but
  this happens in memory not on disk and is thus
  not seen by file system

20
Virus signatures

• a virus is just a program - thus it has a set of
  instructions and data - to achieve its effect the
  instructions and data cannot be randomly ordered,
  but must be ordered such that the virus can carry
  out its effect
• this means that all viruses have a signature - a
  pattern of bits which is unique to that
  particular virus.

21
Polymorphic virus

• 2 ways in which a virus can copy itself
• using an identical copy of itself - a static
  virus
• using a copy that has been modified in some so
  that the copy has a different signature to parent
  virus - a polymorphic virus (polymorph poly -
  many, morph - shape)
• polymorphic virus may be a simple polymorphic
  virus or an encrypting polymorphic virus
• polymorphic virus changes the signature (pattern
  of bits) of the copy of itself it is using to
  infect another file by changing the code
  structure of the copy

22
Signature morphing strategies

• 1. re-order the code sequence e.g.
• a) it can jumble up textual order of code in
  memory, but preserve execution order by inserting
  unconditional jumps into code to make sure one
  piece of code is executed after another
  regardless of the textual order of the code
• b) it can re-order instructions which do not have
  dependencies between them e.g. many arithmetic
  and logical operations are commutative or
  associative and thus it does not matter if
  performing AB whether you load A first into a
  register and then add B or load B into a register
  and then add A or load A into one register and B
  into another and then add both together, etc.

23

• 2. insert instructions that have no effect (e.g.
  add 0 to a location or use the NOP instruction)
  but still alters overall pattern of bits
• 3. Change the registers used in the various
  operations - processors have several data
  registers and in one incarnation of the virus
  code one specific register is used in a portion
  of the code, but the next time the code is copied
  a different register is used
• 4. Interleave virus code with some other
  innocuous algorithm e.g. a sort - of course the
  interleaved algorithm is never executed but it
  still changes the signature

24
Encrypting Polymorphic virus

• an encrypting virus encrypts part of itself using
  a key (usually random) - it has an encrypted part
  (most of the virus code), an decryption algorithm
  part (this remains unencrypted) and a decryption
  key part
• when invoked it first uses unencrypted decryption
  code to decrypt rest of virus using decryption
  key, it can then execute as a normal virus

25

• when it creates a new copy of itself it will
  generate a new random key, encrypt the part of
  the copy that needs to be encrypted using that
  key, and store decryption key (could be same as
  encryption key of course) in virus copy
• thus by using a new random key each time the
  signature of the key and the encrypted part of
  virus will be different each time - but
  decryption part does not change - so that might
  provide a constant signature
• of course you could use normal polymorphic
  techniques on unencrypted decryption code of
  virus to make it more difficult

26
Generic virus structure

• beginVirus // lt..............gt optional
• Infection section
• ltdecrypt virus code using keygt
• if spread-condition met then
• find targets to be infected
• ltmutate virus code for copyinggt
• ltencrypt virus copy with random keygt
• add/insert mutated/encrypted copy of virus
  into target
• alter target to execute virus when initiated
• ltstealth code to hide modificationgt
• Damage section
• if trigger condition is met then
• execute damage code
• else goto beginning of host program code
• endvirus
• ltdecryption keygt

27
Typical virus life-cycle

• Creation
• Release
• Replication - as virus is copied from target to
  target (file/system,etc)
• Activation - time/event triggered or simply time
  to have significant impact
• Discovery - detected and documented - virus
  effect/replication strategy/signature/trace
  evidence identified
• Assimilation - anti-virus software companies
  incorporate signature, trace evidence, etc, into
  programs/updates
• Eradication or sanitation - anti-virus software
  with signature widely available