how to open a file and not get hacked · how to open a file and not get hacked james a. kupsch and...

How to Open a File and Not Get Hacked

James A. Kupschand Barton P. MillerUniversity of Wisconsin

SecSE 2008, Barcelona, SpainMarch 5th, 2008

©2008 James A. Kupsch

2

Background• Vulnerability assessment project focusing

on distributed systems software• As part of this effort we observed security

problems involving– opening of files– path vulnerabilities

in all software examined• Major goal to prevent security problems

and educate developers on secure coding

3

Problem of Safely Opening a FileAlmost all programs open a file. Insecure permissions anywhere in a path can be a disaster.

Opening safely should be simple, but is not:– Standard APIs are not secure by default, much easier

to use in an insecure fashion

– No standard API that provides secure semantics– Subtle semantics for checking trust, due to symbolic

links, hard links, sticky bit semantics– Safe open requires many non-atomic operations and

dealing with the concurrency problems that arise

Others have thought about this problem, but they haven't gotten it right.

4

Threats

• Reveal secrets– /etc/shadow

• Allow unauthorized access– /etc/passwd ~/.ssh/authorized_keys

• Execute programs– /etc/rc ~/.bashrc ~/.vimrc

• Prevent operation– overwrite file contents

Security of a system depends on the security of its files. If a user on the system can attack them, user accounts, applications or the system can easily be compromised.

5

Trust• Trusted users - trust not to do anything bad• Trusted path - safe from attack

– only trusted users can modify• which file• file contents

– less precautions needed, most attacks are prevented

– most applications incorrectly assume paths are trusted

6

Strategies for Safe Open• Verify Path is Trusted

– Do not use if not trusted

• Safely Open an untrusted file– Prevents common security problems with

• symbolic links• misuse of the API leading to weak permissions

– Detects attacks of the path

7

Safe Coding Practices • Active field

– Many books– Prior work on this problem

• Viega & McGraw - Building Secure Software• Bishop - SANS 2002 Tutorial

– US CERT Secure Coding Standards http://www.securecoding.cert.org

– ISO/IEC TR 24731: C library extensions: Bounds checking of string values and I/O safety

• None correctly describe– checking the trust of a path– complete safer open and fopen replacements

8

Attack: Untrusted File

Program's Goal: open file /d/f, assume only trusted users can change the file

Program (P) / Attacker (A)P: fopen("/d/f", "r")A: fopen("/d/f", "w")A: write bad dataP: read dataP: use data

Problem: untrusted users can modify /d/f.Uses untrusted data.

/d

f

TrustedDirs

UntrustedFile

9

Attack: Untrusted Directory

Program's Goal: check trust of /d/f, assume only trustedusers can control contents of /d/f

Problem: untrusted users can remove and create files in /d. Denial of Service after unlink, Uses untrusted data after create.

/d

f

Program (P) / Attacker (A)P: stat("/d/f")P: check trust using statA: unlink("/d/f")A: creat("/d/f")A: write bad dataP: fopen("/d/f", "r")P: read dataP: use data

UntrustedDir

10

Attack: Symbolic link

Program's Goal: create file f in directory /d

Problem: untrusted user can pick file that is opened/created as trusted user. Attacker causes wrong file to be opened/created.

/tmp etc

f passwd

→ /etc/passwd

Program (P) / Attacker (A)A: symlink("/tmp/passwd", "/tmp/f")P: fopen("/tmp/f", "w")P: write data

StickyBit Dir

11

Attack: Hard links

/tmp

Program's Goal: assume that trusted user created file f in the /tmp (sticky bit set) directory if perms of f are trusted.

Problem: any user can create a hard link to any other user's file. Application thinks it created a directory entry it didn't.

s

x x.bad

Program (P) / Attacker (A)A: link("/s/x.bad", "/tmp/x")P: fopen("/tmp/x", "r")P: fstatP: check trust using fstatP: use data

12

Attack: Cryogenic SleepProgram's Goal: use lstat to check trust of /tmp/f. If good,

open /tmp/f. If same object, trust content and location.

Problem: race between lstat and open. Tmp file cleaner removes /tmp/f. Attacker gets program to open untrusted file.

/tmp u

inode=12

f

Program (P) / Attacker (A)P: lstat("/tmp/f")P: check trust from lstatA: sleep/delay programA: wait until /tmp/f removedA: symlink("/u/x", "/tmp/f")A: unlink("/u/x");creat("/u/x") until dev/inode matchA: resume programP: open("/tmp/f", O_RDONLY)P: fstatP: check dev/inode matchP: use data

12




/tmp u

tmpcleanerremoves


12




/tmp u

f

→ /u/x


12




/tmp u

f

→ /u/x inode=18

x


12




/tmp u

f

→ /u/x inode=15

x


12




/tmp u

inode=12

xf

→ /u/x


13

Trusted Path• Trusted path - only the set of trusted users

and groups can modify– which object the path refers – the contents of the object

• Especially important for applications with elevated privileges

• Not secure to check just the trust of– the object– directories from the object to the root directory

14

Trust of a Directory Entry• Trust of a file system object is determined by

– Permission bits

– Owner and group– Trusted users and groups

– Sticky bit for directories

• Types of trust– Untrusted

– Trusted– Sticky directory trusted (such as /tmp) - limited trust to

