Unix Security Use of a taxonomy of security faults By T. Aslam, I. Krsul, and E. H. Spafford

The approach The objective of this work is to facilitate discovery of vulnerabilities by non-security experts, using pattern-oriented approach Making vulnerability analysis more procedural The paper first considers classes of software errors that have been identified by software testing methods: Boundary condition errors, input validation errors, access validation errors, failure to handle exceptional condition errors, environment errors, synchronization errors, configuration errors

Boundary condition errors Boundary Value Analysis (BVA) uses test cases to verify the functionality of software modules. It ensures that test cases explore whether modules correctly implement functionality in boundary conditions. For instance, suppose a branch is taken if a variable x is less than a constant t. It is important to check what happens when x == t and when x differs from t by a small amount. This can find path selection errors. An important technique important in this case is Path Analysis. Path analysis is based on the observation that it is often easy to establish that a program correctly implements a particular functionality along a fixed path (I.e., for specific branch selection choices)

Input/Access validation errors A module (function, component) uses an input without verifying that it conforms to the expected format. As a result, the component (or an inter- dependent element) may fail as a result Path analysis can be effectively used to validate that a program does not fail on improper input Access validation errors result from incorrectly specified condition constructs. Branch and Relational Operator (BRO) testing techniques can facilitate the design of test cases that identify access validation errors

Exceptional conditions/environmental errors Failure to handle exceptional conditions is a common source of vulnerabilities For instance, failure to check return codes for memory/IO operations Often detectable through source code review Environment errors are vulnerabilities that only manifest themselves in specific environmental conditions (OS-dependent, configuration-dependent) E.g.: Integer overflow/underflow. Mutation testing (which involves creating erroneous variants of the program to ensure that a test set is sufficiently comprehensive) can facilitate the discovery of such errors. Similarly, path analysis can ensure that all possible categories of inputs leading to modification of program behavior are examined

Synchronization errors Introduced because of the existence of a time window between two operations. Such operations should occur in a specified order, or as an atomic unit Another process may intervene between the two operations. A classical example is a gap between a privilege access check and a file access. These errors are commonly known as race conditions Assigned reading: N. Borisov, R. Johnson, N. Sastry, D. Wagner. Fixing Races for Fun and Profit: How to abuse atime. Proc. 14th USENIX Security Symposium, pp. 303–

Configuration errors Faults that are introduced during the maintenance phase of the software life-cycle Software is deployed with configuration options that violate the environment’s security policies or is ported to new environments that were not contemplated during development Differ from environmental errors in that the latter are introduced during development phase, and refer to environmental conditions that should have been anticipated by developers (e.g., a deployment scenario that was envisioned for the component)

Fault classification scheme Coding Faults Synchronization errors Condition validation errors Emergent Faults Configuration errors Environmental faults

Finer-grained classification Synchronization Time window Improper serialization Configuration errors Installation location Setup parameters Incorrect permissions Environmental faults Condition validation Types of conditions Checking limits Checking access rights Input validation Origin validation Errors made Missing check Missing predicate (sub- case of a check) Incorrectly formed check leads to predicates being ignored

Study questions How does the fault classification scheme of M. Bishop relates to that of Aslam et.al.? For each fault type in Aslam et.al., seek to classify it in Bishop’s scheme. Does it fit into a single or multiple categories of Bishop’s? Is any of Bishop’s categories a refinement of Aslam et.al.’s Is any of Aslam et.al.’s a refinement of Bishop’s?

Time-memory tradeoffs Applications to password-breaking and cryptanalysis

Secure storage Passwords and cryptographic keys are often stored in file systems for convenience of access Passwords are hashed and/or encrypted and verified during login Keys are “wrapped” (a special encryption operation) using passwords Such values become vulnerable to dictionary attacks Online attacks recover the hashed/wrapped value and try all entries of password dictionary against it Offline attacks pre-compute large databases and perform a lookup against these values Time-memory trade-offs try to find an optimal balance between database pre-computation and online guessing The use of long salt values can make both offline and time- memory trade-off attacks less efficient than online attacks

Time-memory trade-off Compute enough information in a database to allow for faster online attacks Example: Without pre-computation and auxiliary databases, an online dictionary attack requires O(N) steps, where N is the size of the dictionary Time-memory trade-offs can cut the online cost to O(N 2/3 ), using a database of length O(N 2/3 ), at the expense of pre-computation

Example: Hellman method Cryptanalysis problem: Plaintext known in advance (same for many attacks) Ciphertext available at beginning of online phase of attack Find the key used to encrypt Example: password systems If the key-space is exhaustible, one can compute all possible ciphertexts in advance Iterate over keys in some chained fashion Save only the first and last results of the computation chain During the online attack, the availability of the chain begin/end points can reduce the length of the search space for keys Why not save all? Database would be too long

Details Plaintext: P 0, Ciphertext C 0 Which key k was used to encrypt? Notation: C 0 = S(k, P 0 ) Use an arbitrary reduction function R() taking ciphertext to keyspace Compute chains as k i  S(k i, P 0 ) = C i  R(C i ) = k i +1 Combining the two steps into a single function f() k i  f(k i ) = k i+1  f(k i+1 ) = k i+2  …

Database construction and details Compute m chains, each of length t Create a database with entries During the online phase Obtain C Compute k = R(C) Construct t-length chain k  f(k) = k 1  f(k 1 ) = k 2  … If key used to create C was examined during the creation of the database, one element in the online chain matches some ke i in the database From kb i, redo chain computation until k found The preceding element in this chain is the key for C

Characteristics of attack Many windows applications use 40-bit keys A straightforward attack requires at least 2 40 words, or 16 TB of data A time-memory trade-off requires only 2 27 words, or 2GB of data. Larger databases could be used to result in the best I/O to computation trade-off Such databases will typically not be comprehensive Performance depends on strategy to limit the number of false positives during online step Using multiple tables with different reduction functions at each step in the chain results in substantial improvements