comparison and analysis -...

June 2, 2005 ECS 153, Introduction to ComputerSecurity

Slide #1

Comparison and Analysis

• Point of view– If multiple processes involved in exploiting the

flaw, how does that affect classification?• xterm, fingerd flaws depend on interaction of two

processes (xterm and process to switch file objects;fingerd and its client)

• Levels of abstraction– How does flaw appear at different levels?

• Levels are abstract, design, implementation, etc.


Slide #2

xterm and PA Classification

• Implementation level– xterm: improper change– attacker’s program: improper deallocation or

deletion– operating system: improper indivisibility


Slide #3

xterm and PA Classification• Consider higher level of abstraction, where directory is

simply an object– create, delete files maps to writing; read file status, open file maps

to reading– operating system: improper sequencing

• During read, a write occurs, violating Bernstein conditions• Consider even higher level of abstraction

– attacker’s process: improper choice of initial protection domain• Should not be able to write to directory containing log file• Semantics of UNIX users require this at lower levels


Slide #4

xterm and RISOS Classification

• Implementation level– xterm: asynchronous validation/inadequate

serialization– attacker’s process: exploitable logic error and

violable prohibition/limit– operating system: inconsistent parameter

validation


Slide #5

xterm and RISOS Classification

• Consider higher level of abstraction, wheredirectory is simply an object (as before)– all: asynchronous validation/inadequate

serialization• Consider even higher level of abstraction

– attacker’s process: inadequateidentification/authentication/authorization

• Directory with log file not protected adequately• Semantics of UNIX require this at lower levels


Slide #6

xterm and NRL Classification

• Time, location unambiguous– Time: during development– Location: Support:privileged utilities

• Genesis: ambiguous– If intentional:

• Lowest level: inadvertent flaw of serialization/aliasing– If unintentional:

• Lowest level: nonmalicious: other– At higher levels, parallels that of RISOS


Slide #7

xterm and Aslam’s Classification• Implementation level

– attacker’s process: object installed with incorrect permissions• attacker’s process can delete file

– xterm: access rights validation error• xterm doesn’t properly validate file at time of access

– operating system: improper or inadequate serialization error• deletion, creation should not have been interspersed with access, open

– Note: in absence of explicit decision procedure, all could go intoclass race condition


Slide #8

The Point

• The schemes lead to ambiguity– Different researchers may classify the same

vulnerability differently for the sameclassification scheme

• Not true for Aslam’s, but that missesconnections between differentclassifications– xterm is race condition as well as others;

Aslam does not show this


Slide #9

fingerd and PA Classification

• Implementation level– fingerd: improper validation– attacker’s process: improper choice of operand

or operation– operating system: improper isolation of

implementation detail


Slide #10

fingerd and PA Classification• Consider higher level of abstraction, where storage space

of return address is object– operating system: improper change– fingerd: improper validation

• Because it doesn’t validate the type of instructions to be executed,mistaking data for valid ones

• Consider even higher level of abstraction, where security-related value in memory is changing and data executedthat should not be executable– operating system: improper choice of initial protection domain


Slide #11

fingerd and RISOS Classification

• Implementation level– fingerd: incomplete parameter validation– attacker’s process: violable prohibition/limit– operating system: inadequate

identification/authentication/authorization


Slide #12

fingerd and RISOS Classification• Consider higher level of abstraction, where storage space

of return address is object– operating system: asynchronous validation/inadequate serialization– fingerd: inadequate identification/authentication/authorization

• Consider even higher level of abstraction, where security-related value in memory is changing and data executedthat should not be executable– operating system: inadequate

identification/authentication/authorization


Slide #13

fingerd and NRL Classification

• Time, location unambiguous– Time: during development– Location: support: privileged utilities

• Genesis: ambiguous– Known to be inadvertent flaw– Parallels that of RISOS


Slide #14

fingerd and Aslam Classification

• Implementation level– fingerd: boundary condition error– attacker’s process: boundary condition error

• operating system: environmental fault– If decision procedure not present, could also have been

access rights validation errors


Slide #15

Common Vulnerabilities

• Unknown interaction with other systemcomponents

• Overflow• Race conditions• Environment variables• Not resetting privileges


Slide #16

Unknown Interactions

• DNS with bad information• Assumption about servers running on ports


Slide #17

Poisoned DNS

• DNS: returns a host name given an IP address• Attacker “poisons the DNS”

– Say that address 169.237.4.199 corresponds to host“a.com null; cp /bin/sh /etc/telnetd;”

