Unix Security

1. Unix Security Assessing vulnerabilities

2. 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

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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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.

12. 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:access open give read/write access to protected fileaccess unlink delete system-critical fileaccess chroot remove file-system visibility restrictionscreat chown improper change of ownershipopen rename move file to system location • Techniques from software testing and/or pattern matching are required

13. 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

14. 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

15. 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

16. 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