ATAXONOMY OF SECURITY FAULTS IN THE

A Thesis

Submitted to the Faculty

of

Purdue University

by

Taimur Aslam

In Partial Fulllment of the

Requirements for the Degree

of

Master of Science August

ii

This thesis is dedicated to my parents

iii

ACKNOWLEDGMENTS

Iwould like to thank my thesis advisor Dr Eugene Spaord for guiding me through

my reaserch Dr Spaord provided me the insight to tackle dierent problems read

several drafts of the thesis and made invaluable comments I also thank him for b eing

so patient and willing to work with myoddschedule I also thank my committee

memb ers Dr AdityaMathur Dr Samuel Wagsta Dr Michal Young Dr William

Gorman provided invaluable feedbacktoimprove the format of this thesis

I am greatly indebted to myparents for their supp ort and encouragementover

the years I would not have b een able to make it this far without their supp ort I

am also grateful to my sister for her supp ort in so many dierentendeavors and for

b eing a great friend

I thank Dan Schikore Mark Crosbie Steve Lo din and Muhammad Tariq who

pro ofread manuscripts of my thesis and made invaluable comments Thanks to all my

friends and everyb o dy in the COAST lab who provided much needed supp ort and

made sure that I maintained my sanity ThankstoFrank Wang for implementing the

frontend to the prototyp e

This acknowledgementwould not b e complete without mentioning Sadaf and some

vealways b een an inspiration to me very sp ecial p eople who ha

This work was supp orted in part by gifts from Sun Microsystems Bell Northern

Research and Hughes Research Lab oratories equipment loaned to the COAST group

by the US Air Force and a contract with Trident Data Systems This supp ort is

gratefully acknowledged

THIS PAGE IS INTENTIONALLY LEFT BLANK

iv

TABLE OF CONTENTS

Page

LIST OF TABLES vii

LIST OF FIGURES viii

ABSTRACT ix

An Overview of Software Testing Metho ds

Provable Security and Formal Metho ds

SecurityTesting

Applications of Fault Categories

Organization of the Thesis

RELATED WORK

Protection Analysis Pro ject

RISOS Pro ject

Flaw Hyp othesis Metho dology

Case Study Penetration Analysis of the

Software Fault Studies

Fault Categories

Errors of T X

E

ATaxonomy of Computer Program SecurityFlaws

yFault Classication Schemes Comparison of Securit

ATAXONOMY OF SECURITY FAULTS IN THE UNIX OPERATING

SYSTEM

ATaxonomy of SecurityFaults

Conguration Errors

Examples

Synchronization Errors

Example

Condition Validation Errors

v

Page

Examples

EnvironmentFaults

Example

Selection Criteria

DESIGN OF THE VULNERABILITY DATABASE

Motivation

Entity Relation Mo del

EntityAttributes

Entity Relation Diagram

EntityIntegrity Constraints

Referential Integrity Constraints

Op eration on the Relations

Requirements Analysis

Design Issues

Database Kernel

Representation of Relations

Vulnerability Database Interface

terface In

Integrity Constraints

EntityIntegrity Constraints

Referential Integrity Constraints

Template Representation

Data Sources

Requirements Analysis

Design Issues

Database Kernel

Representation of Relations

Vulnerability Database Interface

Integrity Constraints

EntityIntegrity Constraints

Referential Integrity Constraints

Template Representation

Data Sources

SECURITY FAULT DETECTION TECHNIQUES

Static Analysis

Symbolic Testing

Path Analysis and Testing

vi

Page

Functional Testing

Syntax Testing

Mutation Testing

Condition Validation Errors

Boundary Condition Errors

Input Validation Errors

Access RightValidation Errors

Origin Validation Errors

Failure to Handle Exceptional Conditions

Environment Errors

Synchronization Faults

Conguration Errors

Summary

CONCLUSIONS AND FUTURE WORK

BIBLIOGRAPHY

APPENDICES

App endix A Description of Software Fault Studies

App endix B ATaxonomyofUnixVulnerabilities

vii

LIST OF TABLES

Table Page

Percentage of Errors Detected

Fault Categories by Rub ey

Fault Categories byWeiss

Comparative Results byPotier

Bug Statistics by Beizer

VulnerabilityEntityAttributes

Op erating System EntityAttributes

PatchInfoAttributes

Vulnerability Database Interface Functions

Op erations on Relations

Vulnerability Database Interface Functions

Comparison of Dierent Software Testing Metho ds

App endix

Table

viii

LIST OF FIGURES

Figure Page

A Conventional TaxonomyofSoftware Mo deling and Analysis Techniques

Eort vs Testing Metho ds

Relationship b etween Testing Metho ds and the Design Pro cess

TaxonomyofFaults

Selection Criteria for Fault Classication

Entity Relation Diagram

Referential Integrity Constraints

Vulnerability Database

Vulnerability Database Commands Screen

Function Interface

Help Window

Vulnerability Database

Vulnerability Database Commands Screen

Function Interface

Help Window

App endix Figure

ix

ABSTRACT

Taimur Aslam MS Purdue University August A Taxonomy of SecurityFaults

in the Unix Op erating System Ma jor Professor Eugene H Spaord

Security in computer systems is imp ortant to ensure reliable op eration and protect

the integrity of stored information Faults in the implementation can b e exploited to

breach security and p enetrate an op erating system These faults must b e identied

detected and corrected to ensure reliability and safeguard against denial of service

unauthorized mo dication of data or disclosure of information

We dene a classication of security faults in the Unix op erating system Westate

the criteria used to categorize the faults and present examples of the dierentfault

typ es

We present the design and implementation details of a database to store vulner

ability information collected from dierent sources The data is organized according

to our fault categories The information in the database can b e applied in static

audit analysis of systems intrusion detection and fault detection We also identify

and describ e software testing metho ds that should b e eective in detecting dierent

faults in our classication scheme

Security is dened relativetoapolicyandinvolves the protection of resources from

accidental or malicious disclosure mo dication or destruction web Computer

security can b e broadly categorized as

Physical security Physical security is the protection of computer facilities against

physical threats and environmental hazards It involves the use of lo cks identi

cation badges guards p ersonnel clearances and other administrative measures

to control the ability to approach communicate with or otherwise make use of

any material or comp onent of a data pro cessing system A

Information security Information security is the protection of data against acci

dental or unauthorized destruction mo dication or disclosure It involves b oth

physical security measures and controlled access techniques A

Interest in stemmed from protecting information related to

matters of national security and grew as computers were used to store medical and

nancial records of individuals and proprietary information for business organizations

Zwa

The security of a computer system is dened by security requirements and is

implemented using a security p olicy The requirements vary according to the level

of security desired Computer systems op erate with implicit trust the reliabilityof

a computer system dep ends on the reliability of its comp onents The securityofa

computer system thus involves security of its hardware and software comp onents

The critical role played by op erating systems in the op eration of computer systems

mak es them prime targets for malicious attacks An op erating system is p enetrated

if an unauthorized user gains access to the system or if an authorized user causes a

security breachby exploiting a aw in the source co de A total system penetration

o ccurs when an unprivileged user gains the ability to execute privileged commands

H A p enetration of a system can lead to one or more of the following conse

quences Den BS Lin

Denial of service Users may b e denied access to legitimate services

Degradation of p erformance Performance can b e so p o or that the system is

not usable

Disclosure of information A user gains unauthorized access to protected infor

mation

Mo dication of data A user mo dies information in an unauthorized manner

Security breaches result from op erational faults co ding faults or environment

faults Op erational faults consist of conguration errors and p olicy errors Co ding

faults include programming logic errors faults of ommision and faults of commision

Environment faults o ccur when do not pay cient attention to the

execution environment These faults include errors that result from limitations of

the op erational environment and errors intro duced when some functional mo dules

op erate in an unexp ected manner

To ensure the reliable op eration of a computer system the implementation should

conform to the security requirements and should not contain any vulnerabilities

faults that may b e exploited to breach securityFaults intro duced during software de

velopment can b e exp osed by software testing techniques Faults can b e prevented in

software by using formal metho ds of verication at each stage of development These

two asp ects of developing reliable software are discussed in the following sections

An Overview of Software Testing Metho ds

The classic software engineering lifecycle paradigm for software engineering also

known as the waterfall mo del is a sequential approach to the software development

pro cess The pro cess b egins at the system level and progresses through requirements

analysis design co ding testing and maintenance phases Pre GJM These steps

may not b e followed in the sp ecied order and some may b e omitted The phases of

development are briey describ ed b elow

Systems engineering and analysis Often the software b eing develop ed is part of

a larger system Systems engineering establishes the requirements for all the

dierent system comp onents and denes how the software must interface with

other comp onents

Requirements analysis During this phase requirementsgathering is fo cused on the

software b eing develop ed and p erformance and interfacing requirements for soft

ware are dened During requirements analysis a requirements specication

document is develop ed that describ es what the requirements phase has accom

plished GJM The requirements sp ecications must b e stated in a precise

complete consistent and understandable manner This clarity ensures that the

requirements sp ecications do cument encompasses all the exp ectations of the

users and enables designers to develop software that meets the requirements

IEE GJM During requirements analysis a functional specications doc

ument may also b e pro duced that describ es how the system will p erform the

intended task IEE

Design Software design fo cuses on four attributes of the program data structures

software architecture pro cedural detail and interface characterization Pre

The design phase results in a design specications document that contains a

description of the system architecture a description of what each mo dule in

the system is intended to do and the relationships among mo dules GJM

During this phase the design pro cess is do cumented and is often translated in

a representation that can b e assessed for quality

Co ding During the co ding phase the design is translated using one or more appro

priate programming languages

T esting A fault is induced by an error a mistakebya human and mayleadto

failure IEE During the testing phase the fo cus is on nding faults in the

software that mayhavebeenintro duced during the design or co ding phases

Maintenance After the software has b een develop ed and released it may undergo

changes to adapt to dierentenvironments and errors maybeintroducedinthe

pro cess Software maintenance reapplies each of the preceding lifecycle steps

to an existing program

The time sp ent in the testing phase is often dep endent on the pro ject Pressman

Pre and Ghezzi GJM rep ort that for typical pro jects ab out of the total

development time is sp ent in testing and debugging According to Myers Myethe

maintenance and testing costs for typical installations of IBM OS exceeded

of the total cost

The ob jective of the testing phase is to discover anyfaultsthatmayhavebeen

intro duced during the co ding or design phase Although it is referred to as the testing

phase fault detection is not restricted to conventional testing metho ds and anyfault

detection technique may b e employed

Fault detection techniques can b e classied as dynamic analysis or static analy

sis Dynamic analysis techniques require the execution of the program b eing tested

and most conventional testing metho ds b elong to this category YT Static anal

ysis consists of co de walkthroughs and insp ection of requirements and sp ecication

do cuments to nd aws in the implementation Figure from Howa Howb

illustrates the dichotomy of the analysis techniques

Given a program P and sp ecications S it is undecidable to determine if P con

forms to S YT The presence of faults is generally an undecidable prop erty

Thus it is not even theoretically p ossible to devise a fault detection technique that

is applicable to arbitrary programs YT Every practical technique incorp orates a

compromise b etween accuracy and eort Figure adapted from YT shows the

relationship b etween eort exp ended and dierenttyp es of testing metho ds

Static Dynamic

Functional testing Informal checklists Requirements Testing by classes of Formal modeling input data Testing by classes of output data

Design Static analysis of design Design-based testing documents

General information Structural testing Programs Static error analysis Expression testing

Symbolic execution Data-flow testing

Figure AConventional Taxonomy of Software Mo deling and Analysis

Techniques

Exhaustive testing

Time

Path coverage

Infinite Effort

Mutation Threshold of tractability testing

Branch testing

Node testing

Figure Eort vs Testing Metho ds

The ob jective of software testing is not to show that a given program is free from

faults but to demonstrate their presence Mye Exhaustive testing of a program

would require innite eort and time to nd all the faults in a program As a com

promise b etween time and eort conventional testing metho ds rely on an adequacy

criteria to determine that adequate testing has b een done and the test data b eing used

is adequate A test data set is adequate if the program under test runs successfully

on the data set and all incorrect programs run incorrectly DMMP

Several techniques for measuring the adequacy of test data have b een prop osed

Path testing asso ciates the adequacy of test data with the traversal of a subset of

all paths through the program under test CPRZ Mutation testing is another

metho d for determining the adequacy of test data and is based on inducing faults in

the program under test DMMP

Another metho d of classifying dynamic fault detection techniques is as

Functional testing In functional blackbox testing the internal structure and b e

havior of the program is not considered The ob jective is to nd out solely when

the inputoutput b ehavior of a program do es not agree with its sp ecications

DMMP

Structural testing In this approach the structure of the program is examined and

test cases are derived from the programs logic Structural testing is also known

as white b ox testing DMMP

Software testing is further rened into several categories byMyers Mye as de

scrib ed b elow Fig from Mye illustrates the relationship b etween dierent

typ es of testing metho ds and their relationship to the design pro cess

Unit testing Unit testing is a white b ox oriented approach and fo cuses verication

eorts on a p er mo dule basis It uses a detailed design description to exercise

imp ortant control paths within the mo dule b oundaries

Integration testing Integration testing is used to uncover interfacing errors b etween

unittested mo dules

External testing External testing is the verication of the external system functions

as stated in the system sp ecications

System testing System testing attempts to fully verify the complete functionality

of the system System testing is a verication pro cess when it is done in a

simulated environment it is a validation pro cess when it is p erformed in a live

environment

Acceptance testing Acceptance testing is the validation of the system or program

according to the users requirements

Installation testing Installation testing is the validation of each particular installa

tion of the system with the intent of discovering any errors made while installing the system

Requirements

Objectives

Specifications

System Architecture

Program Structure

Module Specifications

Module Logic

Module Test

Integration Test

Function Test

System Test

Acceptance Test

Installation Test

Figure Relationship b etween Testing Metho ds and the Design Pro cess

Provable Security and Formal Metho ds

Software testing techniques can only establish the presence of faults not their

absence Mye Formal metho ds of verication are used to ensure that faults are

not intro duced during dierent stages of development and the implementation is

formally proven to conform to the requirements and sp ecications The applicability

of formal metho ds has b een mostly restricted to proving small sections of programs

to make the pro cess tractable Hall in his intro duction to formal metho ds Hal

states

Formal metho ds are controversial Their advo cates claim that they can

revolutionize software development Their detractors think they are im

p ossibly dicult Meanwhile for most p eople formal metho ds are so

unfamiliar that it is dicult to judge the comp eting claims

Securitykernels were designed to provide provable securityandevolved from the

idea of a reference monitor describ ed by Anderson And A reference monitor

is an abstraction of access checking mechanisms Den The idea b ehind security

kernels is to have a small nucleus of software that is resp onsible for administering

the security p olicy of the entire system The implementation of a securitykernel is

formally veried to demonstrate that it conforms to the security requirements

The requirements of a securitykernel are stated in precise mathematical terms and

are known as the criteria for the system The requirements are followed by stating

the sp ecications that precisely describ e the function of the software in mathematical

terms These sp ecications are indep endentofanyimplementation details and the

system is co ded using a high order language HOL Finally the implementation is

formally demonstrated to conform to the original requirements

Several securitykernels were develop ed to provide provable system security These

included the Kernelized Secure Op erating System MD MITRE securitykernel

Sch with AIM SCS and the UCLA Data Secure Unix DSU

PKKe However securitykernels failed to gain widespread p opularity b ecause of

high developmentcosts medio cre p erformance and diculties encountered in main

taining the systems

SecurityTesting

Software testing is a cost eective metho d to detect faults in software Mye

Several software testing techniques have b een prop osed and have b een studied widely

Bei MyeMye These techniques provide costeective and systematic meth

o ds to detect faults in software Similarly security testing is intended to assess the

trustworthiness of the securitymechanisms Bei Security testing is often regarded

as a sp ecial case of system testing Bei The emphasis of security testing is not to

establish the functional correctness of the software but to establish some degree of

condence in the security measures Bei

Atpresent there is no systematic approach to security testing Traditional meth

o ds of detecting security faults include p enetration analysis and formal verication

of securitykernels Lin MD Penetration analysis is conducted bya tiger team

which is comprised of p ersonnel familiar with the abstract and implementation de

tails of op erating systems Lin Penetration analysis has proven to b e a successful

metho d in assessing the security of a system Lin H Wil AMP But the

success of this metho d dep ends on the comp etence of the tiger team memb ers and

their knowledge of the system

The imp ortance of security in computer systems cannot b e ignored It is needed for

reliable op eration and to maintain the integrity of stored information However there

do es not exist a systematic approach to detect or prev ent security faults in op erating

systems Traditional security assessment metho ds are based on a p enetrate and

