Software Security

Notes

• We have seen that failure to cleanse input can be a problem
• What are some other common errors?
• A buffer overflow
  • Occurs when we try to store more data then space has been allocated.
  • The attacker is able to put something bad into memory they should not have access to.
  • You don't have this problem because of how strings in c++ work
    • cin >> aString
    • The stream extraction operator will append new characters to the string
    • And the string will continually allocate more memory to hold these now characters.
  • But consider if you want to be "more careful" about what you read

    • aFile >> ch;
      while (aFile and ch  != delimiter) {
          aString = aString+ ch
          aFile >> ch;
      }

    • Again this is fine when working with c++ strings
  • But what if we went to c strings
    • These are just arrays of characters
    • And need to be preallocated

    • aFile >> ch;
      char buffer[100]
      
      int i {0};
      while (aFile and ch  != delimiter) {
          buffer[i] = ch;
          ++i;
          aFile >> ch;
      }

  • Why would I use a buffer instead of a string
    • c routines, hence many operating systems calls use these
    • See, for example open
    • So the implementation of streams in c++ must use these.
  • Buffer overflow is exceedingly common and a cause for many different attacks
• Memory Corruption
  • Buffer over is a special case of this
  • The programmer somehow writes to memory they should not.
  • For you, an array index out of bounds error
    • Small time, these are more likely to cause crashes
    • But they can be exploited
  • The pwnkit lab discusses this (no time, way too complex)
    • Most programs start with an array of arguments
    • int main(int argc, char * argv[])
    • argv[0] is usually the program name
    • The attacker in pwnkit uses the assumption that this is true to break the system.
• These two types of attacks are "easy" and hard to defeat
  • For example, in c++ use vectors not arrays
    • And use .at vs []
  • Always make sure your buffers are sufficient to hold your data
• Time of check vs time of use
  • An analogy
    • I pay for something with cash costing $100
    • I count five $20 bills out in front of the seller
    • The seller turns around to get the item
    • I swap a $1 for a $20 in the stack of counted bills while the seller is distracted
    • I hand the seller the modified stack of money
  • Take a look at the wikipedia page that discusses this.
  • If a programmer is not careful, this can happen
    • But unfortunately, this is a bit difficult to show.
• Race conditions
  • Occur when two or more entities are competing for a single resource
  • Consider getting in line to order at fast food
    • Or even better using the kiosk
    • Whoever completes their order first gets put into the system
    • and, we hope, gets put in the order queue first
  • Systems become non-deterministic when this happens
    • We don't know who will win the race
  • This is a common problem when we have multiple programs working together.
  • This type of program is hard to write and harder to debug
  • The Dirty COW exploit is an example of this.
    • A bug in the linux kernel
    • Two processes competed for access to chunk of memory
    • When the attacker process won the race, they would gain access to the system.
• Can these be fixed with a better language?
  • C is bad,
  • C++ is good, if used right
  • RUST/Python are better
  • We might be able to reduce buffer overflow, memory errors
  • But logic errors, especially related to concurrency will remain