CSE 543: Safe File Access Trent Jaeger Systems and Internet - - PowerPoint PPT Presentation

▶
cse 543 safe file access
SMART_READER_LITE
LIVE PREVIEW

CSE 543: Safe File Access Trent Jaeger Systems and Internet - - PowerPoint PPT Presentation

Aug 09, 2023 491 likes •765 views

CSE 543: Safe File Access Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University Systems and Internet Infrastructure Security Laboratory (SIIS) Page 1

slide-1
SLIDE 1

Systems and Internet Infrastructure Security Laboratory (SIIS) Page 1

CSE 543: Safe File Access

Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University

slide-2
SLIDE 2

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Problem

  • Problem: Processes need resources from system
  • Just a simple open(filepath, …) right?
  • But, adversaries can redirect victims to resources of their

choosing

  • And if your program has some valuable privileges, an

adversary may want to trick you into using them to implement a malicious operation

2

slide-3
SLIDE 3

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

A Webserver’s Story …

  • Consider a university department webserver …

GET /~student1/index.html HTTP/1.1

Apache Webserver

student2/ public_html student1/ public_html

faculty1/

public_html

/etc/ passwd

Link

slide-4
SLIDE 4

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Attack Video

slide-5
SLIDE 5

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Systems and Internet Infrastructure Security Laboratory (SIIS) Page

What Just Happened?

Webserver

Password File Web Pages Authenticate

Passwd File Web Pages

Authenticate

OK Not OK

Passwd File Web Pages

Serve Webpage

OK Not OK

  • Program acts as a confused deputy
  • when expecting
  • when expecting

Serve Webpage

slide-6
SLIDE 6

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Lesson

  • Opening a file is fraught with danger
  • We must be careful when using an input that may

be adversary controlled when opening a file

  • Or other resources too
  • USENIX Security 2018 paper on being redirected on UNIX

Domain Sockets

  • What inputs are used in opening a file that

an adversary may control?

6

slide-7
SLIDE 7

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Lesson

  • Opening a file is fraught with danger
  • We must be careful when using an input that may

be adversary controlled when opening a file

  • Or other resources too
  • USENIX Security 2018 paper on being redirected on UNIX

Domain Sockets

  • What inputs are used in opening a file that an

adversary may control?

  • Inputs used to build file path names
  • Filesystem used to resolve file path names

7

slide-8
SLIDE 8

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Talk Outline

  • Problem: Processes need resources from system
  • Adversaries can redirect victims to resources chosen by adversary
  • Adversaries may control names, namespaces, and resources
  • Goal: Protect program during resource retrieval
  • Enforce rules to prevent retrieval of obviously exploitable resources
  • Deduce adversary control automatically to guide enforcement
  • Status:
  • Enforce: Process Firewall kernel mechanism [EuroSys 2013]
  • Deduce: Enforce relative to program control of “name flows” [submitted]
  • Background work: [ASIACCS 2012], [USENIX Security 2012], [SACMAT 2014]

8 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Vulnerability Classes

  • Our focus is on a group of vulnerabilities that

happen when programs access resources

  • Programs require a variety of resources to function
  • Regular files: store input and output
  • Interprocess communication channels
  • Signals: notifications from OS
  • How hard can fetching resources securely be?
  • Just a simple open(filename), right?
  • Wrong!

3

Wednesday, April 23, 14

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

  • Adversary controls the name to direct victim to an

adversary inaccessible (high integrity) resource

GET 1.html

Directory Traversal

9

V: Apache Webserver A passwd 1.html

slide-9
SLIDE 9

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Talk Outline

  • Problem: Processes need resources from system
  • Adversaries can redirect victims to resources chosen by adversary
  • Adversaries may control names, namespaces, and resources
  • Goal: Protect program during resource retrieval
  • Enforce rules to prevent retrieval of obviously exploitable resources
  • Deduce adversary control automatically to guide enforcement
  • Status:
  • Enforce: Process Firewall kernel mechanism [EuroSys 2013]
  • Deduce: Enforce relative to program control of “name flows” [submitted]
  • Background work: [ASIACCS 2012], [USENIX Security 2012], [SACMAT 2014]

9 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Vulnerability Classes

  • Our focus is on a group of vulnerabilities that

happen when programs access resources

  • Programs require a variety of resources to function
  • Regular files: store input and output
  • Interprocess communication channels
  • Signals: notifications from OS
  • How hard can fetching resources securely be?
  • Just a simple open(filename), right?
  • Wrong!

3

Wednesday, April 23, 14

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

  • Adversary controls the name to direct victim to an

adversary inaccessible (high integrity) resource

  • Victim expects adversary accessible (low integrity)

resource

Directory Traversal

9

V: Apache Webserver A passwd 1.html

GET ../../ etc/passwd

Malicious Name

slide-10
SLIDE 10

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Name Resolution

  • Processes often use names to obtain access to

system resources

  • A nameserver (e.g.,OS) performs name resolution using

namespace bindings (e.g., directory) to convert a name (e.g., filename) into a system resource (e.g., file)

  • Filesystem, System V IPC, …

10

/ var mail root P

  • pen(“/var/

mail/root”)

Name (filename) Bindings (directories) Resource (file)

Namespace (filesystem)

/ var mail root

slide-11
SLIDE 11

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

mail var

Link Traversal Attack

  • Adversary controls links to direct a victim to a

resource not normally accessible to the adversary

  • Victim expects adversary-accessible resource, gets a

protected resource instead

  • May take advantage of race conditions (TOCTTOU attacks)

