Unix SecurityUse 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–314. http://www.usenix.org/events/sec05/tech/borisov.html

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(N2/3), using a database of length O(N2/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: P0, Ciphertext C0

Which key k was used to encrypt? Notation: C0 = S(k, P0)

Use an arbitrary reduction function R() taking ciphertext to keyspace

Compute chains as ki S(ki, P0) = Ci R(Ci) = ki +1

Combining the two steps into a single function f() ki f(ki) = ki+1 f(ki+1) = ki+2 …

Database construction and details Compute m chains, each of length t Create a database with entries <kbi, kei> During the online phase

Obtain C Compute k = R(C) Construct t-length chain

k f(k) = k1 f(k1) = k2 … If key used to create C was examined during the creation of

the database, one element in the online chain matches some kei in the database From kbi, 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 240 words, or 16 TB of data

A time-memory trade-off requires only 227 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