patch paradigm where faults are xed as they are discovered The shortcoming of

this approach is succinctly summed up bySchell Scha as

Penetrate and patch is a losing approach to assure secure systems b ecause

the hacker needs to nd only one aw whereas the vendor must nd and

x all the aws

In the following section we discuss the motivation for developing a fault classi

cation scheme and its applications in making the pro cess of fault prevention and

detection more systematic

Applications of Fault Categories

In this thesis we dene a classication of security faults in the Unix op erating

system and present applications of the classication scheme Faults can o ccur in dif

ferent sections of source co de and can result in a wide range of consequences A fault

classication scheme can b e used to categorize faults that a common character

istic The categories can b e used to collect statistics ab out faults and devise metho ds

for fault prevention and detection Beizer Bei summarized the imp ortance of fault

classications as

It is imp ortant to establish categories for bugs if you take the goal of

bug prevention seriously If a particular kind of bug recurs or seems to

dominate the kinds of bugs you have then it is p ossible through education

training new controls revised controls do cumentation insp ection and a

variety of other metho ds to reduce the incidence of that kind of bug If you

have no statistics on the frequency of bugs you cannot have a rational

p ersp ective on where and how to allo cate your limited bug prevention

resources

The ob jective of our fault classication scheme was to unambiguously classify

security faults into nonoverlapping categories We applied the fault categories for

data organization in a vulnerability database and it was necessary to derive non

overlapping categories

The vulnerability database we designed can b e used to store vulnerability infor

mation from dierent sources and maintain security patch information We identied

several p otential applications of the vulnerability information in the database The

information can b e used to analyze commonly o ccurring faults and trace their ori

gin to a design or programming practice If the fault cannot b e corrected defensive

mechanisms may b e programmed in a system that take preventive actions when the

fault o ccurs

The vulnerability information can also b e used to congure audit to ols that at

tempt to nd known vulnerabilities in a system FS SSH The information in

the database can also b e used to write signatures that can b e used byanintrusion

detection system to detect intrusions in realtime KS Furthermore the database

maybeusedtodevisethought exp eriments during the awhyp othesis stage of a

p enetration analysis of a system Lin

As security testing is a sp ecial case of software testing Bei the fault categories

can b e used to devise software testing techniques that exp ose faults in each category

For instance DeMillo and Mathur DM used fault categories to detect errors re

p orted byKnuth in the developmentofT XKnu Based on fault characteristics

E

weidentify software testing techniques that can b e used to detect these characteris

tics and exp ose faults in each category These testing techniques can provide a more

systematic approach to fault detection as compared to the p enetrate and patch

paradigm This testing can b e p erformed as part of system acceptance testing after

the software has b een develop ed Alternatively these techniques can b e used as part

of a p enetration analysis to detect security faults or as a guideline to develop new

attacks during the awhyp othesis stage

Organization of the Thesis

In Chapter w e present a summary of related work in fault classication and

p enetration analysis We present a revised taxonomy of security faults in the Unix

op erating system in Chapter The design and implementation of a vulnerability

database is discussed in Chapter In Chapter we discuss software testing metho ds

that can b e applied to detect security faults In Chapter we present our conclusions

and outline future work

RELATED WORK

Faults in op erating system software can lead to security breaches Knowledge of

the dierenttyp es of faults their general characteristics and the time they enter

the system is imp ortant to ensure reliable op eration and to preserve the integrityof

stored information These topics were the fo cus of fault classication studies that

were conducted to make computer systems secure and to improve the reliabilityof

software Another approach to nd security faults is to assume the role of an intruder

and assess the security mechanismsby trying to break into the system This approach

is the Flaw Hyp othesis Metho dology used in p enetration analysis studies

In the following sections we outline the previous research conducted on security

fault analysis p enetration analysis and software fault classication schemes We

conclude with a discussion of the shortcomings of the previous fault classication

schemes

Protection Analysis Pro ject

The Protection Analysis PA Pro ject conducted research on protection errors in

op erating systems during the mids The group published a series of pap ers

each of which describ ed a sp eci typ e of protection error and presented techniques

for nding those errors The prop osed detection techniques were based on pattern

directed evaluation metho ds and used formalized patterns to search for corresp onding

errors CBP The results of the study were intended for use by p ersonnel work

ing in the evaluation or enhancement of the security of op erating systems BPC

The ob jective of the study was to enable anyone with little or no knowledge ab out

computer security to discover security errors in the system by using the pattern

directed approach The errors that were found in the systems were classied into four

representative categories as follows

Domain errors including errors of exp osed representation incomplete destruc

tion of data incomplete destruction of content and incomplete destruction of

context

Validation errors including b oundary condition errors and failure to validate

op erands

Naming errors including aliasing and incomplete revo cation of access to a

deallo cated ob ject

Serialization errors including multiple reference errors and interrupted atomic

op erations

The PA pro ject did not achieve its goal of fully automating the error detection

pro cess by using the patterndirected approach The prop osed techniques could not b e

automated easily and their vulnerability database was never published However the

groups researchwas an imp ortant step in formalizing the pro cess of error detection

Some p ertinentwork is outlined b elow

Inconsistency of a Single Datum Over Time

Bibsey et al BPC describ ed a general class of problems in whicha value

b ecomes inconsistentafteritisveried These errors are also referred to as timeof

checktotimetouse TOCTTOU errors These typ e of errors could b e classied as

validation errors in the error classication scheme prop osed in the nal rep ort of the

PA pro ject BH

If the value of a variable in a critical function is inadvertently or intentionally

replaced with a dierentvalue after it has b een veried the op erating system can b e

fo oled into using this new value This can lead to a security breachifthevariable is

part of a critical check b ecause the entire checkwillbeinvalidated

BPC illustrated how a critical value change can lead to a security breachbya

usercallable routine shown b elow

connectPROCEDUREdirectory code

CALL passwordcheckdirectory password code

IF code ok THEN

userdirectory directory

END

connect is a usercallable sup ervisor pro cedure that allows users to change their

current directory to a dierent one than that was sp ecied at login The pro cedure

requires as arguments the name and password of the new directory and returns the

result of the request to the user in the variable code connect calls another sup ervisor

check to verify the correctness of the fdirectorypasswordg pair pro cedure password

A return co de of ok indicates that the directory was changed otherwise an error co de

is returned

The connect pro cedure assumes that the value of directory in line is the same

as that checked by password check It also assumes that the value of code in line

is the same as that returned by check The entire password checkwould

be invalidated if the values of code and passwd check were changed after they had

been checked but b efore b eing used The value of the variables could b e changed in

one of the following ways BPC

If the parameter was passed by name or reference the value remains in the

callers address space throughout the execution of the program Any asyn

chronous pro cess that has write access to the callers address space can change

the value

If the parameter was passed by name or reference the calling pro cedure could

arrange that the input and output variables o ccupy the same memory lo cation

When the called pro cedure stored into the output lo cation it would overwrite

the value of the input parameter

The consistency of a data value b etween successive op erations maybeformulated as

the p olicy

BMX for some op eration L o ccurring b efore M either

for op eration L which do es not mo dify ValueX

ValueX b efore L ValueX b efore M or

ValueX after L ValueX b efore M

Informally pro cess B can p erform op eration M on variable X only if the value of X

when M is p erformed is equal to the value of X either b efore or after some op eration

Lwhich o ccurs b efore M

The error statement corresp onding to the p olicy statementisgiven as

B MX and for some op eration L o ccurring b efore M

for op eration L which do es not mo dify ValueX

ValueX b efore L ValueX b efore M and

ValueX after L ValueX b efore M

Pro cess B p erforms op eration M on variable X and the value of X at the time op eration

M is p erformed is not equal to the value of X either b efore or after some op eration L

which o ccurs b efore M

The error statement could b e used to form a search pattern to detect if suchan

error exists in the source co de Bibsey BPC rep orted that fortyseven MULTICS

routines were searched using an error pattern and seven of them were found to contain

errors that could b e classied as TOCTTOU errors

AllocationDeal location of Residuals

This section describ es errors in op erating systems that result from exp osed content

and incomplete revo cation of access to storage elements Errors of this typ e are

classied as naming errors in the classication prop osed in the nal rep ort of the PA pro ject BH

A common strategy used in p enetration attacks is scavenging or searching for

residual information from other pro cesses HB Residuals can b e classied into

HB

Content residual Contents of le space or memory are allo cated to a new pro cess

without the data from the previous allo cation having b een purged

Attribute residual Information such as the size or p osition in the free p o ol of re

source is made available to a dierent pro cess

If attribute and content residuals are preserved they can b e exploited by commu

nicating pro cesses to get information ab out the activity of the pro cess HB Two



imp ortant attribute residuals that can disclose security related information are cell

size and inter and intracell relationships For example if the cell size information

is available to a user it may b e used to guess the maximum length of the password

eld which can reduce the numb er of p ermutations required in a brute force attack

Similarly the relative p osition of dierent cells in the free p o ol can b e used to deduce

that the previous cell allo cations were part of a larger pro cessdened cell

Content residual information can b e prevented from b eing disclosed by formulating

a deallo cation p olicy that either destroys the contents of storage cells when a cell is

added or after the cell is extracted from the free p o ol The latter is less desirable

b ecause a functional error in the system may lead to the contents b eing exp osed while

the cell is in the free p o ol The deallo cation mechanism can also b e designed such

that particular attribute information is destroyed b efore a cell is added to the free

pool

In addition to content residuals access residual information also p oses a security

problem and should b e prevented An access residual o ccurs when a pro cess can

still access a storage cell after it has deallo cated it or an access path to it has b een

established as a side eect of another request

a unit of storage

Hollingworth HB did not prop ose a formal search strategy to detect allo ca

tiondeallo cation errors It was suggested that the allo cation and deallo cation mecha

nisms should b e manually checked to ensure that content attribute or access residuals

are not preserved

Serialization

Serialization refers to the ordering of op erations relative to one another Seri

alization errors result from errors in ordering sp ecications either at the p olicy or

mechanism level Car Serialization errors qualify as protection errors b ecause they

can b e exploited to corrupt data ob jects that consequentlyresultininvalid op erations

However serialization errors are underestimated as security errors b ecause they usu

ally do not manifest themselves directly and rarely o ccur during the op eration of a

system Car Carlstead Car provides an indepth explanation of serialization

errors including a theoretical treatment of the sub ject

RISOS Pro ject

The RISOS pro ject was a study of computer security and privacy conducted in

the mids A The pro ject was aimed at understanding security problems

in existing op erating systems and to suggest ways to enhance their security The

systems whose security features were studied included IBMs OSMVT UNIVACs

Series op erating system and Bolt Beranek and Newmans TENEX system for

the PDP

The nal rep ort of the pro ject discussed several issues related to data securityin

general It suggested administrative actions that could prevent unauthorized access to

the system and metho ds to prevent disclosure of information The main contribution

of the study was a classication of integrityaws found in the op erating systems

studied

are the following The fault categories prop osed by researchers of risos A

Incomplete parameter validation

Pro cesses in an op erating system communicate with each other using pro cedure

calls Tomaintain reliable op eration the parameters must b e validated for data

typ es numb er and order value and range access rights to storage lo cation and

consistency A These checks must sp ecially b e enforced when a pro cedure

call is made by a pro cess that requests services from another pro cess with a

higher set of privileges Failure to validate the parameters completely or thor

oughly may result in an amplication of access rights of a sub ject whichmay

b e exploited to cause a security breach

Inconsistent parameter validation

Inconsistent parameter validation is a design error and dierent from parameter

validation errors If there are multiple sets of validation criteria in a system

that are not consistent an inconsistent parameter validation error o ccurs when

a routine evaluates a condition that it considers valid

Implicit sharing of privilegedcondential data

If information from a higher privileged pro cess or user b ecomes available to a

lesser privileged pro cess or user an implicit disclosure of information has taken

place To preserve the integrity of stored information and security of the system

it is imp ortant that such errors b e prevented from o ccurring in the op erating

system software

AsynchronousvalidationInadequateserialization

This category is comprised of errors that o ccur if serialization is not enforced

during the time a value is stored and the time it is referenced timeofcheckto

timetouse errors These errors can usually b e exploited to p enetrate a system

during a small timing window

Inadequate identicationauthenticationauthorization

Authorization refers to the controlled granting of access rights and is based on

authentication of individuals and resources A Op erating system security

may b e compromised if

it do es not require authorization for an individual or pro cess

it do es not uniquely identify the resources it is dealing with

Violable prohibitionlimit

Op erating system co de contains many xedsized data structures such as tables

queues and stacks If these data structures overow the system maybehave

in unexp ected ways that may lead to a security compromise

Exploitable logic errors

Some errors in op erating system software may exist b ecause of improbable tim

ing conditions incorrect error handling or instruction sideeects For exam

ple handling an error condition b efore an error signal is raised or using half

word arithmetic to store a return address from a routine can b e regarded as

exploitable logic errors

Flaw Hyp othesis Metho dology

System Development Corp oration SDC conducted p enetration analyses of seven

government and industrial installations to assess the secureworthiness of their sys

tems This led to the formulation of the Flaw Hyp othesis Metho dology that was

successfully used in these p enetration studies

Linde Lin summarizes the imp ortance of p enetration analysis as

In the absence of more formal correctness pro of techniques p enetrations

are the most cost eective metho d for assessing vulnerabilities Exhaus

tive testing of an op erating systems security controls is dierent than

sub jecting them to a p enetration attack System testing is intended to

discover implementation errors whereas p enetration tests are used to ex

amine an implementation and from these analyses infer areas of p ossible

design weaknesses

The Flaw Hyp othesis Metho dology is a strategy for p enetrating an op erating system

as well as for isolating generic functional aws that can b e used for determining

weaknesses in the functional areas of the op erating system design Lin The four

stages of the metho dology are outlined b elow

Know ledge of systems control structures For a successful p enetration a p enetrator

should have an understanding of how the users interact with the system what

services are available to them and the constraints placed on those services In

addition a p enetrator should have an abstract as well as implementation level

knowledge at the following levels

intermo dule knowledge

access control mechanism

control ob ject hierarchy

intramo dule design

implementation

Flaw hypothesis During the awhyp othesis stage the p enetration team makes a

hyp othesis ab out the existence of a vulnerability in the system by studying

system source co de and any related do cumentation

Flaw hypothesis conrmation This stage of the metho dology involves conrming

the awhyp othesis by using liveattacks or by writing programs to exploit the

p otential vulnerability

Flaw gener alization In this stage the p enetration team makes a generalized hy

p othesis ab out the existence of a aw based on their knowledge of errors in

other similar systems or by analyzing aws discovered in dierent functional

mo dules of the system under study

Based on the successful p enetrations Linde Lin observed that some mo dules

were found to b e more vulnerable than others and it is recommended that these

should b e insp ected in a p enetration analysis The functional mo dules that should

b e insp ected for securityaws include

InputOutput control

Program and data sharing

Access Control

Installation managementop eration control

The main contribution of this study was the formulation of the Flaw Hyp othesis

Metho dology for system p enetration This metho dology was later successfully used

in several p enetration analysis studies H AMP Wil Despite its usefulness

the metho dology has some drawbacks It do es not provide a systematic approachto

testing the security mechanisms Also the success of a p enetration analysis dep ends

on the knowledge and exp ertise of the tiger team conducting the study As with most

testing techniques p enetration testing can only show the existence of securityaws

not their absence

Case Study Penetration Analysis of the Michigan Terminal System

Presented in this section is a case study of a p enetration analysis conducted by

a graduate level computer science class at the UniversityofMichigan Ann Arb or

H The goals of this study were for an authorized and knowledgeable but un

privileged user to gain unauthorized access to les and data and crash the system

MTS was a general purp ose op erating system for IBM computers and sup

p orted b oth batch and interactive computation The system under study maintained

ab out user accounts and could supp ort users concurrently The members

of the tiger team conducting the p enetration analysis were students enrolled in the

course and had several years of exp erience in using the system The team members

had access to all userlevel do cumentation and manuals as well as internal system

do cumentation

The p enetration team employed the Flaw Hyp othesis Metho dology to nd aws

in the op erating system and discovered a number of aws in some of the system

subroutines It was found that the parameter checking mechanisms were weak and

would allow a user to store arbitrary bit sequences in the system segment The system

segment in MTS contained much of the systems accounting and protection informa

tion Thus by storing an arbitrary bit sequence a user could mo dify the systems

accounting information change his privilege level and completely disable the pro

tection mechanisms As a consequence users could execute privileged instructions

disable hardware storage protection and mo dify shared segments In MTS the sup er

visor co de is also contained in the shared segment Thus by forcing an appropriate

bit pattern to b e stored in the shared segment users could switch the system to su

p ervisor mo de and gain complete control over the system This is the also known as

total system p enetration and is the ultimate goal of a p enetration study H

