Unix SecurityAssessing 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: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

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