Unix Security Assessing vulnerabilities

Classifying vulnerability types Several models have been proposed to classify vulnerabilities in UNIX-type Oses E.g., M. Bishop’s “A Taxonomy of UNIX System and Network Vulnerabilities’’ (95) Stated goals of The Taxonomy: Description should be useful for the purpose of designing intrusion detection mechanisms; Techniques provided for finding vulnerabilities of each type; Techniques provided for mitigating their threat

Dimensions of taxonomy The taxonomy considered: Vulnerability class Time of introduction Exploitation domain Effect domain Minimum component number Source

Vulnerability class From Protection Analysis study: 1. Improper protection (initialization and enforcement) 1a. Improper choice of initial protection domain 1b. Improper isolation of implementation detail 1c. Improper protection 1d. Improper naming 1e. Improper de-allocation or deletion 2. Improper validation 3. Improper synchronization 3a. Improper indivisibility 3b. Improper sequencing 4. Improper choice of operand or operation

Time and Domains Time of introduction 1. Development 2. Maintenance 3. Operation Exploitation domain/Effect domain: Numbering indicates: 1. Nothing else is affected 2. Network sessions are affected 3. Hardware is affected 4. Network sessions and hardware are affected

Number of components and source Minimum number of components: Refers to the number of software modules (programs) that must be involved for the vulnerability to be exploited Directly impacts the complexity of monitoring for attacks that exploit the vulnerability Source: Where the vulnerability was discovered and published Affects how likely is that the vulnerability will be exploited, e.g. if automated scripts are available

Example: The Xterm vulnerability mknod foo p Creates a device (file) that implements FIFO xterm -lf foo Launches an xterm with foo as its log file mv foo junk Renames foo as junk ln -s /etc/passwd foo Creates symbolic link (alias) to system password file cat junk Opens the other end of a FIFO file, effectively creating a pipe from xterm log to stdout through /etc/passwd

Classifying the xterm vulnerability Vulnerability class: 1c, Improper change Time of introduction: 1, development Exploitation domain: 1, UID of xterm program Effect domain: 1, any protection domain Minimum number: 2, xterm process; another process to move file & link password file to name Source: Posted to USENET

Reading passwords Type: 1e. Improper de-allocation or deletion Introduction time: 1. Development Exploitation domain: 1, Group kmem protection domain Effect Domain: 1, Any protection domain Minimum number: 1, Process reading terminal buffer Source: M. Bishop, USENET posting

Detection and mitigation Improper choice of initial protection domain Tools such as tripwire can be used to create a database of system files and their access rights Difficult to manually evaluate against abstract policies since there is no formal access control structure in UNIX Requires computation of the access control closure for a particular user class

Detection and mitigation (2) Improper isolation of implementation detail Each software component that may affect the protection architecture must be analyzed to decide whether it implements checks at the correct location Example: The NIS used to implement checks in the clients to prevent attempts to add (e.g. privileged) accounts in the system. However, anyone could write a program to directly connect to the daemon and perform the addition of accounts. Here, it was improper to delegate the check to clients; the operation should be protected by the daemon.

Detection and mitigation (3) Improper change Assumptions about data consistency are not valid in practice: e.g., the xterm attack E.g. of pairs of system call sequences that expose to improper change flaws: accessopen give read/write access to protected file accessunlink delete system-critical file accesschroot remove file-system visibility restrictions creatchown improper change of ownership openrename move file to system location Techniques from software testing and/or pattern matching are required

Detection and mitigation (4) Improper name Name collision (Trojan horses) Same object, two names (and permission sets) Files (hard links in UNIX) Process IDs (re-use of ID after termination) Simple scanning detects issues of name collision and hard links For process ID re-use, it becomes imperative to insert checks in programs to detect the termination of any processes it communicates with

Detection and mitigation (5) Improper de-allocation/deletion Memory de-allocated but not cleaned/erased Allow for programs to read contents written by other processes Auxiliary structures not cleaned at deletion Denial-of-service attack (historic attack on the Process table) Use of de-allocated memory Software testing techniques are useful in detecting such problems

Improper validation Verify return values from system calls Verify validity of arguments Switch statement have default cases Perform range-checking Use functions that return error checking information whenever available

Detection and mitigation (7) Improper indivisibility Not properly checking locking mechanisms Time-Of-Check-To-Time-Of-Use issues (TOCTTOU) Improper choice of operand/operation Violation of modularity in design Manipulation of data in practice does not correspond to requirements