Some other aws were also found in the system that resulted in nontotal system

p enetrations One suchaw allowed users to bypass the normal accounting up date

and get free computer time by forcing a job into abnormal termination It was also

discovered that some shared memory segments contained sensitive information such

as user and tap e iden tication that could lead to disclosure of information

In the denial of service attacks the system could b e forced to lo op forever while in

sup ervisor mo de when presented with a particular instruction sequence

The study concluded that p enetration analysis if prop erly done can provide an

actual estimate of the amount of time and eort needed to p enetrate a system H

Even though this work factor may b e sub jective and imprecise it still can givea

valid assessment of a systems overall security and highlight its areas of strength and

weaknesses The study also highlighted the interdep endence of dierent mo dules as

an imp ortant area of consideration b ecause system routines execute with an implicit

trust on each other Any security violation at the lowest security level can lead to a

cascading eect that can cause securityoftheentire system to b e compromised

Software Fault Studies

Marick Mar published a survey of software fault studies from the software

engineering literature Most of the studies rep orted faults that were discovered in

pro duction quality software Outlined in this section is a summary of the results from

various software fault studies For brevity the citation index is used for reference to

the study A brief description of these studies is included in App endix A

Faults in programming logic are common

Programming logic errors refer to errors that are intro duced in the software

b ecause of a misunderstanding of the problem area Mar These errors may

be intro duced in the software b ecause of incorrect design or incorrect logic

Studies by Dniestrowski DGM Lip ow Lip and Motley MB found

that programming logic faults were the largest typ e of faults In other studies

Rub ey Rub and Glass Gla also regarded programming logic faults as

b eing serious

Faults of omission are imp ortant

Most faults in the survey were faults of commission and few were faults of omis

sion Mar Glass Gla studied faults that were discovered after delivery

of the software He observed that faults of omission are the most likely faults

to survive Basili and Rombach BR found that most interface faults were

omissions while data handling and computation faults were mostly faults of

commission

Data handling is more errorprone than computation

Data handling refers to the pro cess of initializing and changing variables to

distinguish from computation faults which include evaluation of arithmetic and

b o olean expressions Mar

Basili BR and Glass Gla rep orted that data handling faults were nu

merous in their study Studies by Rub ey Rub Basili and Perricone BP

Lip ow Lip Motley MB and Ostrand and Weyuker OW rep orted

such faults to b e of average frequency

Static and dynamic detection techniques are approximately equally eective

Neither detection technique can detect all the faults in the implementation

Static analysis techniques have proven to b e successful at exp osing of

logic and design errors in a typical program DMMP Dynamic techniques

can exp ose runtime errors that may not b e detected by static analysis Accor

ding to four studies rep orted by Marick Mar there is no convincing evidence

that one technique outp erforms the other The p ercentage of errors detected

using the two techniques is shown in Table

Study Static Analysis Dynamic Analysis

Rub

SB

DGM Weak complexitymodules

DGM Greater complexitymodules

WB

Table Percentage of Errors Detected

Note In the study by Dniestrowski et al DGM weak complexitymodules

refer to mo dules containing mostly arithmetic and b o olean expressions Greater

complexity mo dules contain IO drivers and realtime management co de

There is evidence that b oth small and large mo dules are more errorprone than

medium sized mo dules

Studies by Basili and Perricone BP and Shen et al Y observed that

smaller mo dules have higher fault rates This observation is also conrmed by

Withrow Wit in her study of Ada programs

No conclusion ab out development phases is p ossible

The p ercentage of faults intro duced during the dierent phases of the software

life cycle vary from to making it dicult to drawany conclusive

decisions ab out the time a fault was intro duced

Fault Categories

Rub ey Rub presented several fault categories and the p ercentage of fault o c

currence in a study of small commercial realtime control programs The results are

shown in Table

Fault Category Percentage

Incomplete or erroneous sp ecications

Intentional deviation from sp ecication

Violation of programming standards

Erroneous data access

Erroneous decision logic or sequencing

Erroneous arithmetic computations

Invalid timing

Improp er handling of interrupts

Wrong constantordatavalue

Inaccurate do cumentation

Table Fault Categories byRubey

Weiss WB rep orted faults in a pro ject to develop a hardware architecture

simulator co ded in lines of Fortran The faults included in the study were

rep orted during development and after delivery The fault categories byWeiss WB

are shown in Table In the categories prop osed byWeiss WB language refers

to misunderstanding a Fortran language construct and clerical and careless ommision

refers to a misunderstanding of the design concept

Fault Category Percentage

Requirements

Design

Interface

Co ding Sp ecications

Language

Co ding Standards

Careless ommision

Clerical

Table Fault Categories byWeiss

Table presents results from a comparative study published byPotier PAFB

Potier collected over faults found in a for TLR a high level language

Most of the faults were detected during testing Potier et al compare their ndings

with those published in Lip and MB

Category PAFB Lip MB

Computational

Logic

I

Data handling

Interface

Data denition

Data base

Others

Table Comparative Results byPotier

Beizer Bei collected a sample of program statements mostly exe

cutable and faults from fault studies conducted by Dniestrowski et al DGM

Endres End Rub ey et al RDB and Schneidewind Schb Based on these

statistics Beizer prop osed a classication scheme and categorized the faults into the

dierent categories These categories and the fault statistics are shown in Table

Category Number Percentage of o ccurrence

Functional

Sp ecication

Function

Test

Total

System

Internal Interface

HardwareIO devices

Op erating System

Software Architecture

Control or Sequence

Resources

Total

Process

Arithmetic

Initialization

Control or Sequence

Static Logic

Other

Total

Data

Typ e

Structure

Initial Value

Other

Total

Code

Documentation

Standards

Other

Table Bug Statistics by Beizer

Errors of T X

E

T Xisatyp esetting software develop ed byDEKnuth Knuth presented a

E

chronological record of errors discovered during the development pro cess and pro

p osed a classication scheme to organize the errors Knu The classication scheme

was based on essential functionality rather than on the external form of the program

Knu This error classication is included in our study b ecause it is representative

of errors made by comp etent and exp erienced programmers A revised classication of

these errors was used by DeMillo and Mathur DM to detect errors using mutation

testing

The fault categories prop osed byKnuth are as follows

A an algorithm gone awry

B a blunder or a mental typ o

C a cleanup for consistency or clarity

D a data structure debacle

E an eciency enhancement

F a forgotten function

G a generalization or growthofability

I an interactiveimprovement

L a language liability

M a mismatchbetween mo dules

P a promotion of p ortability

Q a quest for quality

R reinforcement of robustness

S a surprising scenario

T a trivial typ o

In Knuths classication ABDFLMRS and T represent bugs which had to b e

xed for the correct functioning of the program Knu Categories CEGIPand

Q represent enhancements whichwere intro duced to improve p erformance Knu

ATaxonomy of Computer Program SecurityFlaws

Landwehr et al L published a collection of securityaws in dierentop

erating systems and classied eachaw according to its genesis or the time it was

intro duced into the system or the section of co de where eachawwas intro duced

This study was motivated by the observation that the history of software failures is

mostly undo cumented and a study that cataloged system failures could help system

designers in building b etter and secure systems The authors remark that

Knowing how systems have failed can help us build systems that resist

failure

An outline of the three categories in the taxonomy is presented b elow

By Genesis The genesis of a aw is categorized as malicious or nonmalicious Ma

licious aws are intentionally intro duced in the system to cause a security vio

lation These take the form of viruses worms Tro jan horse time b ombs and

trap do ors in the co de L Nonmalicious aws are intro duced b ecause of

an implementation error missing requirements or misunderstanding of design

logic Most nonmalicious aws can b elong to one of the following categories

Validation errors

Domain errors

Serializationaliasing errors

Errors that result from inadequate identicationauthentication

Boundary condition errors

Logic errors

By time of introduction Flaws are categorized according to the time in the software

life cycle that they were intro duced into the system Time of intro duction

includes aws that were intro duced during development maintenance and op

eration

By location In this categoryaws are classied based on their lo cation in op erating

system routines supp ort software or user programs Flaws in op erating system

are further classied into categories corresp onding to the functional mo dules

where they are discovered

Comparison of SecurityFault Classication Schemes

In chapter we present a taxonomy of security faults in Unix The ob jectiveofour

fault classication scheme was to unambiguously classify faults into nonoverlapping

categories This classication was then used for data organization in the design of

a vulnerability database and to identify fault detection techniques In this section

we discuss the shortcomings of the existing security fault classication schemes in

applying them for data organization

The research conducted by the Protection Analysis Pro ject was aimed at formu

lating pattern matching techniques to detect security faults in the system source co de

CBP The search strategies were based on the use of formalized patterns and an

alyzed the syntactic structure of the program An error was detected if a sequence of

op erations matched the corresp onding error pattern The nal rep ort of the pro ject

prop osed four representative categories of faults BH These fault categories were

designed to group faults based on the syntactic structure and were to o broad to b e

used for data organization Eac h category in the classication consisted of several

typ es of faults This would have made it dicult to unambiguously classify faults

and would not have allowed sp ecic queries to b e p erformed on our database

Seven generic fault categories were published in the nal rep ort of the risos

pro ject A These fault categories were develop ed with the goal of b etter under

standing the faults and to classify and analyze new faults as they were discovered

A The fault categories prop osed by researchers of risos were general enough

to classify faults from several op erating systems But the generality of the fault cat

egories would haveprevented negrained queries to b e p erformed on our database

Also the criteria used for the classication was not clearly stated This could lead

to ambiguities when classifying dierent faults and a fault could b e classied in more

than one category

Landwehr et al L prop osed a taxonomyofaws found in dierent op erating

systems The ob jective of this taxonomywas to identify the time during the software

lifecycle that a fault was intro duced in the system The taxonomy categorized aws

according to genesis lo cation in the system software and time of intro duction These

three fault categories were further divided into subcategories This fault classica

tion was not used for data organization in our database b ecause faults could not b e

categorized into Landwehrs prop osed categories based only on their description For

example to classify a aw as either b eing malicious or nonmalicious involves a deci

sion ab out the intentions of the This is dicult to judge without access

to the source co de and knowledge of the programming environment Also it is not

p ossible to correctly predict the time a awwas intro duced in the system based only

on its description Mar Such a decision could not b e made without kno wledge of

detailed progress rep orts and milestones met during a pro ject Similarly the lo cation

where a awwas discovered cannot b e easily classied without access to the source co de

ATAXONOMY OF SECURITY FAULTS IN THE UNIX OPERATING

SYSTEM

In this chapter we present a taxonomy of security faults in the Unix op erating

systems We present the motivation for developing the taxonomy followed bya

discussion of the dierent fault categories in the classication

Security errors in op erating systems are software faults that are intentionally or

inadvertently intro duced in the system and can cause a security breach an action

that violates a security p olicy The op erating system plays an imp ortant role in the

op eration of a computer system and the presence of a security fault p oses a p otential

threat to disrupt reliable op eration of the system A security fault may b e exploited

to cause denial of service disclosure of information or degrade p erformance of the

system Toprevent unauthorized and authorized users from disrupting reliable op er

ation the securitymechanisms of an op erating system should b e able to withstand

malicious attacks and the implementation should not contain any faults that maybe

exploited to breach security

Security of computer systems is imp ortantsoastomaintain reliable op eration and

to protect the integrity of stored information With the widespread use of comput

ers and increasing computer knowledge it is no longer p ossible to implement security

through obscurity GS To ensure that computer systems are secure against ma

licious attacks we need to analyze and understand the characteristics of faults that

can subvert security mechanisms A classication scheme can help in the understand

ing of fault characteristics by categorizing faults that share common c haracteristics

This classication can b e used to organize vulnerability data gather statistics ab out

frequency of faults and devise prevention or detection techniques

ATaxonomy of SecurityFaults

In this chapter we present a taxonomy of security faults in the Unix op erating

system The motivation of the study was to unambiguously classify security faults

into distinct categories This classication was used as the basis for data organization

of a vulnerability database that facilitated dierent queries to b e p erformed on the

stored data The sp ecic characteristics of faults in each category have also b een used

to identify software testing techniques that can detect those faults These testing

metho ds can provide a systematic approach to detect security faults as compared to

the traditional p enetrate and patch paradigm

Our fault classication scheme is not unique Several security fault classication

schemes have b een prop osed that categorized faults according to dierent criteria

These include the classications prop osed in the nal rep ort of the Protection Anal

ysis Pro ject BH a classication prop osed by researchers of the risos pro ject

A and a taxonomyofaws prop osed byLandwehr et al L However

these classications are not suitable for data organization b ecause the categories are

to o generic and do not clearly sp ecify the criteria used for the classication The

latter often leads to ambiguities that can result in a fault b eing classied in more

than one category Our taxonomy addresses these shortcomings The fault categories

we present are sp ecic and distinct We also sp ecify a selection criteria for eachfault

category

Our taxonomywas derived from security faults in the Unix op erating system

that led to a security compromise Other taxonomies discussed earlier A L

BH were based on faults collected from several dierent op erating systems We

fo cused on Unix b ecause of its widespread p opularit y in academia and industry

Thus a large numb er of users would b enet from the results of a study based on Unix

vulnerabilities The security faults were collected from a numb er of dierent sources

including Computer Emergency Resp onse Team CERT advisories vulnerabilities

rep orted on an electronic security mailing list and a survey of the literature

After collecting the security faults we gathered information on how eachfault

was exploited the functional area a fault was found in versions of op erating systems

that each fault was present and the consequences that o ccurred when the fault was

exploited This information was collected from references in literature descriptions

of faults in the resp onse team advisories and discussions with exp erienced p ersonnel

After understanding the details we broadly classied faults as either co ding faults

op erational faults or environment faults

Personnel communication physical and op erations securityplay an essential role

in the reliable op eration of computer systems ISV Vulnerabilities in any of these

classes may b e exploited to cause a security compromise Wehave fo cused on faults

that are emb o died in the software Wehave not included vulnerabilities that involved

p ersonnel communication physical or op erations security Examples of vulnerabili

ties in these security classes include

Personnel security An employee is brib ed to reveal sensitive information

Communication security A wiretap is installed to monitor information on a channel

Physical security An intruder or an employee steals a disk or tap e containing sen

sitive information

Op erations security An op erator fails to run software that could detect p otential

securityweaknesses

Co ding faults are comprised of faults that were intro duced during software devel

opment These faults could have b een intro duced b ecause of errors in programming

logic missing or incorrect requirements or design errors These observations are

dra wn from dierent software fault studies that list the aforementioned errors as p o

tential problem areas Rub WB PAFB Bei Knu Op erational faults

result from improp er installation of software Most p olicy errors can b e classied as

op erational faults Environment faults result when a programmer fails to completely

understand the limitations of the runtime environmentorinteractions b etween func

tionally correct mo dules These faults are dep endent on the op erational environment

Co ding and op erational fault categories were further rened into distinct sub

categories For co ding faults we studied the faults to identify the sp ecic co ding

error that led to the fault We tried to abstract each implementation error to a level

that would maintain the sp ecic characteristics of each category yet hide the imple

mentation details This approach can b e b enecial in classifying faults in more than

one The fault categories were then used to group dierent

faults that shared similar characteristics For op erational faults weidentied the

sp ecic op eration that had led to the fault and used it to categorize the faults

In the following sections we present our taxonomy of faults For each fault cat

egory we present a description of the fault the criteria used and examples of the

dierent fault typ es

The taxonomy of faults is comprised of the following categories

Operational Faults

Conguration errors to include errors resulting from

programsutilities installed in the wrong place

programsutilities installed with incorrect setup parameters

programsutilities or secondary storage ob jects installed with access p er

missions that violate the security p olicy

Coding Faults

Synchronization errors to include

race condition errors

errors resulting from improp er or inadequate serialization of op erations

Condition validation errors to include errors resulting from

missing conditions

incorrectly sp ecied conditions

missing predicates in the condition

Environment Faults

Environment faults include

errors resulting from a limitation of the op erational environment

errors intro duced by a faulty compiler or op erating system

interaction errors b etween functionally correct mo dules

errors intro duced b ecuase exception handling mechanisms are dierent

than exp ected

Figure shows a diagrammatic representation of our fault taxonomy

security fault

environment coding fault operational fault fault

condition synchronization validation error configuration error error

improper race failure or inadequate object utility utility installed condition to handle serialization error installed with installed in the with incorrect error exceptions incorrect wrong place setup permissions parameters

input origin access rights boundary validation validation validation condition error error error error

field value syntax type & missing correlation number of extraneous

error error input fields input input

Figure TaxonomyofFaults

Conguration Errors

The conguration of a system can b e broadly dened as consisting of the hard

ware and software resources web Thus the system utility programs and various

service routines that a computer system provides can b e regarded as b eing part of