• Attacker connect to a system running server thatnotifies root of any connections or connectionattempts

• It runs a command like this:echo Login | mail –s nob null; cp /bin/sh /etc/telnetd


Slide #18

Wrong Server Listening

• Connect to port 79 to obtain information– fingerd takes name, name and host, and sends

back information about that user on namedhost (or local, if no host named)

• Server is chargen (supposed to be on port19), not fingerd– finger client prints whatever it is sent


Slide #19

Overflows

• Buffer overflows• Integer overflows


Slide #20

Example: sendmail config file

• sendmail takes debugging flags of form flag.value– sendmail -d7,102 sets debugging flag 7 to value 102

• Flags stored in array in data segment• So is name of default configuration file

– It’s called sendmail.cf• Contains name of local delivery agent

– Mlocal line; usually /bin/mail …


Slide #21

In Pictures/ e t c/ s e nd m a il . c f

configuration file name

byte for flag 0

100104

128

Create your own config file,making the local mailer be whateveryou want. Then run sendmail with thefollowing debug flags settings: flag–27 to 117 (‘t’), –26 to 110 (‘m’), and–25 to 113 (‘p’). Have it deliver aletter to any local address …


Slide #22

Problems and Solutions

• Sendmail won’t recognize negative flagnumbers

• So make them unsigned (positive)!–27 becomes 232 – 27 = 4294967269–26 becomes 232 – 26 = 4294967270–25 becomes 232 – 26 = 4294967271

• Command is:sendmail -d4294967269,117 -d4294967270,110 -

d4294967271,113 …


Slide #23

Race Conditions

• TOCTTOU flaws like xterm• Races in signaling, interprocess

communication


Slide #24

Race Conditions

• Two events, a and b, will occur– Order ab is expected– Order ba causes problem– a and b “race” to finish first

• Arises in concurrent programming– UNIX, Linux systems are multiprocessing– Two processes interacting creates the possibility of race condition– One process is victim, one attacker


Slide #25

TOCTTOU Flaw

• Time of Check to Time of Use(TOCTTOU)– Check some condition of a resource– If check satisfactory, use the resource

• Example: File name rebound to file objectat each file system access by name


Slide #26

Check and Use

• First, check condition– Common system calls for this are access(2) and stat(2) or one of

their relatives• Then, check use:

– Common system calls are open(2), chown(2), chgrp(2), chmod(2),and unlink(2)

• All these done by name; therefore binding can be switchedif attacker can move file or its ancestor directories


Slide #27

Requires

• Programming condition determines if a race conditioncould occur– Does not mean that it must occur– Without it, no race condition possible

• Environmental condition determines if race condition isexploitable– Again, does not mean it must occur– Without it, no race condition possible even if programming

condition holds


Slide #28

Programming Condition

• Outline– Check validates assumptions– Use acts on those assumptions

• Attack– Invalidate assumptions between check, use

• Procedure– Locate these intervals


Slide #29

Referencing Files

• By name: late binding– Kernel binds after scanning path name– Rebound at every instance of name– Multiply indirect pointer

• By descriptor– Kernel binds at creation of descriptor– Never rebound until original object explicitly disassociated– Direct pointer to object


Slide #30

Bounds of Interval

• Check, use with file names– Programming condition holds

• Check with file name, use with descriptor– Programming condition holds

• Check with descriptor, use with name– Programming condition holds

• Check, use with descriptors– Programming condition does not hold


Slide #31

Detecting the Condition

• Build call graph– This shows which functions call other functions– Can combine with data flow graph to determine when arguments

are the same• Look for pairs of system calls referring to the same file

– Requires resolving variable and pointer references– If system calls constructed on the fly, this fails


Slide #32

Quick and Dirty

• Look in each function for two successivesystem calls that refer to the same variableas a file name– Doesn’t handle situations where f() calls g(),g() calls access, and then f() calls open

– May (or may not) handle macros– Names of arguments checked, but not values


Slide #33

Environmental Condition

• Can user alter or replace referent?– If so, race condition can be exploited– policy dictates whether being able to change file only is enough

• Trustworthy file– File which untrusted users cannot alter or replace– Idea: if file is trustworthy, only trusted users can change it, so race

condition cannot be exploited


Slide #34

Trustworthiness

• Define trustworthiness function trust(file) by:– trust(f ) true if f cannot be altered by untrusted user– this refers to the object binding; that is, f’s binding can

be altered only by a trusted subject– if the process reads the file (not write to it), “alter” also

