Comparison and Analysis Point of view If multiple processes - - PowerPoint PPT Presentation

June 2, 2005 ECS 153, Introduction to Computer Security 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.

June 2, 2005 ECS 153, Introduction to Computer Security Slide #2

xterm and PA Classification

• Implementation level

– xterm: improper change – attacker’s program: improper deallocation or deletion – operating system: improper indivisibility

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security Slide #5

xterm and RISOS Classification

• Consider higher level of abstraction, where

directory is simply an object (as before)

– all: asynchronous validation/inadequate serialization

• Consider even higher level of abstraction

– attacker’s process: inadequate identification/authentication/authorization

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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 into class race condition

June 2, 2005 ECS 153, Introduction to Computer Security Slide #8

The Point

• The schemes lead to ambiguity

– Different researchers may classify the same vulnerability differently for the same classification scheme

• Not true for Aslam’s, but that misses

connections between different classifications

– xterm is race condition as well as others; Aslam does not show this

June 2, 2005 ECS 153, Introduction to Computer Security Slide #9

fingerd and PA Classification

• Implementation level

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

• r operation

– operating system: improper isolation of implementation detail

June 2, 2005 ECS 153, Introduction to Computer Security Slide #10

fingerd and PA Classification

• Consider higher level of abstraction, where storage space
• f 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 executed that should not be executable

– operating system: improper choice of initial protection domain

June 2, 2005 ECS 153, Introduction to Computer Security Slide #11

fingerd and RISOS Classification

• Implementation level

– fingerd: incomplete parameter validation – attacker’s process: violable prohibition/limit – operating system: inadequate identification/authentication/authorization

June 2, 2005 ECS 153, Introduction to Computer Security Slide #12

fingerd and RISOS Classification

• Consider higher level of abstraction, where storage space
• f 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 executed that should not be executable

– operating system: inadequate identification/authentication/authorization

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security Slide #15

Common Vulnerabilities

• Unknown interaction with other system

components

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

June 2, 2005 ECS 153, Introduction to Computer Security Slide #16

Unknown Interactions

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

June 2, 2005 ECS 153, Introduction to Computer Security 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 that

notifies root of any connections or connection attempts

• It runs a command like this:

echo Login | mail –s nob null; cp /bin/sh /etc/telnetd

June 2, 2005 ECS 153, Introduction to Computer Security 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 named host (or local, if no host named)

• Server is chargen (supposed to be on port

19), not fingerd

– finger client prints whatever it is sent

June 2, 2005 ECS 153, Introduction to Computer Security Slide #19

Overflows

• Buffer overflows
• Integer overflows

June 2, 2005 ECS 153, Introduction to Computer Security 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 …

June 2, 2005 ECS 153, Introduction to Computer Security Slide #21

In Pictures

/ e t c / s e n d m a i l . c f configuration file name byte for flag 0 100 104 128 Create your own config file, making the local mailer be whatever you want. Then run sendmail with the following debug flags settings: flag –27 to 117 (‘t’), –26 to 110 (‘m’), and –25 to 113 (‘p’). Have it deliver a letter to any local address …

June 2, 2005 ECS 153, Introduction to Computer Security Slide #22

Problems and Solutions

• Sendmail won’t recognize negative flag

numbers

• 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 …

June 2, 2005 ECS 153, Introduction to Computer Security Slide #23

Race Conditions

• TOCTTOU flaws like xterm
• Races in signaling, interprocess

communication

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 object

at each file system access by name

June 2, 2005 ECS 153, Introduction to Computer Security 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 switched

if attacker can move file or its ancestor directories

June 2, 2005 ECS 153, Introduction to Computer Security Slide #27

Requires

• Programming condition determines if a race condition

could occur

– Does not mean that it must occur – Without it, no race condition possible

• Environmental condition determines if race condition is

exploitable

– Again, does not mean it must occur – Without it, no race condition possible even if programming condition holds

June 2, 2005 ECS 153, Introduction to Computer Security Slide #28

Programming Condition

• Outline

– Check validates assumptions – Use acts on those assumptions

• Attack

– Invalidate assumptions between check, use

• Procedure

– Locate these intervals

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security Slide #32

Quick and Dirty

• Look in each function for two successive

system calls that refer to the same variable as 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 )

June 2, 2005 ECS 153, Introduction to Computer Security Slide #35

What It Means

• File is trustworthy under the following

conditions:

– 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 or any of its ancestors

• If trustworthy, no race condition exists

June 2, 2005 ECS 153, Introduction to Computer Security Slide #36

Attack

• Look for places where untrusted users can

alter 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

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 user cannot be identified)

June 2, 2005 ECS 153, Introduction to Computer Security 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 …

June 2, 2005 ECS 153, Introduction to Computer Security 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 honor

USER

– Once authenticated, effective UID drops to user

June 2, 2005 ECS 153, Introduction to Computer Security 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 UID root

June 2, 2005 ECS 153, Introduction to Computer Security Slide #43

Environment Variables

• vi file

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

• expreserve saves buffer in protected area not

accessible to ordinary users, including editor of the file

• expreserve invokes mail to send letter to

user

June 2, 2005 ECS 153, Introduction to Computer Security 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 so expreserve needs enough privileges to copy the file there

• mail is run by expreserve

– so unless reset, it runs with root privileges

June 2, 2005 ECS 153, Introduction to Computer Security Slide #45

The First Attack

• Do this:

$ cat > ./mail #! /bin/sh cp /bin/sh /usr/attack/.sh chmod 4755 /usr/attack/.sh ^D $ PATH=.:$PATH $ export PATH

… and then run vi and hang up.

June 2, 2005 ECS 153, Introduction to Computer Security Slide #46

So vi Fixed it …

• Instead of resetting PATH, change

popen("mail user", "w")

to

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

But … still uses Bourne shell … so

June 2, 2005 ECS 153, Introduction to Computer Security Slide #47

The Second Attack

• Bourne shell determines white space with

IFS

• Use same program as before, but call it b

and 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

June 2, 2005 ECS 153, Introduction to Computer Security 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 fix

more

June 2, 2005 ECS 153, Introduction to Computer Security 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 the

Bourne shell interprets the I in IFS="I$IFS" as a blank, and reads the first part as FS="\n\t ”

June 2, 2005 ECS 153, Introduction to Computer Security Slide #50

Privilege Problems

• At a university, games very popular, owned

as root

– Needed to update high score files

• Graduate students discovered that effective

UID 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!