the conguration In our taxonomy a fault can b e classied as a conguration if

a programutility is installed in the wrong place

a programutility is installed with incorrect setup parameters

a secondary storage ob ject or a programutility is installed with incorrect p er

mission that violates the security p olicy

The following examples illustrate how conguration errors have b een exploited to

compromise security

Examples

The trivial le transfer proto col tftpisa network utility based on the User

Datagram Proto col UDP and is commonly used by diskless workstations to down

load kernel image les from a server Com At some sites running dierentversions

of Unix the tftp daemon was enabled in sucha waythatitallowed any user on the

Internet to access any le on the machine running tftp CAa CAb This

could result in disclosure of information and security could b e compromise if sensitive

les were read For instance if an intruder obtained access to the password le it

could b e used to crack passwords and gain unauthorized access to the system The

problem o ccurred b ecause tftp was not prop erly installed If tftp had to b e enabled

it should have b een installed such that it only had restricted access to the le system

through the chroot command

In Unix BSD was installed with the Wizard mo de enabled CAa

The Wizard mo de option was left over from a test scaolding It was included to

enable system programmers to debug the program without having to go through a

lengthy authentication pro cess If sendmail was installed with Wizard mo de en

abled any user could gain access to the system by connecting to the mail p ort and

providing WIZ as a command The Wizard mo de came with a default password

of wizzywoz By using this default password an intruder could bypass the system

authentication pro cedure and gain access to the system

Synchronization Errors

Carlstead Car studied serialization errors in detail as part of the Protection

Analysis Pro ject Some of the ideas presented in this section are b orrowed from his

results Two op erations are data related if the evaluation of conditions by one can

aect the other bychanging the relative ordering of the op erations Two op erations

are control related if a change in the relative order of execution can pro duce dierent

results Serialization is concerned with twotyp es of relationships b etween op era

tions data ow and control ow The purp ose of serialization is to maintain the

appropriateness of the latter with the former Car

In our taxonomy a fault can b e classied as a synchronization error if

a fault can b e exploited b ecause of a timing windowbetween two op erations

a fault results from improp er serialization of op erations

Synchronization errors in our taxonomy include b oth race condition errors errors

that o ccur b ecause of a timing window and serialization errors error that result from

improp er serialization of op erations

Example

A Unix sp ecic example is presented here to illustrate race condition errors xterm

provides a windowinterface in the X window system A vulnerabilitywas found in

manyversions of the xterm program which if exploited allowed users to create and

delete arbitrary les in the system If xterm op erated as a or setgid pro cess

then a race condition b etween the access check p ermissions to the logging le and the

logging itself allowed users to replace any arbitrary le with the logging le CAa

The following co de explains how the vulnerability could b e exploited

mknod foo p create a FIFO file and name it foo

xterm lf foo start logging to foo

mv foo junk rename file foo to junk

ln s etcpasswd foo create a symbolic link to password file

cat junk open other end of FIFO

This error o ccurs b ecause of a timing window that exists b etween the time access

p ermissions of the logging le are checked and the time actual logging is started

This timing window could b e exploited by creating a symb olic link from the logging

le to a target le in the system If xterm ran as setuid ro ot this could b e used to

create new les or destroy existing les in the system

Condition Validation Errors

Most op erations in an op erating system can b e classied as Car

prohibitive an op eration is allowed to pro ceed only if the conditions under whichit

must b e allowed to pro ceed hold otherwise the action is ab orted

or

inhibitive an op eration is delayed until the conditions under which it can pro ceed

are met

For example access checking mechanisms are prohibitive b ecause an action is denied

if a userpro cess invokes it on an ob ject outside its access domain Synchronization

mechanisms are inhibitive b ecause an op eration is delayed until the required condition

is satised

Conditions are usually sp ecied as a conditional construct in the implementation

language An expression corresp onding to the condition is evaluated and an execution

path is chosen based on the outcome of the condition In this discussion we assume

that an op eration is allowed to pro ceed only if the condition evaluated to true A

condition validation error o ccurs if

Condition is missing This allows an op eration to pro ceed regardless of the

outcome of the condition expression

Condition is incorrectly sp ecied If a condition is incorrectly sp ecied it would

allow execution to pro ceed along an alternate path This mayallow an op eration

to pro ceed regardless of the outcome of the condition expression and completely

invalidate the check

A predicate in the condition expression is missing This would evaluate the

condition incorrectly and allows an alternate execution path to b e chosen

Condition errors are co ding faults that o ccur b ecause a programmer misunder

sto o d the requirements or made a logic error when a condition was sp ecied

In our taxonomy a fault is classied as a condition error if one of the following

conditions is missing or not sp ecied correctly

Check for limits Before an op eration can pro ceed the system must ensure that it

can allo cate the required resources without causing starvation or deadlo cks For

inputoutput op erations the system must also ensure that a userpro cess do es

not read or write b eyond its address b oundaries

Check for access rights The system must ensure that a userpro cess can only access

an ob ject in its access domain The mechanics of this check dep end on how

access control mechanisms are implemented

Checkforvalid input Any routines that accept input directly from a user or from

another routine must check for its validity This includes checks for

Fieldvalue correlation

Syntax

Typ e and numb er of parameters or input elds

Missing input elds or delimiters

Extraneous input elds or parameters

Failure to prop erly validate input may indirectly cause other functional mo dules

to fail and cause the system to b ehave in an unexp ected manner

Check for the origin of a sub ject In this context sub ject refers to a userpro cess

host and shared data ob jects The system must authenticate the sub ject to

preventidentity compromise attacks

Check for exceptional conditions The system must b e able to handle exceptional

conditions that arise from failure events or malfunction of a functional mo dule

or device

Examples

In Unix etcexports sp ecies a lists of trusted remote hosts that are allowed

to mount the le system In SunOS x if a host entry in the le was longer

than characters or if the numb er of hosts exceeded the cache capacity a buer

overow allowed any nontrusted host to mount the le system CA This allowed

unauthorized users read and write access to all les on a system This error o ccurred

b ecause the system failed to check that it had read more than characters or that

it had exhausted the cache capacity

The Unix op erating system allows users to copy a le from or to a remote ma

chine via the rcp utility A vulnerabilitywas discovered in a version of Unix that

allowed remote users of a trusted machine to execute ro otprivilege commands via

rcp CA This problem o ccurred b ecause of an authentication error in the name

lo okup proto col that binds the high lev el addresses used for identication to Internet

Proto col IP addresses This error is representativeofa numb er of other similar

aws that can b e exploited using a weakness in the Domain Name Service proto col

Sch The error o ccurred b ecause the origin of the message hostname was not

authenticated

In SunOS and SunOS any user could redirect characters away from any

other users terminal device The error o ccurred b ecause the inputoutput routine

failed to prop erly check access rights of the user who had invoked the op eration The

x involved adding a checktoallow a read or write request to pro ceed only if the user

had the correct access rights and reject the request otherwise CAb

uux is a Unix utility that allows users to remotely execute a limited set of com

mands A aw in the parsing of the command line allowed remote users to execute

arbitrary commands on the system Bis The command line to b e executed was

received by the remote system and parsed to see if the commands in the line were

among the set of commands that could b e executed uux read the rst word of the

line and skipp ed characters until a delimiter character was read uux would

continue this wayuntil the end of the line was read However two delimiters

were missing from the set so a command following these characters would never b e

checked b efore b eing executed For example a user could execute any command by

executing the following sequence

uux remotemachine rmail anything command

In uux the command after would not b e checked b efore b eing executed This

allowed users to execute unauthorized commands on a remote system This error

o ccurred b ecause uux failed to check for missing delimiters

fsck isaprogramthatchecks and repairs le system consistency Some of the

inconsistencies that fsck corrects include to olarge link counts in ino des missing

blo cks in the free list blo cks app earing in the free list and also in les or incorrect

counts in the sup er blo ck On many Unix systems fsck is run as part of the system

b o otup pro cedure to correct lesystem inconsistencies If fsck failed during b o otup

in Solaris x a privileged shell was started on the console This enabled anyuser

with physical access to gain ro ot privileges CAb

EnvironmentFaults

Environment faults are intro duced when sp ecications are translated to co de but

sucient attention is not paid to the runtime environment Spa These faults are

dep endent on the op erational environment and result when software is executed in a

dierentenvironment than the programmer had in mind

Some typical examples of environmental faults include Spa

the value used to initialize uninitialized pages or segments of

mayintro duce unsusp ected problems

interp ertation of supp osed constantvalues may pro duce faults such as p orting

co de that deferences a constant p ointer

exception handling and rep orting may b e dierent than exp ected

system errors a compiler may pro duce incorrect co de the hardware may ex

ecute instructions dierently than exp ected under some circumstance and the

op erating system mayintro duce intermittent errors not related to the user co de

Environment faults can also o ccur when dierent mo dules interact in an unantic

ipated manner Indep endently the mo dules may function according to sp ecications

but an error o ccurs when they are sub jected to a sp ecic set of input in a particular

execution environment

Example

The exec system call overlays a new pro cess image over an old one The new image

is constructed from an executable ob ject le or a data le containing commands for

an interpreter When an interpreter le is execd the arguments sp ecied in the exec

call are passed to the interpreter Most interpreters take i as an argument to start

an interactive shell

In SunOS v ersion and earlier any user could create an interactive shell by

creating a link with the name i to a setuid shell script exec passed i as an

argument to the shell interpreter that started an interactive shell Both the exec

system call and the shell interpreter worked according to sp ecications The error

resulted from an interaction b etween the shell interpreter and the exec call that had

not b een considered

Selection Criteria

In this section we describ e the selection criteria that can b e used to decide mem

b ership of security faults into dierent categories The motivation is to avoid any

ambiguities and distinctly classify each fault

For each fault categorywe present a series of questions that are used to determine

memb ership in a sp ecic categoryAnanswer in the armative to a question in that

series qualies the fault to b e classied in the corresp onding category We assume

that sucient details ab out the faults are known

Condition Validation Errors

The following sets of questions can b e used to determine if a fault can b e classied

as condition validation error

Boundary Condition Errors

Did the error o ccur when a pro cess attempted to read or write b eyond a valid

address b oundary

Did the error o ccur when a system resource was exhausted

Did the error result from an overow of a staticsized data structure

Access Validation Errors

Did the error o ccur when a sub ject invoked an op eration on an ob ject outside its access domain

Did the error o ccur as a result of reading or writing tofrom a le or device

outside a sub jects access domain

Origin Validation Errors

Did the error result when an ob ject accepted input from an unauthorized sub

ject

Did the error result b ecause the system failed to prop erly or completely authen

ticate a sub ject

Input Validation Errors

Did the error o ccur b ecause a program failed to parse syntactically incorrect

input

Did the error result when a mo dule accepted extraneous input elds

Did the error result when a mo dule did not handle missing input elds

Did the error result b ecause of a eldvalue correlation error

Failure to Handle Exceptional Conditions

Did the error b ecause the system failed to handle an exceptional condition

generated by a functional mo dule device or user input

Synchronization Errors

This section presents the criteria that can b e used to decide if a fault can b e

classied as a synchronization error

Race Condition Errors

Is the error exploited during a timing windowbetween two op erations

Serialization Errors

Did the error result from inadequate or improp er serialization of op erations

Environment Errors

This section presents a series of questions that b e used to decide if a fault can can

b e classied as an environment error

Do es the error result from an interaction in a sp ecic environmentbetween

functionally correct mo dules

Do es the error o ccur only when a program is executed on a sp ecic machine

under a particular conguration

Do es the error o ccur b ecause the op erational environmentisdierent from that

the software was designed for

Conguration Errors

The following questions can b e used to determine if a fault can b e classied as a

conguration error

Did the error result b ecause a system utilitywas installed with incorrect setup

parameters

Did the error o ccur by exploiting a system utilitythatwas installed in the wrong

place

Did the error o ccur b ecause access p ermissions were incorrectly set on a utility

such that it violated the securitypolicy

Figure shows a pictorial representation of the decision tree derived from ques

tions used for deciding memb ership for faults The internal no des of the decision tree

represent the series of questions that are used for each category The leaf no des in the

tree represent the dierent fault categories The decision tree shows two no des that

are lab eled unclassiable errors These no des representa catchal l category for the

co ding op erational and environment faults The unclassiable error categories are

included in our classication scheme to account for new faults that cannot b e readily

classied using our existing criteria The new fault category and the asso ciated crite

ria can b e added as a parentnodeoftheunclassiable error no de The abilitytoadd

new fault categories can b e useful if the taxonomy is extended to dierent op erating

systems that have dierent structures

coding fault Y N

boundary operational condition Y error environment N dependent fault condition Y access validation validation N error Y error environment N setup parameters error N Y origin condition access validation validation configuration error permissions Y error error N Y installed in N wrong place configuration condition error input validation N Y error validation policy configuration N error error Y error Y N failure configuration condition error to handle validation unclassifiable exceptions error error

N Y

condition race condition validation error error N Y

serialization synchronization error error Y N

unclassifiable synchronization

error error

Figure Selection Criteria for Fault Classication

DESIGN OF THE VULNERABILITY DATABASE

In this chapter we present the conceptual design of a vulnerability database The

vulnerability database can b e used to organize information ab out security faults based

on our taxonomy This chapter discusses the various design issues and the rational

b ehind the design choices The design of the database is presented in terms of re

lational mo del entities and relational algebra functions This approach is used to

separate the implementation details from the abstract design

Motivation

Landwehr et alL observe that the history of software failure has b een mostly

undo cumented and knowing how systems have failed can help us design b etter systems

that are less prone to failure The design of this vulnerability database is one step in

that direction The database can serve as a rep ository of vulnerability information

collected from dierent sources This information can b e organized to allow useful

queries to b e p erformed on the data The information in the database can b e useful to

the system designer in identifying areas of weaknesses in the design requirements or

implementation Personnel involved with testing securitymechanisms of an op erating

system may also nd the information to b e useful The database also demonstrates

that our taxonomy can b e applied to classify actual vulnerabilities from dierent

versions of Unix

Our database can also b e used to maintain vendor patch information vendor

and resp onse team advisories and catalog the patches applied in resp onse to those

advisories This information can b e helpful to system administrators maintaining a legacy system

Entity Relation Mo del

As part of the conceptual design pro cess an entity relation mo del is often used to

illustrate the relationships b etween the dierententities in the database mo del An

entity is a ob ject in the entity relation mo del with an indep endent existence in

the real world EN An entity can either havea physical or a conceptual existence

Based on the queries collected in the requirements analysis phase the following

three entities were identied

Vulnerability The vulnerabilityentitytyp e corresp onds to the description of a

p otential securityaw in the op erating system

Op erating system The op erating system entitytyp e corresp onds to the op erating

system that contains a particular vulnerability

Patch Info Patch info is a conceptual entity that provides information ab out patches

that were applied to a system and the vulnerabilities they x

EntityAttributes

An attribute is a particular prop erty p ossessed byanentity Asso ciated with an

attribute is a value which is the information stored in that attribute Attributes can

b e either single valuedormultivalued The single valued attributes are asso ciated

with the value set which sp ecies the domain of values that may b e assigned to the

attribute

The attributes asso ciated with the three entitytyp es are outlined b elow Wehave

also included a brief description and the value set of the attribute

Attribute Description Value Set

Nameidentication Unique identication pri string

number mary key

Source Where the vulnerabilitywas string

rep orted

Description A brief description of howit text

was or could have b een ex

ploited

Detection technique A brief description of the text

testing strategy that can b e

used to detect this vulnera

bility

Classication Representative category in string

the taxonomy

Work around Anyknown workarounds text

Description of x A description of how the vul text

nerabilitywas xed

Literature Any reference to the vulner text

ability

Consequence A generic consequence class string

Table VulnerabilityEntityAttributes

Attribute Description Value Set

System name Unique name of the op erat string

ing system primary key

Family of system Family of the system eg string

Unix

Vendor Vendors name and address string

if available

Table Op erating System EntityAttributes

Attribute Description Value Set

Patchnumber Unique patchnumber pri string

mary key

Description A brief description of the string

patch

Fixes vulnerability Vulnerabilityvulnerabilities text

xed by this patch

Table Patch Info Attributes

Entity Relation Diagram

The entityrelation diagram Figure shows two MN relationships that exist

between the entities in the database These relationships cannot b e easily represented

in the hierarchical or the network mo del without replication of data records As the

amount of stored information in the vulnerability database can b e large we opted for

the relational mo del minimize data replication Each MN relationship is represented

by an additional relation that contains the primary keys of the entities on b oth sides

patch num. description name family

vendor fixes N M vulnerability operating system contains patch info patches

M

contains 1 vulnerability results consequence N in

N work classification around

class description of fix vulnerability references detection in literature technique

id, number source description Legend