includes modifying the data in the object• Can show the following (d directory, l symbolic

link to directory d):– trust(d/f ) if, and only if, trust(d ) and trust(f )– trust(l/f ) if, and only if, trust(l ) and trust(d/f )


Slide #35

What It Means

• File is trustworthy under the followingconditions:– No untrusted user can write/append to the file– No untrusted user can alter an ancestor

directory– If any ancestor directory is a symbolic link, no

untrusted user can alter the link’s referent orany of its ancestors

• If trustworthy, no race condition exists


Slide #36

Attack

• Look for places where untrusted users canalter files– Temporary files created in world writable

directories• /tmp, /usr/tmp, /var/tmp, others

– Sub-directories of world writable directories• Can move unwritable sub-directories

– Consider groups, too


Slide #37

Example: sendmail

• Programming condition tested on v8.6.10– Used the “quick and dirty” method

• 24 positives found– 19 clearly false positives– 2 allow redefinition of “class”

• Require file containing definition of class to be untrustworthy– 2 allow listing of files with names of form “qfnnnnnx” or

“dfnnnnnx” and in protected directories• Again, require directory to be untrustworthy


Slide #38

But …

• 1 allows file protection modes to be altered– Requires “dead.letter” to be in untrustworthy

directory (normal state of affairs if real usercannot be identified)


Slide #39

Amusing Aftermath

• Problem reported to Eric Allman• When reported, sendmail v8.6.12 had just

been released• *Hobbit* had found it just before we did

– The sixth race condition …


Slide #40

About the Script

• A perl program written in under 3 hours– Rumor was the grad student had begun learning PERL the day

before he wrote it• Run over a vendor’s source

– Found numerous problems– Reported to vendor and subsequently fixed

• Script ported to other vendors’ systems– Required changing the list of system calls to look for– Enumerating these was the most painful


Slide #41

Race Signals

• FTP clients aborting:– ABOR on control connection with urgent flag set– Closing data connection

• FTP server getting two signals and catching both:– SIGURG for the ABOR– SIGPIPE for the close

• FTP server has real UID as root so it can honorUSER– Once authenticated, effective UID drops to user


Slide #42

FTP Race Condition

• SIGPIPE causes server to get effective UID root,write entry to the wtmp file, exit– No signal handling changed here

• SIGURG sends FTP server back to command loop– Window is if SIGURG arrives after SIGPIPE but

before exit()– If SIGURG occurs at that point, FTP server re-enters

FTP command loop and is running with effective UIDroot


Slide #43

Environment Variables

• vi file– Edit file, then hang up without saving it …– vi invokes expreserve

• expreserve saves buffer in protected area notaccessible to ordinary users, including editor of thefile

• expreserve invokes mail to send letter touser


Slide #44

Where Is the Privilege?

• vi is not setuid to root– You don't need that to edit your files

• expreserve is setuid to root– the buffer is saved in a protected area soexpreserve needs enough privileges to copy thefile there

• mail is run by expreserve– so unless reset, it runs with root privileges


Slide #45

The First Attack

• Do this:$ cat > ./mail#! /bin/shcp /bin/sh /usr/attack/.shchmod 4755 /usr/attack/.sh^D$ PATH=.:$PATH$ export PATH

… and then run vi and hang up.


Slide #46

So vi Fixed it …

• Instead of resetting PATH, changepopen("mail user", "w")

topopen("/bin/mail user", "w")

But … still uses Bourne shell … so


Slide #47

The Second Attack

• Bourne shell determines white space withIFS

• Use same program as before, but call it band set it up this way:

% IFS="/inmal\t\n "; export IFS% PATH=.:$PATH; export PATH

• Then run vi and hang up.– Then “/bin/mail” user acts like b and runs my

program


Slide #48

Fixing This

• Fix given in most books is:system("IFS='\n\t ';PATH=/bin:/usr/bin;\

export IFS

PATH;command");

• This sets IFS, PATH; you may want to fixmore


Slide #49

How to Break This

• Before invoking your program plugh, I do:% IFS="I$IFS"% PATH=".:$PATH"% plugh

• Now your IFS is unchanged since theBourne shell interprets the I inIFS="I$IFS" as a blank, and reads thefirst part as FS="\n\t ”


Slide #50

Privilege Problems

• At a university, games very popular, ownedas root– Needed to update high score files

• Graduate students discovered that effectiveUID was not reset when a subshell spawned– So they could start a game which kept a high

score file, and run a subshell – as root!

comparison and analysis -...

Documents