11

  • pen(“/var/

mail/root”)

/ root var mail var mail / etc passwd passwd root root

Vroot

Amail

slide-12
SLIDE 12

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

TOCTTOU Attacks

  • Time-of-check-to-time-of-use Attack
  • Check System Call
  • Does the requesting party have access to the file? (stat,

access)

  • Is the file accessed via a symbolic link? (lstat)
  • Use System Call
  • Convert the file name to a file descriptor (open)
  • Modify the file metadata (chown, chmod)
  • Change filesystem between check and use to

evade access control

slide-13
SLIDE 13

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

File Squatting Attack

  • Adversary controls final resource enabling the

adversary to control input that the victim may depend on

  • Victim expects protected resource, gets an

adversary-controlled resource instead

13

mail var

  • pen(“/var/

mail/root”)

/ root var mail var mail / root

  • wner root
  • wner mail

root

Amail

Vroot

slide-14
SLIDE 14

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Prevalence

16

slide-15
SLIDE 15

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Name Resolution Problem

  • An adversary may be authorized to write to a

directory you use in resolving a file path

  • Create (and delete) files in that directory
  • E.g., groups and others may have write permission

to a directory

  • /tmp
  • ls ‒la /tmp
  • drwxrwxrwx --- root root --- .
  • Means?

17

slide-16
SLIDE 16

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Link traversal

  • Suppose your program is asked to open the

file path “/tmp/just_a_normal_file_here”

  • What file will you open?

20

slide-17
SLIDE 17

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Link traversal

  • Suppose your program is asked to open the file

path “/tmp/just_a_normal_file_here”

  • What file will you open?
  • An adversary could have created this as a symbolic link to any

file in the system (no restrictions on targets of symbolic links)

  • And it is difficult/expensive to verify the link target
  • lstat ‒ provides file system information (like “stat”) for the file

referenced by a link if the path name refers to a link

  • TOCTTOU RACES: But, adversary could place a file at the

time of the lstat check and replace with a link before the open

  • Causes your program to access an adversary-chosen file

21

slide-18
SLIDE 18

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Defense for Link Traversal

  • Check for symbolic link

(lstat)

  • Check for lstat-open race
  • Check for inode recycling
  • Do checks for each path

component (safe_open)

  • /, var, mail, …
  • Challenge: Can be

expensive

22

slide-19
SLIDE 19

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Safe Open - Inefficient

  • Checking retrieved resources is expensive
  • Single open() requires 4 * path length additional syscalls
  • Programmers omit checks to improve performance
  • Example: Apache documentation recommended switching off

resource access checks

23

slide-20
SLIDE 20

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

File Squatting

  • Suppose your program wants to create a

new file at “/tmp/my_pristine_new_file”

  • What file will you open?

24

slide-21
SLIDE 21

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

File Squatting

  • Suppose your program wants to create a

new file at “/tmp/my_pristine_new_file”

  • What file will you open?
  • An adversary could have created this file already and

given you permissions, so that you can use it

  • Causes your program to use a file under adversary

control when you expect a protected file

25

slide-22
SLIDE 22

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

File Squatting

  • Suppose your program wants to create a

new file at “/tmp/my_pristine_new_file”

  • What file will you open?
  • An adversary could have created this file already and

given you permissions, so that you can use it

  • Causes your program to use a file under adversary

control when you expect a protected file

  • DEFENSE: Opening file with a flag (O_EXCL)

will prevent opening a file already created,

  • But difficult to implement call that will either create

an exclusive file or open a file you already created

26

slide-23
SLIDE 23

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Deployment

Cause ‒ Multiple Parties

40

Programmer Administrator OS distributor

Code Configuration Access Control Policy

??? ???

  • pen(config_file)
  • pen(html_file)
  • pen(tmp_file)

mismatch mismatch

Expectations mismatch, blame each other

slide-24
SLIDE 24

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Causes

  • In general, a program must prevent an adversary

from using their input to access unauthorized files

  • Two things may go wrong
  • (1) The program may not recognize the inputs that may be

adversary controlled

  • For both file name and name resolution
  • (2) The program may filter input incorrectly allowing

access to unauthorized files

  • Is there an approach you can take to prevent these

problems?

41

slide-25
SLIDE 25

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Defense Principles

  • Enforce programmer expectation
  • If programmer expects to access only , then

they should not access

  • Unexpected attack surface
  • Failed to check case (1)
  • If programmer expects , then they should

not access

  • Classic confused deputy
  • Failed to check case (2)

42

slide-26
SLIDE 26

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Prevent Escalation

  • In general, a program must prevent an adversary from

using their input to access unauthorized files

  • Two things may go wrong
  • (1) The program may not recognize the inputs that may be

adversary controlled

  • Detect receipt of adversary-controlled inputs and prevent use to limit

to expected attack surfaces (e.g., via lstat of directories, inode recycling prevention, and fstat of source fd)

  • (2) The program may filter input incorrectly allowing access to

unauthorized files

  • Restrict adversaries to their authorized files when their input is used in

building file names or in resolving file names (e.g., fstat of target fd)

43

slide-27
SLIDE 27

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Take Away

  • Programs can exploited when retrieving system

resources

  • Because adversaries may want access to resources held by

privileged programs

  • Cause programs to either operate on privileged

resources (e.g., link traversal) or untrusted resources (e.g., file squatting)

  • Track adversary control of inputs to file access (file

names and name resolution) to limit adversary to authorized permissions

47