Entity

Attribute

Key Attribute

1 N

E1 E2 Cardinality Ratio

Figure Entity Relation Diagram

The following schema are derived from the entityrelation diagram and showthe

dierent attributes The primary key attributes of the schema are underlined

Op erating System Schema

name family vendor

VulnerabilitySchema

detection description references vulner source description classification work consequence

id technique around of fix in literature

Patch Info Schema

patch number description fixes vulnerability

Contains patchSchema

operating system patch number

name

Contains vulnerabilitySchema

operating system vulnerability

name id

EntityIntegrity Constraints

The entityintegrity constraints state that primary keys used to uniquely identify a

tuple in a relation should not b e null Entityintegrity constraints should b e enforced

on all up date add and mo dify op erations

Referential Integrity Constraints

Referential integrity constraints are sp ecied b etween two relations and are used

to maintain consistency b etween the tuples Referential integrity constraints should

b e maintained on add delete and mo dify op erations The referential integrity con

straints in our vulnerability database are diagrammatically depicted in Figure

Vulnerability

vulner detection description source description classification work references conseqeunce id technique around of fix in literature

Contains_vulnerability

operating system vulnerability name id

Contains_patch

operating system patch number name Operating system

name family vendor

Patch info

patch number fixes

description vulnerability

Figure Referential Integrity Constraints

Op eration on the Relations

Relational Algebra is a collection of op erations that are used to manipulate entire

relations It includes op erations to select tuples from individual relations and to com

bine related tuples from several relations for the purp ose of sp ecifying a queryThe

complete set of relational op erations consists of select project union differ

ence Cartesian productAny other relational op eration can b e p erformed as a

combination of these ve op erationsEN These op erations are briey describ ed in

Table

In the following sections we present the implementation details of the vulnerability

database prototyp e

The prototyp e was develop ed to demonstrate that vulnerabilities from dierent

versions of Unix can b e classied in our taxonomy of faults

The three ma jor comp onents of the vulnerability database are

Database kernel

Vulnerability database interface

Userinterface

Each of the three comp onents are discussed in detail in the following sections

The information and data ow information b etween the three comp onents is shown in Figure

User Interface

Vulnerability Database Interface

Database Kernel

Physical Schema

Figure Vulnerability Database

Requirements Analysis

As part of the requirements analysis weidentied two ma jor uses for the vulner

ability database It can b e used to maintain uptodate security related information

ab out dierent op erating systems that can b e helpful to system designers and re

searchers Also the vulnerability information can b e used during security assessment

studies of op erating systems In the second phase of requirements analysis weasked

several p eople involved with securityrelated pro jects to comment on a small set of

queries we had prop osed We asked them to supplement the list with any additional

queries that may b e p erformed on the database We then constructed a small but

comprehensive set of queries that encompass a wide range of attributes The collec

tion of queries help ed us identify the information that should b e included in dierent

attributes of the data ob jects

Although the collection of vulnerabilities provided useful information some of

the queries were discarded and the attributes they accessed are not included in the

database For example a query ab out the time that a vulnerabilitywas intro duced

into the system cannot b e answered by using the stored information Similarly queries

ab out programming practices are not supp orted Such queries cannot b e answered

without access to program source co de program requirements functional sp ecica

tions and knowledge of the program developmentenvironment Furthermore such

queries are dicult to answer b ecause they require a qualitativeevaluation of infor

mation

The set of queries that can b e supp orted in the initial prototyp e of the database

is shown b elow

List all the vulnerabilities in system X

List all vulnerabilities in system X that o ccur b ecause of Y eg race condition

List all vulnerabilities which result in Z eg denial of service

Perform anycombination of b o olean op erations on and eg Y Z Y Z

Y Z

Given vulnerability V classify it

Given vulnerability V nd all systems that have this vulnerability

List all vulnerabilities in system X that will result in Z

List all systems that have a vulnerability that will cause Z

Given vulnerability V and system X what were or could have b een the con

sequence if exploited

Give a brief description of howVwas could have b een exploited

List any reference to vulnerability V in the literature

Give a description of the x for vulnerabilityV

List all patches applied to system X

For a vulnerability V are there any practical workarounds

For system X version Y what vulnerabilities have no supp orted patch

For all systems that have a vulnerability V list their version numb ers and

vendors

List any references to V in the literature

Some queries collected during requirements analysis are not supp orted b ecause they

require a qualitative analysis of the data For completeness these queries are also

shown b elow

Given vulnerability V and system X which part of the op erating system was it

found in

Do es patch P completely x a given vulnerability

What is the level of dicultyexp ertise required to patch vulnerabilityV

What is the initial accesssetup required to exploit vulnerability V eg requires

a user account requires access to p ort P

Given a co ding practice list all vulnerabilities resulting from this co ding prac

tice

Given V howcouldhave it b een prevented

For a class of vulnerabilityCwhichsoftware engineering practice P would have

prevented the intro duction of this vulnerability

Design Issues

The two ma jor factors that inuenced the design of our database were scalability

and ease of maintaining the integrity of information

A p o or design that did not scale could lead to degradation of p erformance waste

storage space and create problems in maintenance Even though p erformance was not

a critical factor in the design wekeep a resp onse time for the queries We paid partic

ular attention to ensure that little or no data replication to ok place Our initial design

was based on a hierarchical mo del but the MN relationships b etween the dierent

entities could not b e mo deled without data replication At that p oint a relational

schema was adopted that facilitated the representation of the MN relationships with less data replication

Maintenance of a large rep ository of information is a dicult task and it is not

clear if any particular organization scheme can makeitany easier Wehave identied

entityintegrity constraints as well as referential integrity constraints that should b e

helpful to maintain the integrity of the stored information

Database Kernel

Our vulnerability database is based on a relational schema mo del that consists

of b oth physical and conceptual entities These entities are represented as relations

tables in the mo del Relational algebra denes the op erations that can b e p erformed

on the the relations It also denes a set of basis functions suchthatany query in

the relational mo del can b e sp ecied only in terms of these functions The basis

functions in the relational mo del are select project union difference and

cartesian product

The vulnerability database kernel is comprised of the ve basis functions that

directly op erate on the physical schema In addition it also contains the following

functions

Create Creates a new relation in the database

Mo dify Mo dify all the elds of a tuple in a relation

Up date Change a sp ecied eld of a tuple in a relation

Delete Delete a tuple from a relation

Destroy Remove a relation from the database

The kernel also provides a layer of abstraction to the upp er level layers whichdo

not directly interface with the physical schema This enables us to restrict details of

the physical schema to the kernel functions

Representation of Relations

In the vulnerability database each relation is contained in a separate le Each

tuple in the relation is represented as a line of text where the dierent elds are

separated by a colon An instance of the op erating system relation is shown b elow

osunxsome vendor

osxnvendor

Vulnerability Database Interface

The database provides an interface to the physical schema through a set of kernel

functions All of the queries listed in Section can b e sp ecied using only the

kernel functions However this approach has two disadvantages First the underlying

details of the physical schema are exp osed to the user Second sp ecifying the queries

only in terms of the kernel functions b ecomes cumb ersome and exp oses details of

the physical schema As an alternative a separate layer of abstraction called the

vulnerability database interface is provided This layer provides a set of formbased

queries that interact with the kernel functions The set of queries currently supp orted

in the vulnerability database layer of the prototyp e are listed in Table

Query Interface Function

List all the vulnerabilities in system X list vulnerability sy stem

List all vulnerabilities in system X that o c vulner conseq

cur b ecause of Y v ul ner sy stem

List all vulnerabilities which result in Z list conseq conseq

Given vulnerability V classify it classify vulner

Given vulnerability V nd all systems that nd system vulner

have this vulnerability

List all vulnerabilities in system X that will vulner result

result in Y sy stem conseq

List all systems whichhave a vulnerability list systems sy stems

that will cause Y

Given vulnerability V and system X what conseq v ul ner sy stem

were or could have b een the consequence

if exploited

Give a brief description of howVwas exploit v ul ner

could have b een exploited

List any reference to V in the literature descr x v ul ner

Give a description of the x literature v ul ner

List all patches applied to system X patches to sy stem

For a vulnerability V are there any prac workaround v ul ner

tical workarounds

For system X version Y what vulnerabil nopatch sy stem

ities have no supp orted patch

For all systems that have a vulnerability sysinfo v ul ner

V list their vendors

Table Vulnerability Database Interface Functions

User Interface

A user can interact with our database either by using command line arguments

or through a graphical user interface The graphical interface was written using

the Tk to olkit Ous and provides a exible interface to the vulnerability database

functions All of the functions listed in Table can b e invoked through the interface

Figure shows the main commands screen that shows all the functions that

can b e invoked After a function has b een selected it maybeinvoked using the run

button This presents another windowwithentry elds for the needed arguments

Figure shows the dialogue window for the vulner conseq function It shows the

entry elds for the two needed arguments A template representation for the input

elds was chosen so that a user would not need to rememb er the order or number

of arguments required byeach function A user can also obtain a help window for

a selected function by using the help command in the main screen The help screen

contains a brief description of the function the arguments required and the usage

conseq function syntax Figure shows a help screen for the vulner

Op eration Description Notation

select Select all tuples that satisfy the select selection condition

selection condition from a rela R

tion R

Project Pro duce a new relation with only project attribute list R

some of the attribute of R and

remove duplicate tuples

union Pro duce a new relation that in R union R

 

cludes all tuples in R or R or

 

both R and R R and R must

   

b e union compatible

difference Pro duce a relation that includes R difference R

 

all the tuples in R that are not



in R



cartesian Pro duce a relation that has the R cartesian product R

 

product attributes of R and R and in

 

cludes as tuples all p ossible com

binations of tuples from R and



R



Table Op erations on Relations y Database Commands Screen ulnerabilit V Figure

Figure Function Interface

Figure Help Window

Integrity Constraints

In a relational database entity and referential integrity constraints must b e main

tained when creating mo difying or up dating relations to maintain the integrityof

stored information The referential and entityintegrity constraints in the vulnera

bility database were discussed in section and This section describ es how

these constraints are implemented in the database

EntityIntegrity Constraints

Entityintegrity constraints sp ecify that the primary key of a relation whichis

used to uniquely identify a tuple is always dened In the vulnerability database

entityintegrity constraints are explicitly sp ecied in the integrityconf le The

format of entries in the les is as shown b elow

vulnervulnerid

containsvulnerosvulnerid

osname

containspatchospatchnumber

patchinfopatchnumber

The name of the relation is followed by the elds that serve as the primary keys

This format allows more than one key to b e sp ecied in the integritycheck and allows

the maintainer to change the keys if desired The entityintegritycheckcanbeinv oked

every time a relation is created mo died or when a tuple is mo died or deleted from

the relation

The primary keys that are used in the database are

vulnerabilitynumb er For vulnerabilities obtained from a resp onse team the pri

mary key is the same as the unique identier used by a resp onse team to ad

vertise the vulnerabilityFor other vulnerabilities a unique numb er is assigned

to each vulnerability tuple

op erating system name The primary key for the op erating system entity is formed

by concatenating the name of the op erating system to its version numb er This

eld serves as a unique identier and also implicitly stores the version numb er

patchnumb er Patchnumb er is the same unique key used byvendors to identify a

distributed patch

Referential Integrity Constraints

Referential integrity constraints are sp ecied b etween tuples of two relations to

maintain consistency among the tuples In the vulnerability database referential

integrity constraints are explicitly sp ecied in the chkconf le The tuples that

have referential integrity constraints are sp ecied as

relationfieldA relationfieldB

In the instance shown fieldA in relation sp ecies a referential integrity constraint

on fieldB in relationAnychanges to fieldB in relation should b e reected

in fieldA in relation Referential integritychecks should b e invoked when tuples

in the relations are mo died deleted or up dated

Template Representation

The vulnerability database provides exibilitytochange elds in the tuples con

tained in the relations or to change the integrity constrain ts through an editable tem

plate representation The dierent elds of the tuples are sp ecied in the dbconf

le using a format shown b elow

vulnerability id source classification

The example ab oveshows a relation vulnerability that consists of three elds id

source and classication

The templates in dbconf are used by the database kernel routines when new

tuples are added mo died or up dated A template representation allows the main

tainer of the database to easily add or delete elds from the tuples The changes are

then reected in any subsequent Create Modify or Update op erations

Integrity constraints in the vulnerability database are also sp ecied as editable

templates This also allows maintainers to change primary keys add new keys or

change referential integrity constraints by simply editing the templates in the integrity

conguration les

Data Sources

Wehave started p opulating the vulnerability database with attacks that led to

a security compromise The information was gathered from advisories issued bythe

Computer Emergency Resp onse Team CERT information rep orted on an electronic

security mailing list and a survey of the literature At present the database contains

information on fourty nine known vulnerabilities These vulnerabilities have b een cat

egorized based on our taxonomy and include descriptions of howeachwas exploited

and the op erating systems that it was found in

In the following sections we present the implementation details of the vulnerability

database prototyp e

The prototyp e was develop ed to demonstrate that vulnerabilities from dierent

versions of Unix can b e classied in our taxonomy of faults

The three ma jor comp onents of the vulnerability database are

Database kernel

Vulnerability database interface

Userinterface

Each of the three comp onents are discussed in detail in the following sections

The information and data ow information b etween the three comp onents is shown in Figure

User Interface

Vulnerability Database Interface

Database Kernel

Physical Schema

Figure Vulnerability Database

Requirements Analysis

As part of the requirements analysis weidentied two ma jor uses for the vulner

ability database It can b e used to maintain uptodate security related information

ab out dierent op erating systems that can b e helpful to system designers and re

searchers Also the vulnerability information can b e used during security assessment

studies of op erating systems In the second phase of requirements analysis weasked

several p eople involved with securityrelated pro jects to comment on a small set of

queries we had prop osed We asked them to supplement the list with any additional

queries that may b e p erformed on the database We then constructed a small but

comprehensive set of queries that encompass a wide range of attributes The collec

tion of queries help ed us identify the information that should b e included in dierent

attributes of the data ob jects

Although the collection of vulnerabilities provided useful information some of

the queries were discarded and the attributes they accessed are not included in the

database For example a query ab out the time that a vulnerabilitywas intro duced

into the system cannot b e answered by using the stored information Similarly queries

ab out programming practices are not supp orted Such queries cannot b e answered

without access to program source co de program requirements functional sp ecica

tions and knowledge of the program developmentenvironment Furthermore such

queries are dicult to answer b ecause they require a qualitativeevaluation of infor

mation

The set of queries that can b e supp orted in the initial prototyp e of the database

is shown b elow

List all the vulnerabilities in system X

List all vulnerabilities in system X that o ccur b ecause of Y eg race condition

List all vulnerabilities which result in Z eg denial of service

Perform anycombination of b o olean op erations on and eg Y Z Y Z

Y Z

Given vulnerability V classify it

Given vulnerability V nd all systems that have this vulnerability

List all vulnerabilities in system X that will result in Z

List all systems that have a vulnerability that will cause Z

Given vulnerability V and system X what were or could have b een the con

sequence if exploited

Give a brief description of howVwas could have b een exploited

List any reference to vulnerability V in the literature

Give a description of the x for vulnerabilityV

List all patches applied to system X

For a vulnerability V are there any practical workarounds

For system X version Y what vulnerabilities have no supp orted patch

For all systems that have a vulnerability V list their version numb ers and

vendors

List any references to V in the literature

Some queries collected during requirements analysis are not supp orted b ecause they

require a qualitative analysis of the data For completeness these queries are also

shown b elow

Given vulnerability V and system X which part of the op erating system was it

found in

Do es patch P completely x a given vulnerability

What is the level of dicultyexp ertise required to patch vulnerabilityV

What is the initial accesssetup required to exploit vulnerability V eg requires

a user account requires access to p ort P

Given a co ding practice list all vulnerabilities resulting from this co ding prac

tice

Given V howcouldhave it b een prevented

For a class of vulnerabilityCwhichsoftware engineering practice P would have

prevented the intro duction of this vulnerability

Design Issues

The two ma jor factors that inuenced the design of our database were scalability

and ease of maintaining the integrity of information

A p o or design that did not scale could lead to degradation of p erformance waste

storage space and create problems in maintenance Even though p erformance was not

a critical factor in the design wekeep a resp onse time for the queries We paid partic

ular attention to ensure that little or no data replication to ok place Our initial design

was based on a hierarchical mo del but the MN relationships b etween the dierent

entities could not b e mo deled without data replication At that p oint a relational

schema was adopted that facilitated the representation of the MN relationships with less data replication

Maintenance of a large rep ository of information is a dicult task and it is not

clear if any particular organization scheme can makeitany easier Wehave identied

entityintegrity constraints as well as referential integrity constraints that should b e

helpful to maintain the integrity of the stored information

