Unix Security Assessing vulnerabilities
Classifying vulnerability types n Several models have been proposed to classify vulnerabilities in UNIX-type Oses n n E. g. , M. Bishop’s “A Taxonomy of UNIX System and Network Vulnerabilities’’ (95) Stated goals of The Taxonomy: n n n 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 n The taxonomy considered: n n n Vulnerability class Time of introduction Exploitation domain Effect domain Minimum component number Source
Vulnerability class n From Protection Analysis study: n 1. Improper protection (initialization and enforcement) n n n n 2. Improper validation 3. Improper synchronization n 1 a. Improper choice of initial protection domain 1 b. Improper isolation of implementation detail 1 c. Improper protection 1 d. Improper naming 1 e. Improper de-allocation or deletion 3 a. Improper indivisibility 3 b. Improper sequencing 4. Improper choice of operand or operation
Time and Domains n Time of introduction n n 1. Development 2. Maintenance 3. Operation Exploitation domain/Effect domain: Numbering indicates: n n 1. Nothing else is affected 2. Network sessions are affected 3. Hardware is affected 4. Network sessions and hardware affected
Number of components and source n Minimum number of components: Refers to the number of software modules (programs) that must be involved for the vulnerability to be exploited n n Directly impacts the complexity of monitoring for attacks that exploit the vulnerability Source: Where the vulnerability was discovered and published n Affects how likely is that the vulnerability will be exploited, e. g. if automated scripts are available
Example: The Xterm vulnerability n mknod foo p n n xterm -lf foo n n Renames foo as junk ln -s /etc/passwd foo n n Launches an xterm with foo as its log file mv foo junk n n Creates a device (file) that implements FIFO Creates symbolic link (alias) to system password file cat junk n Opens the other end of a FIFO file, effectively creating a pipe from xterm log to stdout through /etc/passwd
Classifying the xterm vulnerability n n n Vulnerability class: 1 c, 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: 1 e. Improper de-allocation or deletion n Introduction time: 1. Development n Exploitation domain: 1, Group kmem protection domain n Effect Domain: 1, Any protection domain n Minimum number: 1, Process reading terminal buffer n Source: M. Bishop, USENET posting n
Detection and mitigation n Improper choice of initial protection domain n n 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 n Requires computation of the access control closure for a particular user class
Detection and mitigation (2) n Improper isolation of implementation detail n Each software component that may affect the protection architecture must be analyzed to decide whether it implements checks at the correct location n 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) n Improper change n Assumptions about data consistency are not valid in practice: e. g. , the xterm attack n E. g. of pairs of system call sequences that expose to improper change flaws: access creat chown open give read/write access to protected file unlink delete system-critical file chroot remove file-system visibility restrictions improper change of ownership rename move file to system location Techniques from software testing and/or pattern matching are required
Detection and mitigation (4) n Improper name n n Name collision (Trojan horses) Same object, two names (and permission sets) n n 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) n Improper de-allocation/deletion n Memory de-allocated but not cleaned/erased n n Auxiliary structures not cleaned at deletion n Allow for programs to read contents written by other processes 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 n Verify validity of arguments n Switch statement have default cases n Perform range-checking n Use functions that return error checking information whenever available n
Detection and mitigation (7) n Improper indivisibility n n n Not properly checking locking mechanisms Time-Of-Check-To-Time-Of-Use issues (TOCTTOU) Improper choice of operand/operation n n Violation of modularity in design Manipulation of data in practice does not correspond to requirements
Скачать презентацию Unix Security Assessing vulnerabilities Classifying vulnerability types
e079e53d255ebbf8940a217f5abb6a9b.ppt