• Directories inside• Files you create inside and only access through returned file

descriptor

15

Trust of a Path• Must check every object encountered along

the path and all must be trusted– check the same objects as the OS– relative paths must check all directories from

current to root– if the parent directory is sticky dir trusted, non-

directories are not trusted– handle symbolic links

• referent path must be checked before proceeding• detect loops• handle large path lengths

16

safe_is_path_trusted_rsafe_is_path_trusted_r checking the trust of /L1/f. The trust

of each object is checked in the same order as the OS.

Current Path Unprocessed

Processing stops when:• untrusted object found• unprocessed is empty• an error occurs

Symbolic link referents are pushed on the stack.The stack depth is used to detect symbolic link loops.

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f

Parent Trust

➊

➋➌

➍

➎

➏

➐ ➒

➑

Internal State

16

safe_is_path_trusted_r

/ | L1 | f

safe_is_path_trusted_r checking the trust of /L1/f. The trust of each object is checked in the same order as the OS.




/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f

Parent Trust Trusted

➊

➋➌

➍

➎

➏

➐ ➒

➑

Internal State

16


L1 | f





/

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

➊

Internal State

16


f





/L1

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑➋

Internal State

16


d1 | L2 | ..f





/

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

Internal State

16


L2 | ..f





/d1

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑➌

Internal State

16


..f





/d1/L2

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

➍

Internal State

16


/ | d2 | d3..f





/d1

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

Internal State

16


d2 | d3..f





/

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

➎

Internal State

16


d3..f





/d2

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑➏

Internal State

16


..f





/d2/d3

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f

Parent Trust Sticky Trust

➊

➋➌

➍

➎

➏

➐ ➒

➑

➐

Internal State

16


f





/d2/d3/..

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑➑

Internal State

16


f





/d2

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

Internal State

16

safe_is_path_trusted_rsafe_is_path_trusted_r checking the trust of /L1/f. The trust

of each object is checked in the same order as the OS.




/d2/f

/d1

→ /d2/d3

L1 d2

→ d1/L2/..L2 d3 f


➊

➋➌

➍

➎

➏

➐ ➒

➑

➒

Internal State

17

Prior Work - safe_dir• McGraw & Viega in

Building Secure Software– only directory paths– checks directories from

path directly to root directory, not the path given

– correct for '.' path (current working dir)

/bad good

link safe

→ /good

Ex. check /bad/link/safe ➊ OS order ➀ safe_dir order

After check attacker can change link

➊

➋

➌

➍

➎

➏ ➀

➁

➂

18

Prior Work - trustfile• Bishop - SANS2002

Tutorial– unsafe textual

transform A/B/../C to A/C before check• not valid if B is a

symbolic link or not trusted

– fails to detect symbolic link loops

/bad good

link

finalfile

→ d/d

➊

➋

➌ ➍

➎

➏

➀

➁

➂

d

d good safe

finalfile

safe

➐

➒

➑

Ex. check /bad/link/../../good/safe ➊ OS order Incorrectly checks /good/safe ➀ trustfile order

19

Trusted Path Algorithm

multiple trusted accounts ✘ ✔ ✔

supports all file types ✘ ✔ ✔

supports all valid paths ✔ ✘ ✔properly checks symlinks

✘ ✘ ✔

detects symlink loops ✔ ✘ ✔

handles sticky bit dirs ✘ ✘ ✔

efficient ✘ ✘ ✔

concurrency safe ✘ ✔ ✔

trusted result is not attackable

✘✔ for path of '.'

✘ ✔

McGraw & Viega'ssafe_dir

Bishop'strustfile safe_is_path_trusted_r

20

Opening an Untrusted File• Problems

– O_CREAT w/o O_EXCL will follow symbolic link to create files

– open takes 3 arguments• 3rd is permissions when creating

• no warning if missing, get random perms

– Checks can require open, lstat and compare• O_TRUNC is destructive

• Desired solution– Similar API– Solves above problems

– Detection of active attacks on path– Additional richer functionality

21

open Replacement FunctionsDirect replacement function: safe_open_wrapper(filename, flags, perms)Advanced replacement functions: safe_open_no_create safe_create_fail_if_exists safe_create_keep_if_exists safe_create_replace_if_existsSymbolic link following to an existing file: safe_open_wrapper_follow safe_open_no_create_follow safe_open_keep_if_exists_followSimilar functions for fopenAll support attack detection mechanism

22

safe_open_no_create

safe_open_no_create(fn, flags){if (O_CREATE or O_EXCL in flags) return error

loop remove O_TRUNC from flags fd = open(fn, flags) lstat(fn) fstat(fd) if (both succeed and are same file) if (had O_TRUNC) ftruncate(fd, 0) return fd if (errors are consistent) return error AttackDetected(fn)}

check for invalid input

cryogenic sleep attack prevented by open before lstat - prevents dev/inode reuse

handle truncate after check to not truncated wrong file

attacker beat race between lstat and open; report attack detected and try again

23

Source Code Availablesafefile library and documentation

under Apache license athttp://www.cs.wisc.edu/~kupsch/safefile

23

Source Code Availablesafefile library and documentation

under Apache license athttp://www.cs.wisc.edu/~kupsch/safefile

Questions

how to open a file and not get hacked · how to open a file and not get hacked james a. kupsch and...

Documents