Unix SecurityClassifying vulnerability typesDimensions of taxonomyVulnerability classTime and DomainsNumber of components and sourceExample: The Xterm vulnerabilityClassifying the xterm vulnerabilityReading passwordsDetection and mitigationDetection and mitigation (2)Detection and mitigation (3)Detection and mitigation (4)Detection and mitigation (5)Improper validationDetection and mitigation (7)PowerPoint PresentationUnix SecurityAssessing vulnerabilitiesClassifying vulnerability typesSeveral models have been proposed to classify vulnerabilities in UNIX-type OsesE.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 threatDimensions of taxonomyThe taxonomy considered:Vulnerability classTime of introduction Exploitation domainEffect domainMinimum component numberSourceVulnerability classFrom Protection Analysis study:1. Improper protection (initialization and enforcement)1a. Improper choice of initial protection domain1b. Improper isolation of implementation detail1c. Improper protection1d. Improper naming1e. Improper de-allocation or deletion2. Improper validation3. Improper synchronization3a. Improper indivisibility3b. Improper sequencing4. Improper choice of operand or operationTime and DomainsTime of introduction1. Development2. Maintenance3. OperationExploitation domain/Effect domain: Numbering indicates:1. Nothing else is affected2. Network sessions are affected3. Hardware is affected4. Network sessions and hardware are affectedNumber of components and sourceMinimum number of components: Refers to the number of software modules (programs) that must be involved for the vulnerability to be exploitedDirectly impacts the complexity of monitoring for attacks that exploit the vulnerabilitySource: Where the vulnerability was discovered and publishedAffects how likely is that the vulnerability will be exploited, e.g. if automated scripts are availableExample: The Xterm vulnerabilitymknod foo pCreates a device (file) that implements FIFOxterm -lf fooLaunches an xterm with foo as its log filemv foo junkRenames foo as junkln -s /etc/passwd fooCreates symbolic link (alias) to system password filecat junkOpens the other end of a FIFO file, effectively creating a pipe from xterm log to stdout t hrough /etc/passwdClassifying the xterm vulnerabilityVulnerability class: 1c, Improper changeTime of introduction: 1, developmentExploitation domain: 1, UID of xterm programEffect domain: 1, any protection domainMinimum number: 2, xterm process; another process to move file & link password file to nameSource: Posted to USENETReading passwordsType: 1e. Improper de-allocation or deletionIntroduction time: 1. DevelopmentExploitation domain: 1, Group kmem protection domainEffect Domain: 1, Any protection domainMinimum number: 1, Process reading terminal bufferSource: M. Bishop, USENET postingDetection and mitigationImproper choice of initial protection domainTools such as tripwire can be used to create a database of system files and their access rightsDifficult to manually evaluate against abstract policies since there is no formal access control structure in UNIXRequires computation of the access control closure for a particular user classDetection and mitigation (2)Improper isolation of implementation detailEach software component that may affect the protection architecture must be analyzed to decide whether it implements checks at the correct locationExample: 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 changeAssumptions about data consistency are not valid in practice: e.g., the xterm attackE.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 locationTechniques from software testing and/or pattern matching are requiredDetection and mitigation (4)Improper nameName 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 linksFor process ID re-use, it becomes imperative to insert checks in programs to detect the termination of any processes it communicates withDetection and mitigation (5)Improper de-allocation/deletionMemory de-allocated but not cleaned/erasedAllow for programs to read contents written by other processesAuxiliary structures not cleaned at deletionDenial-of-service attack (historic attack on the Process table)Use of de-allocated memorySoftware testing techniques are useful in detecting such problemsImproper validationVerify return values from system callsVerify validity of argumentsSwitch statement have default casesPerform range-checkingUse functions that return error checking information whenever availableDetection and mitigation (7)Improper indivisibility Not properly checking locking mechanismsTime-Of-Check-To-Time-Of-Use issues (TOCTTOU)Improper choice of operand/operationViolation of modularity in designManipulation of data in practice does not correspond to
View Full Document