Database Kernel

Our vulnerability database is based on a relational schema mo del that consists

of b oth physical and conceptual entities These entities are represented as relations

tables in the mo del Relational algebra denes the op erations that can b e p erformed

on the the relations It also denes a set of basis functions suchthatany query in

the relational mo del can b e sp ecied only in terms of these functions The basis

functions in the relational mo del are select project union difference and

cartesian product

The vulnerability database kernel is comprised of the ve basis functions that

directly op erate on the physical schema In addition it also contains the following

functions

Create Creates a new relation in the database

Mo dify Mo dify all the elds of a tuple in a relation

Up date Change a sp ecied eld of a tuple in a relation

Delete Delete a tuple from a relation

Destroy Remove a relation from the database

The kernel also provides a layer of abstraction to the upp er level layers whichdo

not directly interface with the physical schema This enables us to restrict details of

the physical schema to the kernel functions

Representation of Relations

In the vulnerability database each relation is contained in a separate le Each

tuple in the relation is represented as a line of text where the dierent elds are

separated by a colon An instance of the op erating system relation is shown b elow

osunxsome vendor

osxnvendor

Vulnerability Database Interface

The database provides an interface to the physical schema through a set of kernel

functions All of the queries listed in Section can b e sp ecied using only the

kernel functions However this approach has two disadvantages First the underlying

details of the physical schema are exp osed to the user Second sp ecifying the queries

only in terms of the kernel functions b ecomes cumb ersome and exp oses details of

the physical schema As an alternative a separate layer of abstraction called the

vulnerability database interface is provided This layer provides a set of formbased

queries that interact with the kernel functions The set of queries currently supp orted

in the vulnerability database layer of the prototyp e are listed in Table

Query Interface Function

List all the vulnerabilities in system X list vulnerability sy stem

List all vulnerabilities in system X that o c vulner conseq

cur b ecause of Y v ul ner sy stem

List all vulnerabilities which result in Z list conseq conseq

Given vulnerability V classify it classify vulner

Given vulnerability V nd all systems that nd system vulner

have this vulnerability

List all vulnerabilities in system X that will vulner result

result in Y sy stem conseq

List all systems whichhave a vulnerability list systems sy stems

that will cause Y

Given vulnerability V and system X what conseq v ul ner sy stem

were or could have b een the consequence

if exploited

Give a brief description of howVwas exploit v ul ner

could have b een exploited

List any reference to V in the literature descr x v ul ner

Give a description of the x literature v ul ner

List all patches applied to system X patches to sy stem

For a vulnerability V are there any prac workaround v ul ner

tical workarounds

For system X version Y what vulnerabil nopatch sy stem

ities have no supp orted patch

For all systems that have a vulnerability sysinfo v ul ner

V list their vendors

Table Vulnerability Database Interface Functions

User Interface

A user can interact with our database either by using command line arguments

or through a graphical user interface The graphical interface was written using

the Tk to olkit Ous and provides a exible interface to the vulnerability database

functions All of the functions listed in Table can b e invoked through the interface

Figure shows the main commands screen that shows all the functions that

can b e invoked After a function has b een selected it maybeinvoked using the run

button This presents another windowwithentry elds for the needed arguments

Figure shows the dialogue window for the vulner conseq function It shows the

entry elds for the two needed arguments A template representation for the input

elds was chosen so that a user would not need to rememb er the order or number

of arguments required byeach function A user can also obtain a help window for

a selected function by using the help command in the main screen The help screen

contains a brief description of the function the arguments required and the usage

conseq function syntax Figure shows a help screen for the vulner y Database Commands Screen ulnerabilit V Figure

Figure Function Interface

Figure Help Window

Integrity Constraints

In a relational database entity and referential integrity constraints must b e main

tained when creating mo difying or up dating relations to maintain the integrityof

stored information The referential and entityintegrity constraints in the vulnera

bility database were discussed in section and This section describ es how

these constraints are implemented in the database

EntityIntegrity Constraints

Entityintegrity constraints sp ecify that the primary key of a relation whichis

used to uniquely identify a tuple is always dened In the vulnerability database

entityintegrity constraints are explicitly sp ecied in the integrityconf le The

format of entries in the les is as shown b elow

vulnervulnerid

containsvulnerosvulnerid

osname

containspatchospatchnumber

patchinfopatchnumber

The name of the relation is followed by the elds that serve as the primary keys

This format allows more than one key to b e sp ecied in the integritycheck and allows

the maintainer to change the keys if desired The entityintegritycheckcanbeinv oked

every time a relation is created mo died or when a tuple is mo died or deleted from

the relation

The primary keys that are used in the database are

vulnerabilitynumb er For vulnerabilities obtained from a resp onse team the pri

mary key is the same as the unique identier used by a resp onse team to ad

vertise the vulnerabilityFor other vulnerabilities a unique numb er is assigned

to each vulnerability tuple

op erating system name The primary key for the op erating system entity is formed

by concatenating the name of the op erating system to its version numb er This

eld serves as a unique identier and also implicitly stores the version numb er

patchnumb er Patchnumb er is the same unique key used byvendors to identify a

distributed patch

Referential Integrity Constraints

Referential integrity constraints are sp ecied b etween tuples of two relations to

maintain consistency among the tuples In the vulnerability database referential

integrity constraints are explicitly sp ecied in the chkconf le The tuples that

have referential integrity constraints are sp ecied as

relationfieldA relationfieldB

In the instance shown fieldA in relation sp ecies a referential integrity constraint

on fieldB in relationAnychanges to fieldB in relation should b e reected

in fieldA in relation Referential integritychecks should b e invoked when tuples

in the relations are mo died deleted or up dated

Template Representation

The vulnerability database provides exibilitytochange elds in the tuples con

tained in the relations or to change the integrity constrain ts through an editable tem

plate representation The dierent elds of the tuples are sp ecied in the dbconf

le using a format shown b elow

vulnerability id source classification

The example ab oveshows a relation vulnerability that consists of three elds id

source and classication

The templates in dbconf are used by the database kernel routines when new

tuples are added mo died or up dated A template representation allows the main

tainer of the database to easily add or delete elds from the tuples The changes are

then reected in any subsequent Create Modify or Update op erations

Integrity constraints in the vulnerability database are also sp ecied as editable

templates This also allows maintainers to change primary keys add new keys or

change referential integrity constraints by simply editing the templates in the integrity

conguration les

Data Sources

Wehave started p opulating the vulnerability database with attacks that led to

a security compromise The information was gathered from advisories issued bythe

Computer Emergency Resp onse Team CERT information rep orted on an electronic

security mailing list and a survey of the literature At present the database contains

information on fourty nine known vulnerabilities These vulnerabilities have b een cat

egorized based on our taxonomy and include descriptions of howeachwas exploited

and the op erating systems that it was found in

SECURITY FAULT DETECTION TECHNIQUES

In Chapter we discussed a classication scheme for security faults in Unix The

motivation b ehind the classication was to classify faults unambiguously into dierent

categories and use them for data organization The fault categories were used as the

basis for data organization in the design of a vulnerability database The design and

implementation of the database was discussed in Chapter As another application

of our fault classication scheme wehave also identied software testing techniques

that may b e used to detect faults in each category

In our taxonomy of faults errors that share a common characteristic are classied

in the same categoryFor example synchronization errors share a common metho d

of exploitation the relative ordering of an op eration sequence can b e used to breach

securityFaults in the condition validation category result from missing or incomplete

condition checks Conguration errors are op erational faults that o ccur when software

is adapted to a new environment after it has b een develop ed Environmental errors

are op erational dep endent faults that manifest themselves when software is executed

in a particular execution environment

In the following sections we present a brief description of dierentsoftware test

ing techniques In Sections through we presentasynthesis of these testing

techniques and discuss their application to security faults

Static Analysis

Static analysis techniques do not require execution of the software These tech

niques rely on insp ection of requirements and design do cuments co de walkthroughs

and formal metho ds of verication to detect co ding errors in a program DMMP

Static analysis may b e p erformed manually or the pro cess can b e automated by using

an analysis to ol

A ma jor limitation of static analysis involves array references and p ointer variables

as the values referenced cannot b e distinguished DM Exp erimental evaluation

of co de insp ections and walkthroughs have shown these metho ds to b e eectivein

nding to of logic design and co ding errors in typical programs Mye

Various static analysis techniques suchascodewalkthroughs insp ection of design

and sp ecication do cuments and formal metho ds of verication were also used in the

design of secure op erating systems MD PKKe These systems provided prova

ble securityandwere formally demonstrated to conform to the security requirements

Symb olic Testing

In symb olic testing of programs input data and output values are assigned sym

b olic values that may b e elementary symbolic values or expressions DMMP The

p ossible executions of a program are characterized by an execution tree The exe

cution of a program during symb olic testing is p erformed by a symb olic evaluator

that consists of an expression simplier and a symbolic interpreter Symb olic testing

has b een used in several symbolic evaluation and program pro of systems Howden

How studied the eectiveness of symb olic testing and rep orted that fteen out

of twentytwo errors rep orted in a program may p ossibly b e detected bysymbolic

testing

Symb olic testing can b e used to prove the correctness of a program If a program

under test is viewed as a nite set of assertiontoassertion paths the program is

b olic testing has problems shown to b e correct if each path is correct DMMP Sym

if a program contains lo ops or arrayvariables The limitations of symb olic testing

b ecause of lo ops and arrayvariables do es not present itself as an attractivechoice to test complex op erating system source co de

Path Analysis and Testing

Path analysis testing involves the selection of test data cases to execute chosen

paths DMMP A test case is constructed bycho osing one test p oint from each

execution path of the program This approach exercises all the p ossible paths through

a program at least once But practical and economical limitations restrict path testing

to cho osing only a subset of all p ossible paths Path testing is meant to detect

computation path selection and missing path errors How A computation error

o ccurs when a computation statement along a path is computed incorrectly A path

selection error o ccurs when the predicates in a conditional construct are incorrect

Missing path errors result from missing predicates in the condition construct Path

analysis testing can b e used in conjunction with domain analysis to design test cases

Domain testing is intended to detect path selection errors on or near the b oundary

of a path domain DM

Control structure testing is a path coverage testing technique that exercises all the

p ossible outcomes of a condition construct Control structure testing is divided into

condition testing data ow testing and lo op testing Condition testing fo cuses on the

condition expressions in a program Data ow testing selects paths of the program

according to the use and denition of variables Lo op testing fo cuses exclusively on

the validity of lo op constructs in a program We will explore condition testing in

more detail and present it as a p ossible detection technique for condition validation

errors Condition testing is further rened into the following typ es of testing

Branch Testing Branch testing is the simplest control testing technique and involves

evaluating the true and false branchofevery conditional branch at least once

Mye

Branch and Relational Operator Testing BRO Branch and relational op erator test

ing guarantees the detection of branch and relational op erator errors in a condi

tion provided that all b o olean variables and relational op erators in the condition

o ccur only once and have no common variables T ai BRO uses condition

constraints on a simple condition A condition C has constraints D D

 

D where D is a symb ol sp ecifying a constraint on the outcome of the ith

n i

simple condition in C A condition constraint D for condition C is covered by

an execution of C if during this execution of C the outcome of each simple

condition in C satises the corresp onding constraintinD

For example consider a condition of the form

C B E E

  

where B is a b o olean expression and E and E are arithmetic expressions

  

Assuming short circuit evaluation of b o olean op erands the constraint set for this

condition is ftrue falsetruetrueg Otherwise the constraint

set would also include ffalse falseg Coverage of the constraintset

guarantees that all b o olean and relational op erator errors in C will b e detected

It should b e noted that condition testing can only reveal problems with evaluating

conditions and the corresp onding results It cannot detect missing condition con

structs In addition to test cases that are used in control structure testing test cases

should also b e designed to detect missing condition checks

Functional Testing

In functional program testing the design of a program is viewed as an abstract

description of its design and requirements sp ecications DMMP The ob jectiveis

to nd out when the inputoutput b ehavior of the program do es not agree with its

sp ecications Functional testing enables us to derive test cases that fully exercise

all functional requirements for a program Functional testing attempts to nd the

following errors in a program Pre

incorrect or missing functions

interface errors

errors in data structures

p erformance errors

initialization and termination errors

It is rep orted that functional testing exp osed thirtyeightofthefortytwoknown errors

in the release of a ma jor software package DMMP In the following sections we

present a functional testing technique and a test case design technique that can b e

used in conjunction with functional program testing These fault detection techniques

can b e used to detect condition validation errors

Boundary value analysis BVA is a technique for designing test cases to uncover

b oundary value errors Mye It provides guidelines for complete b oundary testing

and derives tests from b oth input and output domains Boundary value analysis can

b e used to derive test cases to detect missing or incorrectly sp ecied limit checks

for system resources and staticsized data structures The guidelines provided for

b oundary value analysis are as follows

If an input condition sp ecies a range b ounded byvalues a and b test cases

should b e designed with values a and b just ab ove and just b elow a and b

resp ectively In addition extreme values at b oth the high and low end should

also b e considered to ensure that those conditions are handled prop erly

If an input condition sp ecies a number of values test cases should b e develop ed

that exercise the minimum and maximum numb ers Values just ab ove and just

b elow are also tested

Apply guidelines and to output conditions

If internal program data structures have prescrib ed b oundaries test cases should b e designed to exercise those b oundaries

Syntax Testing

Syntax testing is a functional testing technique in which the ob ject under test is

treated as a blackbox that can accept certain inputs reject others and pro cess some

Syntax checking can b e p erformed as part of the system functional test or as part of

the acceptance test The primary ob jectiveofthistechnique is not to establish the

correctness of the system under test but to establish that the system is not vulnerable

to illformatted input Beizer Bei has summarized the ob jective of syntax testing

as follows

The element do es not fail when sub jected to bad inputs

The element do es not cause another element to fail even though it do es not fail

itself when sub jected to bad inputs

The element do es not corrupt the database when sub jected to bad inputs even

though it do es not fail itself

The element rejects all bad inputs and accepts all go o d inputs

It p erforms the correct pro cessing on go o d inputs

Some of the errors that can result from improp er input validation are outlined

below Test cases should b e designed to check for these errors in the implementation

High level syntax errors Violations in the syntax sp ecication through inap

propriate combination of elds

Fieldsyntax errors Syntax errors asso ciated with a eld

Delimiter errors Violation of the rules governing the placement and the typ e

of characters that must app ear as separators b etween elds These include

missing delimiter wrong delimiter not a delimiter and to o many delimiters

Fieldvalue errors Errors that o ccur b ecause of the contents of a eld These

include b oundary values and excluded values

Syntaxcontext errors There is a p ossibility of an error when the contents of a

eld dictate the content of subsequent elds

Fieldvalue correlation errors The contents of two or more elds are correlated

by a functional relation b etween them and there may not b e full freedom in

picking their values

Statedep endency errors The p ermissible syntax andor eld value is condi

tional on the state of the system or the routine

Syntax checking should b e p erformed on at least the following mo dules as they

handle a ma jor p ortion of the input that enters the system

All userinterface programs including terminal device input routines

All communication proto cols programs that accept user input

Internal interface routines that call sup ervisor routines

Dedicated data validation routines and mo dules

Mutation Testing

Strictly sp eaking mutation testing is not a testing technique but a technique

for measuring the adequacy of test data DMMP A brief overview of mutation

testing from DM is presented here A more detailed discussion can b e found in

Bud DMMP

Assume P is the program under test P is the correct version of the program and

c

is the same as P if P is correct T is the set of test cases on which P is b eing tested

and D is the domain of P such that P D The correctness of P is assumed relative

c

to some set of sp ecications Mutation analysis relies on a set F of faults Given a

program P b eing tested each of the faults in F is intro duced into P one by one By

intro ducing a fault into P a slightly dierent program known as the mutant of P is

pro duced Mutating P using all the elements of F results in a set M of mutants A

mutant M is kil led if its b ehavior is dierent from P when M Mis executed against

a test case t TIfM cannot b e killed byany t T it could b e b ecause

M is equivalentto P and will always b ehaveidentical to P on all t D

or

there exists a test case t T but t D for which M behaves dierentthan P

Mutation testing requires knowledge of the implementation language to design the

language dep endentmutants

In the following sections we present an analysis of the dierent fault detection

metho ds outlined earlier and discuss howeach metho d can b e used to detect the

dierent fault typ es in our classication scheme

Condition Validation Errors

In our classication scheme we identied vetyp es of faults that can result when

a condition is not b eing evaluated prop erly The four subcategories of condition

validation faults are b oundary condition errors input validation errors access right

validation errors origin validation errors and failure to handle exceptional conditions

In the following sections we present software testing techniques that can b e applied

to detect faults in each category

Boundary Condition Errors

Boundary condition errors can b e detected by using b oundary value analysis

BVA to design test cases for functional testing of mo dules BVA ensures that

the test cases exercise the b oundary conditions that can exp ose b oundary condition

errors in the mo dule under test Mye

In addition to functional testing mutation testing can also b e used to detect

b oundary conditions by designing appropriate language dep endentmutants For in

stance Agrawal et al ADHe describ e a C language mutant for checking b oundary

conditions in scalar variables For a statementsuch as

pab

The mutants that are generated consist of

p a b

and

pab

These mutants are killed if they cause an overow or underow in the program

Path analysis testing in conjunction with domain analysis can b e applied to detect

b oundary condition errors Domain analysis has b een studied with twovariables and

examined with three variables JK ADJ The main disadvantage of domain testing

is that it can only b e applied to a small number of variables as the diculty of selecting

test cases b ecomes increasingly complex In an exp erimentbyHowden path analysis

revealed the existence of one out of three path selection errors How

Input Validation Errors

Input validation errors result when a functional mo dule fails to prop erly validate

the input it accepts from another mo dule or another pro cess Failure to validate the

input may cause the mo dule accepting input to fail or it may indirectly cause another

interacting mo dule to fail

Syntax testing can b e used to verify that functional mo dules that accept input

from other pro cesses or mo dules do not fail when presented with illformatted input

Syntax testing was describ ed in Section including test case scenario that should

b e tested

Path analysis and testing can b e applied to detect scenarios where a certain ex

ecution path maybechosen based on the input In an exp eriment conducted by

Howden path testing revealed the existence of nine out of twelve computation errors

Symb olic testing and static analysis are not viable choices for detecting input

validation errors Most of the input validation errors result from input received during

runtime This observation do es not favor using symb olic or static testing as an

attractivechoice to detect input validation errors

Access RightValidation Errors

Access validation errors result when a sub ject is allowed to invoke an op eration on

an ob ject outside its access domain In most programming languages these conditions

are co ded as conditional constructs and an execution path is chosen based on the

outcome of the evaluated condition An improp erly sp ecied condition can lead to

an incorrect execution path that can invalidate the access rightcheck

Path analysis can b e used to detect errors that result from incorrectly sp ecied

condition constructs Branch and Relational Op erator testing BRO is a test case

design techniques that can aid in the design of test cases that can exp ose access

validation errors

In programming languages where access validation checks are co ded as conditional

constructs mutation testing can also b e used to detect these errors Mutants can b e

designed to provide condition analysis for conditional constructs In the C program

ming language twomutants can b e created for an if statement as follows ADHe

For the statements if e S the twomutants are

ve if trap on truev S

ve if trap on falsev S

When trap on truefalse is executed the mutant is killed if the function

gumentvalue is truefalse If the value if not truefalse then the mutants continue

execution

The ab ove mentioned mutants only provide partial coverage for the if statement

Toprovide complete coverage in the case of statements of the form if c S else



S the mutants needed to provide complete coverage are



on statement else S if c trap 

if c S else trap on statement



These twomutants are equivalenttoproviding branchcoverage and encourage test

cases to b e designed such that each branch is executed at least once

Origin Validation Errors

If a system do es not prop erly authenticate a user or pro cess it mayallow unau

thorized sub jects to access the system Similarly if a program do es not prop erly

authenticate the shared data or libraries it maybefooledinto using mo died data

that can lead to a security breach

It is a dicult task to verify that a system is not vulnerable to identity compromise

attacks We are not aware of any fault detection technique that can b e employed to

exp ose origin validation errors To ensure that a system prop erly authenticates its

users we can apply formal metho ds of verication to ensure that the implementation

adheres to the security requirements and also ensure that the underlying proto col

do es not contain anyweaknesses that may b e exploited

Failure to Handle Exceptional Conditions

A security breach can b e caused if a system fails to handle an exceptional condi

tion This can include unanticipated return co des and failure events

Static analysis techniques such as insp ection of design do cuments co de walk

throughs and formal verication of critical sections can b e used to ensure that a

system can gracefully handle anyunanticipated event

Path analysis testing can also b e p erformed on small critical sections of co de to

ensure that all p ossible execution paths are examined This can reveal problems that

may not have b een anticipated by the designers or overlo oked b ecause of complexity

Environment Errors

Enviromental errors are dep endent on the op erational environment which makes

them dicult to detect Spa It is p ossible that these vulnerabilities manifest

themselves only when the software is run on a particular machine under a particular

op erating system or a particular conguration

As environment errors are dep endent on the runtime conditions a static analysis

of the co de cannot detect these faults The underlying mo dules and algorithms may

even b e formally demonstrated to b e correct yet the program fails to function correctly

on a sp ecic set of input Spa

Spaord Spa used mutation testing to uncover problems with integer overow

and underow Mutation testing can b e used to design test cases that exercise a

sp ecic set of inputs unique to the runtime environment Path analysis and testing

can also b e applied to sections of the co de to ensure that all p ossible inputs are

examined

Synchronization Faults

In our fault classication scheme synchronization faults are intro duced b ecause

of the existence of a timing windowbetween two op erations or faults that result from

improp er or inadequate serialization of op erations One p ossible sequence of actions

that mayleadtoasynchronization fault can b e characterized as KS

A pro cess acquires access to an ob ject to p erform some op eration

The pro cesss notion of the ob ject changes indirectly

The pro cess p erforms the op eration on the ob ject

Mutation testing can b e used to detect synchronization faults in a program To

detect faults that are intro duced by a timing windowbetween two op erations a

trap on execution mutant can b e placed b etween these two op erations The mutant terminates execution of the program if certain sp ecied conditions are not satised

For instance a timing windowbetween the access p ermission checks and the actual

logging in xterm could b e exploited to compromise security CAa A mutant for

this vulnerability could b e designed that terminated execution thus killing the mutant

if the access checks had b een completed This mutant could b e placed b etween the

access checks and the logging to detect the race condition

Mutants can also b e designed to detect improp er serialization op erations Con

sider a set of n statementthatmust b e executed sequentially to ensure correct op

eration We assume that the statements do not contain any instructions that break

the sequential lo ckstep execution We can design n mutants that rearrange

the order of the n execution statements These mutants are killed when the mutated

program pro duces a dierent result than the original program

Other software testing techniques we discussed earlier cannot b e applied to detect

synchronization errors The emphasis of path analysis is to provide coverage that

ensures that all p ossible execution paths through a program are executed at least

once This would not detect synchronization errors that dep end on relative timing

and serialization of op erations Timing errors and improp er serialization are detected

byintro ducing faults in the co de as in mutation testing

Static analysis is not a viable option b ecause synchronization errors dep end on

the runtime conditions

Conguration Errors

Conguration errors may result when software is adapted to new environments

or from a failure to adhere to the security p olicy Conguration errors comprise of

faults intro duced after software has b een develop ed and are faults intro duced during

the maintenance phase of the software lifecycle

A static audit analysis of a system can reveal a ma jority of conguration errors

Among the various software testing techniques discussed static analysis is the most

eective in detecting conguration errors The other testing techniques we discussed

fo cus on detecting co ding faults and would not b e eective in exp osing conguration

errors The static audit of a system can b e automated by using static audit to ols

suchasCops FS and Tiger SSH that search a system for known avenues of

p enetration

Using Cops as an example we illustrate the typ es of conguration errors that

can b e detected Cops contains the following checks to detect security faults that

led to a compromise of a system FS

dircheck lechk Check a list of sp ecied directories and les to ensure that they

are not worldwritable Typically this list includes etcpasswd profile

etcrc bin usradm etc These checks ensure that critical les

and directories do not have incorrect p ermissions that violate a security p olicy

passchk This checks for p o or password choices This includes user name common

words and login identiers This is to prevent brute force attempts to crack

passwords

groupchk passwdchk These check etcpasswd yypasswd etcgroupsand

ypgroup for the validityofcontents and a varietyofknown problems including

blank spaces null passwords and nonstandard elds

cronchk rcchk These checks ensure that an intruder cannot run a program with

ro ot privileges at system startup bychecking that les referenced in etcrc

are not world writable

ks that devkmem devmem etcfstab are not world read devchk This chec

able or writable If the p ermissions are not set correctly it allows an intruder

to read or write directly from a device

homechk userchk These checks ensure that each users home directory and ini

tialization les are not worldwritable These checks are intended to preventan

individual users account b eing sab otaged byanintruder

ro otchk This checks ro ot startup les for incorrect umask settings and search paths

containing the current directory This ensure that les owned by the sup eruser

are created with the correct p ermissions

suidchk This program checks for changes in SUID le status on a system This

is to prevent a system from several known p enetration attacks that result from

information ow problems

kuang This is an exp ert system written by Rob ert W Baldwin of MIT This checks

if a given users account can b e compromised based on a set of rules

The checks we describ ed ab ove can detect manyoftheknown conguration errors

These checks should b e up dated as new conguration errors are discovered The

vulnerability database describ ed in chaptercanbeusedtokeep the set of checks

current As new conguration errors are added to the database information ab out

fault characteristics can b e extracted and used to write new checks for the audit to ols

Summary

Table shows a summary of dierentsoftware testing metho ds that can b e used

to detect dierenttyp es of faults We use to denote that the technique should

b e eective and has b een demonstrated to detect faults with similar characteristics

A denotes that the technique cannot eectively b e used A denotes that the

testing metho d can b e eective and a quantitativestudymay b e p erformed as part

of the future work

Errors Functional Path Static Mutation

Testing Analysis Analysis Testing

Boundary condition

Input validation

Access right

Origin validation

Failure to

handle exceptions

Environment

Race condition

Serialization

Conguration

Table Comparison of Dierent Software Testing Metho ds

CONCLUSIONS AND FUTURE WORK

The main contribution of this thesis is the security fault classication scheme for

the Unix op erating system Our classication scheme allows us to categorize distinctly

each security fault according to the sp ecied criteria This distinguishes our taxonomy

from other classication schemes that do not explicitly sp ecify the memb ership criteria

for the faults To demonstrate the applicability of our classication scheme we used

it as a basis for the design of a vulnerability database The database was used to

store security faults found in dierentversions of Unix This database can b e used

in conjunction with an intrusion detection system or a static audit to ol to search for

known avenues of p enetration Furthermore we used the fault categories to identify

software testing metho ds These metho ds can b e applied during the test phase of the

software lifecycle or can b e used during a p enetration analysis

Traditionally testing fo cused on proving the functional correctness of software

Little or no imp ortance was given to security testing Personnel who maintained a

system were also resp onsible for its security Some sites used p enetration analysis to

uncover existing security vulnerabilities But a ma jority of computer sites could not

aord a comprehensive p enetration analysis and vulnerabilities went unnoticed until

they had led to a security compromise

Co ding faults can b e detected by adequate testing Thus security compromises

that resulted by exploiting such faults could have b een prevented if the faults were

detected and xed during the developmentcycleTo develop more reliable systems

more emphasis should b e placed on security testing and system testing metho ds

should b e designed to detect security faults

As part of the future work wemay extend our classication scheme to other

mo dern op erating system Many mo dern systems are based on a software architecture

that is dierent from Unixs structure These include microkernels ob jectoriented

and distributed op erating systems The criteria used in our taxonomy do not rely

on implementation details and are designed to encompass general characteristics of a

fault Also our existing categories can b e extended to include faults that cannot b e

classied into existing categories We b elieve that these factors would enable us to

extend our classication scheme to include faults in various op erating systems

Another area for future work maybetoevaluate the software testing metho ds on

dierent op erating systems This would provide quantitative data on the eectiveness

of each metho d These metho ds mayalsobeusedtodevelop a testsuite that can b e

used to measure the secureworthiness of dierent systems Using this suite it may

b e p ossible to develop a set of metrics that can b e used for security certication of

dierent systems BIBLIOGRAPHY

BIBLIOGRAPHY

A RP Abb ott et al Security Analysis and Enhancements of Computer

Op erating Systems Technical Rep ort NBSIR Institute for Com

puter Science and Technology National Bureau of Standards

ADHe H Agrawal R DeMillo R Hathaway and et al Design of Mutant Op

erators for the C Programming Language Technical Rep ort SERCTR

PSoftware Engineering ResearchCenter Purdue University

ADJ DeMillo R A Ho cking E D and Meritt M J A Comparison of Some

Reliable Test Data Generation Pro cedures Technical rep ort Georgia

Institue of Technology

AMP CR Attansio P W Markstein and R J Phillips Penetrating an op er

ating system a study of VM integrity IBM Systems Journal pages

And J P Anderson Computer securitytechnology planning studyTechnical

Rep ort ESDTR USAF Electronic Systems Div

Bei Boris Beizer Software Testing Techniques Electrical Engineer

ingComputer Science and Engineering Series Van Nostrand Reinhold

BH R Bibsey and D Hollingworth Protection analysis pro ject nal rep ort

Technical Rep ort ISIRR Institue of Information Sciences Univer

sity of Southern California

Bis Matt Bishop Analyzing the Security of an Existing Computer System

IEEE Fall Joint Computer Conference Novemb er

BP V Basili and Barry T Perricone Software Errors and Complexity An

Empirical Investigation Communications of the ACM Jan

uary

BPC Richard Bibsey Gerald Pop ek and Jim Carlstead Inconsistency of a

single data value over time Technical rep ort Information Sciences Insti

tuteUniversity of Southern California December

BR Victor R Baisli and H Dieter Rombach Tailoring the Software Pro cess

to Pro ject Goals and Environments In Proceedings of the th Interna

tional Conference on Software Engineering pages IEEE Press

BS Lub omir Bic and Alan Shaw The Logical Design of Operating Systems

Prentice Hall

Bud TA Budd Mutation Analysis of Program Test Data PhD thesis Yale

UniversityMay

CA CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAa CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAb CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAa CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAb CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAa CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CAb CERT advisory CA Computer Emergency Resp onse Team Advi

sory

CA CERT advisory CA Computer Emergency Resp onse Team Advi

sory

Car Jim Carlstead Serialization Protection errors in op erating systems

Technical rep ort Information Sciences Institute University of Southern

California April

CBP Jim Carlstead Richard Bibsey I I and Gerald Pop ek Patterndirected

protection evaluation Technical rep ort Information Sciences In

stitueUniversity of Southern California June

Com Douglas E Comer Internetworking with TCPIP Prentice Hall

CPRZ L A Clarke A Po dgruski D J Richardson and S Zeil AFormal

Evaluation of Data FlowPath Selection Criteria IEEE Transactions on

Software Engineering Novemb er

Den Dorothy Denning Cryptography and Data Security AddisonWessley

Publishing Company

DGM A Dniestrowski J M Guillaume and R Mortier Software Engineering

in Avionics Applications In Proceedings of the rd International Con

ference on Software Engineering pages IEEE Press

Dis A V Discolo BSD Unix Security Technical rep ort Universityof

California Santa Barbara

DM Richard A DeMillo and AdityaP Mathur On the Use of Software

Artifacts to Evaluate the Eectiveness of Mutation Analysis for Detecting

Errors in Pro duction Software Technical rep ort Software Engineering

ResearchCenter Purdue University SERCTRP March

DMMP Richard A DeMillo W Michael McCracken R J Martin and John F

Passaume SoftwareTesting and Evaluation The BenjaminCummings

Publishing Company Inc

EN R Elmasri and S B Navathe Fundamentals of Database SystemsThe

BenjaminCummings Publishing Comany Inc

End A Endres An analysis of errors and their causes in system programs

IEEE Transactions on SoftwareEngineering SE

ker FS Daniel Farmer and Eugene H Spaord The COPS Security Chec

System Technical Rep ort CSDTR Software Engineering Research

Center Purdue University September

GJM Carlo Ghezzi Mehdi Jazayeri and Dino Mandrioli Fundamentals of

Software Engineering Prentice Hall

Gla Rob ert L Glass Persistentsoftware errors Transactions on Software

Engineering SE March

GS Simson Garnkel and Eugene Spaord Practical Unix Security OReily

and Asso ciates

H B Hebbard et al A p enetration analysis of the Michigan terminal sys

tem ACM SIGOPS Operating System Review

Hal Anthony Hall Seven myths of formal metho ds IEEE Software pages

September

HB Dennis Hollingworth and Richard Bibsey I I Allo cationdeallo cation

residuals Technical rep ort Information Sciences Institute University of Southern California June

How W E Howden ReliabilityofthePath Analysis Testing Strategy IEEE

Transactions on Software Engineering SE

How W E Howden An Evaluation of the Eectiveness of Symb olic Testing

SoftwarePractice and Principle JulyAugust

Howa William E Howden A survey of dynamic analysis metho ds Tutorial

SoftwareTesting Validation pages

Howb William E Howden A survey of static analysis metho ds Tutorial

SoftwareTesting Validation pages

HSP David K Hess David R Saord and Udo W Pooch A Unix Network

Proto col Security Study Network Information Service Technical rep ort

TexasAMUniversity

IEE IEEE ANSIIEEE Standard Glossary of Software Engineering Termi

nology IEEE Press

ISV DaveIcove Karl Seger and William VonStorch Computer Crime A

Crimeghters Handbook OReilly Asso ciates Inc

JK White L J and Cohen E K A Domain Strategy for Computer Program

Testing IEEE Transactions on Software Engineering May

X SoftwarePracticeandExperience Knu DE Knuth The Errors of T

E

KS Sandeep Kumar and Eugene Spaord APattern Matching Mo del for

Misuse Intrusion Detection In th National Computer Security Confer

ence

L Carl Landwher et al A taxonomy of computer program securityaws

Technical rep ort Naval Research Lab oratoryNovemb er

Lin Richard Linde Op erating system p enetration In National Computer

Conference pages

Lip M Lip ow Prediction of Software Failures Journal of Systems and Soft

ware

Mar Brian Marick Asurvey of software fault surveys Technical Rep ort

UIUCDCSR University of Illinois at UrbanaChampaign De

cemb er

MB R W Motley and W D Bro oks Statistical Prediction of Programming

Errors Technical Rep ort RADCTR

MD EJ McCauley and PJ Drongowski KSOS The design of a secure

op erating system National Computer Conference

Mye Glenford J Myers SoftwareReliability WileyInterscience

Mye G Myers The Art of SoftwareTestingWiley

Ous John K Ousterhout Tcl and Tk Toolkit Addison Wesley Publishing

Company

OW Thomas J Ostrand and Elaine J Weyuker Collecting and Categorizing

Software Error Data in an Industrial Environment Journal of Systems

and Software

PAFB D Potier JL Albin R Ferrol and A Bilo deau Exp eriments with

Computer Software Complexity and Reliability In Proceedings of the th

International Conference on SoftwareEngineering pages IEEE

Press

PKKe G J Pop ek M Kamp e C S Kline and et al UCLA Secure Unix In

Proceedings of the National Computer Conference pages

Pre Roger Pressman Software Engineering A Practitioners Approach Mc

Graw Hill Inc Third edition

RDB R J Rub ey J A Dana and PWBiche Quantitative asp ects of

are validation IEEE Transactions on Software Engineering SE softw

Rub Raymond J Rub eyQuantitative Asp ects of Software Validation SIG

PLAN Notices SE May

SB ML Scho oman and MI Bolsky Typ es Distribution and Test and

Correction Times for Programming Errors In Proceedings of the

International ConferenceonReliable Software

Sch W L Schiller The Design and Sep cications of a Security Kernel for the

PDP Technical Rep ort ESDTR THE MITRE Corp oration

SchaRRSchell Computer Security the Achilles Heel of the Electronic Air

Force Air University Review

Schb N F Schneidewind Software metrics for aiding program development

debugging In National Computer Conference

Sch Christoph Schuba Addressing Weaknesses in the

Proto col Masters thesis Purdue University

SCS M D Schro eder D D Clark and J H Saltzer The MUTLICS Kernel

Design Pro ject ACM Operating Systems Review

Spa Eugene H Spaord Crisis and Aftermath Communications of the ACM

June

Spa Eugene H Spaord Extending Mutation Testing to Find Environmental

Bugs SoftwarePractice and Principle Feb

SSH David R Saord Douglas Lee Schales and DavidKHessTheTAMU

securitypackage In Edward Dehart editor Proceedings of the Security

IV Conference pages

Tai K C Tai What to do b eyond branch testing ACM Software Engineer

ing Notes April

WB David M Weiss and Victor R Basili Evaluating Software development

by Analysis of Changes Some Data from the Software Engineering Lab

oratory IEEE Transactions on Software Engineering SE

February

web Websters New World Dictionary of Computer Terms Websters New

World New York

Wil A L Wilkinson et al A p enetration analysis of a Burroughs large system

ACM SIGOPS Operating System Review

Wit Carol Withrow Error Density and Size in Ada Softw are IEEE Software

January

Y Shen YuetalIdentifying ErrorProne Software An Empirical Study

Transactions on Software Engineering SE April

YT Michal Young and Richard N Taylor Rethinking the TaxonomyofFault

Detection Techniques Technical rep ort Software Engineering Research

Center Purdue University September

Zwa Vladmir Zwass Management Information Systems Dubuque Wm C

Brown APPENDICES

App endix A

Description of Software Fault Studies

BR Basili and Rombach rep ort on software faults in pro jects characterized by

high co de reuse established pro cesses and high turnover among programmers

Gla Glass surveyed faults eachfromtwosoftware systems for military air

craft The rst was co ded in instructions and was built by pro

grammers The second system had instructions and was built by

programmers All the faults were rep orted after delivery of the software

DGM Dniestrowski et al describ e a digital ightcontrolavionics real time sys

tem The system contained lines of co de written in LTR a sp ecial high

level language and assembly

OW Ostrand and Weyuker rep ort on faults discovered during the develop

ment and system testing of an interactive sp ecialpurp ose editor co ded in

lines of a highlevel language and lines of assembly

Rub Rub ey rep orts on faults found from over a dozen validation eorts The

system included in the study were small commercial realtime control programs

BP Basili and Perricone discuss faults in a lines Fortran pro ject The

system was general purp ose program for satellite planning studies It was char

acterized by rapidly changing requirements and by co de and design reuse

Y Shen et al describ e faults discovered after release of software in three dier

en t programs a metric calculation to ol written in Pascal a compiler in PLS

and a database system written primarily in assembly

App endix B

ATaxonomyofUnixVulnerabilities

Synopsis lpr can b e used to delete or create any le on the system lpr

s allows users to create symb olic links to lp ds sp o ol directory After

invo cations lpr will reuse les in the sp o ol directory and followthe

previously installed link

Source lgm advisory

Op erating System SunOS or earlier BSD BSD NET derived

systems AUX

Classication Condition validation error check for origin

Synopsis If an access list of hosts in etcexports is longer than charac

ters or if the cached list of netgroups exceeds the cache capacity then the

lesystem can b e mounted byany user

Source CERT advisory CA

Op erating System SunOS on Sun and Sun

Classication Condition validation error check for limit

Synopsis In systems that used delivermail the mail message could b e

app ended to the le by sending mail to the lename instead of a user This

could b e used to create an arbitrary entry in etcpasswd

Source See Bis

Op erating System BSD systems that used delivermail

Classication Condition validation error check for origin destination

Synopsis It is p ossible to lo ck the password le and preventany user from

changing hisher password

Source security distribution list

Op erating System BSD and derived systems

Classication Condition validation error check for limit

Synopsis rcp can b e exploited byan y trusted host in etchostsequiv or

rhosts

Source CERT advisory CA

Op erating System SunOSx

Classication Condition validation error check for origin

Synopsis Any user can gain ro ot access to a machine running HPs NIS

ypbind

Source CERT advisory CA

Op erating System Any system running HPs NIS ypbind

Classication Condition validation error check for origin

Synopsis A system running NISRPCUDP can b e p enetrated by generating

a fake etcpassword entry in resp onse to a NIS client request

Source See HSP

Op erating System Systems running NISRPCUDP

Classication Condition validation error check for origin

Synopsis A vulnerability in Ma jordomo software allows users access to the

system without authentication

Source CERT advisory CA

Op erating System Any system running Ma jordomo up to and including ver

sion

Classication Condition validation error check for origin

Synopsis usretcmodload and OPENWINDOWSbinloadmodule can b e ex

ploited to execute a users program using the eectiveidofroot

Source CERT advisory CA

Op erating System SunOS c

Classication Condition validation error check for access rights

Synopsis TIOCCONS can b e used to redirect console inputoutput away

from console regardless of the p ermissions on the terminal device

Source CERT advisory CA

Op erating System SunOS

Classication Condition validation error check for access rights

execc takes the text and Synopsis Implementation of usrsyssyskern

data sizes in the header of the le b eing execd to b e true This can cause a

security breach when a program with a large datasize causes a coredump

Source Security distribution list

Op erating System BSD

Classication Condition validation error check for limits

Synopsis The password le reading routines use fgets to read a string of

input These routines do not prop erly check if the last line was completely

read This can b e used to create a b ogus entry in the password le

Source Security distribution list

Op erating System BSD

Classication Condition validation error check for input syntax

Synopsis Setting the stack size on a Sun causes a coredump and crashes

the system The problem o ccurs b ecause the input is parsed incorrectly

Source Security distribution list

Op erating System Sun systems

Classication Condition validation error check for input

Synopsis The xterm emulator denes some escap e sequences that can b e

sent to a users terminal via a mail message This can b e used to invoke

arbitrary commands on another users terminal

Source Security distribution list

Op erating System Systems running X windows version release and

Classication Environment error interaction b etween functionally correct

mo dules

Synopsis rdist uses popen to execute sendmail as ro ot It can b e

made to execute arbitrary programs as ro ot

Source lgm advisory

Op erating System SunOS or earlier AUX BSD NETDerived

systems

Classication Condition validation check for origin of sub jectprogram

Synopsis In version Unix if su could not op en the password le it would

create a shell with the eective and real gid of ro ot and grant ro ot privileges

to the user

Source Unreferenced source

Op erating System Unix version

Classication Condition validation check for limits

Synopsis A vulnerability in NCSA HTTP daemon allows remote users access

to the account under which httpd is running

Source CERT advisory CA

Op erating System Systems running NCSA HTTPD v ersion up to and includ

ing version

Classication Condition validation check for limit

Synopsis In the co de for binmail in the function sendrmt there is a lo op

that copies the address up to the rst or NULL If the input string is

long enough to overwrite the stack it will b e executed when the pro cedure

returns using the address stored on the stack

Source Unreferenced source

Op erating System Information not available

Classication Condition validation check for limits

Synopsis The ioctl system call can b e combined with at to takeover a users

terminal and breach security

Source Security distribution list

Op erating System SunOS

Classication Synchronization error race condition

Synopsis If multiple users change their passwords simultaneously the yellow

pages password map le is up dated concurrently with no le lo cking This

corrupts the yellow page map le

Source Security distribution list

Op erating System SunOS

Classication Synchronization error improp er serialization of op erations

Synopsis A race condition in mkdir exists that can b e exploited to gain ro ot

access

Source Security distribution list

Op erating System Most BSD derived systems

Classication Synchronization error race condition

Synopsis A vulnerability exists in the site exec feature of ftpd that allows

any lo cal or remote user to gain ro ot access

Source CERT advisory CA

Op erating System Systems running wuarchiveversion

Classication Conguration error utility installed with incorrect setup

Synopsis A vulnerability in the logging function of xterm allows lo cal users

to create new les or mo dify any existing les

Source CERT advisory CA

Op erating System Systems running X windowsystemversion and version

Classication Sync hronization error race condition

Synopsis In SunOS etcutmp is writable by default This can b e ex

ploited by using programs suchas rwall to overwrite the password le

Source Security distribution list

Op erating System SunOS

Classication Condition validation error input validation error

Synopsis yypasswd le is world writable This allows any user to edit and

create new entries in the le

Source Security distribution list

Op erating System SunOS

Classication Conguration error secondary storage ob ject system database

le installed with incorrect p ermissions

Synopsis tftpd is installed on some machines that allows intruders access to

the system

Source CERT advisory CA

Op erating System DEC

Classication Condition validation error check for origin

Synopsis Any user can create a setuid program by using a P option in

login and breach security

Source Security distribution list

Op erating System Ultrix

Classication Origin validation error check for origin of sub ject

Synopsis If uucp is mo de it can b e exploited to gain ro ot privileges

Source Security distribution list

Op erating System Information not available

Classication Conguration error program installed with incorrect p ermis

sions

Synopsis If rexd RPC Remote program execution daemon is enabled any

one on the Internet can get access to the machine running rexd

Source CERT advisory CA

Op erating System Aix Aix

Classication Condition validation error check for origin

Synopsis If sendmail is installed with d it can b e exploited by unauthorized

users to gain access to a system

Source CERT advisory CA Also see Spa

Op erating System Systems running sendmail version

Classication Conguration error program installed with incorrect setup parameters

Synopsis When installing DECnet Internet software it is necessary to create

a guest account on the host By default this accounthasbincsh as its

default shell As the guest accounthasa valid shell it can b e exploited to

gain ro ot privileges

Source CERT advisory CA

Op erating System Ultrix

Classication Conguration error utility installed with incorrect setup

Synopsis The queuing system on AIX includes a batch queue bsh that is

turned on by default in etcqconfig This can b e exploited by remote

and lo cal users to gain ro ot privileges

Source CERT advisory CA

Op erating System AIX version and earlier

Classication Conguration error utility installed with incorrect setup pa

rameters

Synopsis A vulnerability in the p erformance to ols in AIX allows lo cal users

to gain ro ot privileges The solution suggested is to remove the setuid bit

Source CERT advisory CA

Op erating System AIX

Classication Conguration error secondary ob ject utility installed with

incorrect p ermissions

Synopsis If fsck fails during system b o otup a privileged shell is run on

the console This can allow users with physical access to the system to

gain unrestricted privileges

Source CERT advisory CA

Op erating System Solaris x

Classication Condition validation failure to handle exceptions

Synopsis A user can create an interactive shell with the userid of a setuid

shell script by creating a link to it with the name i

Source Unreferenced source

Op erating System SunOS and earlier

Classication Environment error interaction b etween functionally correct

mo dules

Synopsis Any user could bypass authentication pro cess by supplying a n as

an argumen t to the login program

Source Unreferenced source

Op erating System Sun i based systems

Classication Condition validation error check for origin

Synopsis sendmail could b e exploited to read any le on the system regardless

of the p ermissions by sp ecifying it as the conguration le to sendmail

Source See Dis

Op erating System BSD

Classication Condition validation error check for origin

Synopsis A vulnerability exists on IRIX systems that can b e exploited by users

to gain ro ot privileges The vulnerability is exploited using usrsbinfmt

The suggested solution is to change p ermission on fmt and ownership

to ro ot

Source CERT advisory CA

Op erating System SGI IRIX systems

Classication Conguration error utility installed with incorrect p ermissions

Synopsis A writable setuid le exists in Masscomp RTU that can b e exploited

to gain ro ot privileges

Source Security distribution list

Op erating System Masscomp RTU a system V deriv ed kernel

Classication Conguration error secondary storage ob ject installed with

incorrect p ermissions

Synopsis Mail programs on Unix systems change the uid of the mail le to

that of the recipient If the mail program do es not clear the setuid bits of

the le and the directory is writable security can b e breached

Source See Bis

Op erating System Information not available

Classication Conguration error secondary storage mail directory ob ject

installed with incorrect p ermissions

Synopsis The restore command was setuid which could b e exploited to

breach security

Source CERT advisory CA

Op erating System SunOS x

Classication Conguration error utility installed with incorrect p ermissions

Synopsis Some systems were shipp ed with accounts that did not have pass

words

Source CERT advisory CA

Op erating System Unisys U

Classication Conguration error utility set with incorrect setup parameters

Synopsis A vulnerabilityin intelnetd allowed the p ossibility of capturing

passwords by reading the terminal output

Source CERT advisory CAa

Op erating System SunOS and SunOS

Classication Condition validation check for access rights

Synopsis usrbinchroot was improp erly installed and could b e exploited

to gain ro ot privileges

Source CERT advisory CA

Op erating System Ultrix

Classication Conguration error utility installed with incorrect p ermissions

Synopsis Lo cal users could gain unauthorized privileges if a setuid program

changed its real and eective user ids to b e the same and subsequently

caused a dynamicallylinked program to b e execd

Source CERT advisory CA

Op erating System SunOS and higher

Classication Condition validation check for origin

Synopsis Default p ermission on a numb er of les and directories were set

incorrectlyFor instance les owned byrootwere owned bybin

Source CERT advisory CA

Op erating System SunOS fg

Classication Conguration error secondary storage ob ject has incorrect

p ermissions

Synopsis As part of the installation the system creates usrreleasebin

and installs two setuid ro ot les makeinstall and winstall These could

b e exploited to gain ro ot access

Source CERT advisory CA

Op erating System SunOS SunOS SunOS

Classication Conguration error utility installed with incorrect p ermissions

Synopsis binlogin is improp erly installed and may b e exploited to gain

ro ot privileges

Source CERT advisory CA

Op erating System System V release

Classication Conguration error utility installed with incorrect setup pa

rameters

Synopsis In some SunOS version the ro ot directory was writable This could

result in a user b eing able to overwrite or destroy sensitive les

Source Security distribution list

Op erating System SunOS

Classication Conguration error secondary storage ob ject installed with incorrect p ermissions