CSE543 - Introduction to Computer and Network Security Module: - - PowerPoint PPT Presentation

▶
cse543 introduction to computer and network security
SMART_READER_LITE
LIVE PREVIEW

CSE543 - Introduction to Computer and Network Security Module: - - PowerPoint PPT Presentation

Apr 03, 2024 1.3k likes •1.67k views

slide-1
SLIDE 1

฀฀฀฀ ฀

  • ฀฀฀฀

฀฀฀฀฀ ฀฀฀฀฀฀

CSE543 - Introduction to Computer and Network Security Page

CSE543 - Introduction to Computer and Network Security Module: System Vulnerabilities

Professor Trent Jaeger

1

slide-2
SLIDE 2

CSE543 - Introduction to Computer and Network Security Page

Still Not Enough

  • So, even with “secure” operating systems that enforce
  • MAC policies comprehensively
  • The adversaries can still launch many attacks against

those systems

  • What are we missing?

2

slide-3
SLIDE 3

CSE543 - Introduction to Computer and Network Security Page

Name Resolution

3

! !

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

/! var! mail! root! P!

  • pen(“/var/

mail/root”)

Name! (filename)" Bindings (directories)" Resource (file)" Namespace (filesystem)" /! var! mail! root!

slide-4
SLIDE 4

CSE543 - Introduction to Computer and Network Security Page

Attacks on Name Resolution

4

  • Improper Resource Attack!
  • Adversary controls final resource in unexpected ways!
  • Untrusted search paths (e.g., Trojan library), file squatting!
  • Victim expects high integrity, gets low integrity instead!

mail! var! ! !

  • pen(“/var/

mail/root”)

/! root! var! mail! root!

  • wner root

root! Amail! Vroot!

slide-5
SLIDE 5

CSE543 - Introduction to Computer and Network Security Page

Attacks on Name Resolution

5

  • Improper Resource Attack!
  • Adversary controls final resource in unexpected ways!
  • Untrusted search paths (e.g., Trojan library), file squatting!
  • Victim expects high integrity, gets low integrity instead!

mail! var! ! !

  • pen(“/var/

mail/root”)

/! root! var! mail! root!

  • wner mail

Amail! Vroot!

slide-6
SLIDE 6

CSE543 - Introduction to Computer and Network Security Page

Attacks on Name Resolution

6

mail! var!

  • Improper Binding Attack!
  • Adversary controls bindings to redirect victim to a

resource not under adversary’s control (confused deputy)!

  • Symbolic link, hard link attacks!
  • Victim expects low integrity/secrecy, gets high instead!

! !

  • pen(“/var/

mail/root”)

/! root! var! mail! var! mail! /! etc! passwd! passwd! root! root! Vroot! Amail!

slide-7
SLIDE 7

CSE543 - Introduction to Computer and Network Security Page

Attacks on Name Resolution

7

  • Race Conditions!
  • Adversary exploits non-atomicity in “check” and “use” of

resource to conduct improper resource and improper binding attacks!

  • Well-known “TOCTTOU” attacks !

mail! var! ! ! Vroot!

lstat(“/var/ mail/root”)

/! root! var! mail! etc! passwd! Amail!

slide-8
SLIDE 8

CSE543 - Introduction to Computer and Network Security Page

Attacks on Name Resolution

8

  • Race Conditions!
  • Adversary exploits non-atomicity in “check” and “use” of

resource to conduct improper resource and improper binding attacks!

  • Well-known “TOCTTOU” attacks !

mail! var! ! ! Vroot! /! root! var! mail! var! mail! /! etc! passwd! passwd! root! root! root!

  • pen(“/var/

mail/root”)

Amail!

slide-9
SLIDE 9

CSE543 - Introduction to Computer and Network Security Page

How Serious a Problem?

9

  • Name resolution vulnerabilities accounts for 5-10%

CVE entries each year!

  • These are particularly hard to eradicate as they

involve multiple parties!

  • Programmers who write code!
  • OS distributors who define access control policies!
  • Administrators who configure end system!
slide-10
SLIDE 10

CSE543 - Introduction to Computer and Network Security Page

Difficult to Prevent

10 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

  • Manual checks can

easily overlook vulnerabilities!

  • But, misses already

existing file squat!!

31

01 /* filename = /var/mail/root */ 02 /* First, check if file already exists */ 03 fd = open (filename, flg); 04 if (fd == -1) { 05 /* Create the file */ 06 fd = open(filename, O_CREAT|O_EXCL); 07 if (fd < 0) { 08 return errno; 09 } 10 } 11 /* We now have a file. Make sure 12 we did not open a symlink. */ 13 struct stat fdbuf, filebuf; 14 if (fstat (fd, &fdbuf) == -1) 15 return errno; 16 if (lstat (filename, &filebuf) == -1) 17 return errno; 18 /* Now check if file and fd reference the same file, 19 file only has one link, file is plain file. */ 20 if ((fdbuf.st_dev != filebuf.st_dev 21 || fdbuf.st_ino != filebuf.st_ino 22 || fdbuf.st_nlink != 1 23 || filebuf.st_nlink != 1 24 || (fdbuf.st_mode & S_IFMT) != S_IFREG)) { 25 error (_("%s must be a plain file 26 with one link"), filename); 27 close (fd); 28 return EINVAL; 29 } 30 /* If we get here, all checks passed. 31 Start using the file */ 32 read(fd, ...)

Squat during ! create! Symbolic link! Hard link, ! race conditions!

slide-11
SLIDE 11

CSE543 - Introduction to Computer and Network Security Page

Fundamental Problem

11

  • Security problems occur because low-integrity

adversary processes share the same OS namespaces as high-integrity victim processes!

  • Adversary processes attempt to affect name resolution of

victim processes!

  • Permissions for /var/mail!
  • Group mail can create and delete files
slide-12
SLIDE 12

CSE543 - Introduction to Computer and Network Security Page

STING Approach

12

  • Thus, we have to actively change the namespace to

create adversarial scenarios!

  • And evaluate process response to scenario!
  • We take inspiration from “grey-box” testing!
  • Feed known adversarial inputs to programs and examine

process response (e.g., detect SQL injection vulnerability)!

V! Generate! Adversarial! Input! Study! Program ! Response!

‘test’; drop table name; db.exec(‘drop table name’);

Vulnerable!!

slide-13
SLIDE 13

CSE543 - Introduction to Computer and Network Security Page

Adversary Accessibility

13

  • Under DAC adversary model!
  • Only 4% (Fedora) and 5.7% (Ubuntu) of total name

resolution entrypoints were accessible to adversaries!

  • Only 0.3% (Fedora) and 0.9% (Ubuntu) of total name

resolutions were vulnerable!

slide-14
SLIDE 14

CSE543 - Introduction to Computer and Network Security Page

Vulnerabilities Found

14

Program Vuln.

  • Priv. Escalation

Distribution Previously Entry DAC: uid->uid known dbus-daemon 2 messagebus->root Ubuntu Unknown landscape 4 landscape->root Ubuntu Unknown Startup scripts (3) 4 various->root Ubuntu Unknown mysql 2 mysql->root Ubuntu 1 Known mysql upgrade 1 mysql->root Ubuntu Unknown tomcat script 2 tomcat6->root Ubuntu Known lightdm 1 *->root Ubuntu Unknown bluetooth-applet 1 *->user Ubuntu Unknown java (openjdk) 1 *->user Both Known zeitgeist-daemon 1 *->user Both Unknown mountall 1 *->root Ubuntu Unknown mailutils 1 mail->root Ubuntu Unknown bsd-mailx 1 mail->root Fedora Unknown cupsd 1 cups->root Fedora Known abrt-server 1 abrt->root Fedora Unknown yum 1 sync->root Fedora Unknown x2gostartagent 1 *->user Extra Unknown 19 Programs 26 21 Unknown

slide-15
SLIDE 15

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?

15

slide-16
SLIDE 16

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • What do you need to check for?

16

slide-17
SLIDE 17

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • Expensive and incomplete

17 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Resource Retrieval

  • Check for symbolic link

(lstat)

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

component (safe_open)

  • /, var, mail, …
  • Programmers fail to get

these checks right – retrofit!

  • 4*path_length additional

syscalls for each open()

  • Too expensive!

104

slide-18
SLIDE 18

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • What do you need to check for?

18 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Code Filters - Inefficient

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

resource access checks

18

slide-19
SLIDE 19

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • What do you need to check for?
  • When should programmers apply such defenses?

19

slide-20
SLIDE 20

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • What do you need to check for?
  • When should programmers apply such defenses?

20 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Deployment

Cause - Multiple Parties

22

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-21
SLIDE 21

CSE543 - Introduction to Computer and Network Security Page

Preventions

  • How to prevent such vulnerabilities?
  • Add checks in your program to make sure that you are

protected from such attacks

  • What do you need to check for?
  • When should programmers apply such defenses?
  • Add checks in the system to make sure that programs

are protected from such attacks

  • What does the system know about programs use of files?

21

slide-22
SLIDE 22

CSE543 - Introduction to Computer and Network Security Page

System Defenses

  • How do you know what a program really wants?
  • In general, the system cannot know the programmers’

intents [Cai et al. Oakland 2009]

  • Maybe we can find some problems…

22

slide-23
SLIDE 23

CSE543 - Introduction to Computer and Network Security Page

System Defenses

  • How do you know what a program really wants?
  • One proposal - Safe Open [Chari et al. NDSS 2011]
  • If you want to open a file owned by “root”
  • You should only use bindings owned by “root” to access that

file

  • E.g., open /etc/passwd via /etc
  • Not /home/badguy/malice
  • Where malice is a link to /etc
  • Premise: Don’t use an “unsafe” name for a file if a “safe”
  • ne exists
  • What is safe and unsafe? What if program provides an

unsafe name to access an unsafe file? Or vice versa?

23

slide-24
SLIDE 24

CSE543 - Introduction to Computer and Network Security Page

System Defenses

  • How do you know what a program really wants?
  • One proposal - Safe Open [Chari et al. NDSS 2011]
  • If you want to open a file owned by “root”
  • You should only use bindings owned by “root” to access that

file

  • E.g., open /etc/passwd via /etc
  • Not /home/badguy/malice
  • Where malice is a link to /etc
  • Premise: Don’t use an “unsafe” name for a file if a “safe”
  • ne exists
  • What if program provides an unsafe name to access an

unsafe file? Or vice versa?

24 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Solution Overview

  • Match programmer expectation onto system
  • Irrespective of OS access control or admin

configuration

  • If programmer expects to access only , then

they should not access

  • Unexpected attack surface
  • If programmer expects , then they should

not access

  • Well-known “confused deputy”

23

slide-25
SLIDE 25

CSE543 - Introduction to Computer and Network Security Page

System Defenses

  • How do you know what a program really wants?
  • One proposal - Safe Open [Chari et al. NDSS 2011]
  • If you want to open a file owned by “root”
  • You should only use bindings owned by “root” to access that

file

  • E.g., open /etc/passwd via /etc
  • Not /home/badguy/malice
  • Where malice is a link to /etc
  • Premise: Don’t use an “unsafe” name for a file if a “safe”
  • ne exists
  • What if program provides an unsafe name to access an

unsafe file? Or vice versa?

25 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

  • Write

defensive checks (filters) to protect resource accesses

  • Name filters
  • Binding filters

Resource Access Filters

28

slide-26
SLIDE 26

CSE543 - Introduction to Computer and Network Security Page

System Defenses

  • How do you know what a program really wants?
  • One proposal - Safe Open [Chari et al. NDSS 2011]
  • If you want to open a file owned by “root”
  • You should only use bindings owned by “root” to access that

file

  • E.g., open /etc/passwd via /etc
  • Not /home/badguy/malice
  • Where malice is a link to /etc
  • Premise: Don’t use an “unsafe” name for a file if a “safe”
  • ne exists
  • What if program provides an unsafe name to access an

unsafe file? Or vice versa?

26 Systems and Internet Infrastructure Security Laboratory (SIIS) Page

.htpasswd Vulnerability

  • Apache allows users to specify a password file to protect

their pages in .htaccess

  • Neither name flow nor binding is filtered
  • User can specify any password file, even of other users, or the

system-wide /etc/passwd (if in proper format)

  • Can be used to brute-force passwords
  • No rate limit on HTTP auth (unlike terminal logins)
  • Vulnerability hidden all these years, showing importance of

automated and principled reasoning of resource access

52

slide-27
SLIDE 27

CSE543 - Introduction to Computer and Network Security Page

Take Away

  • Vulnerabilities due to controlling name resolution
  • Improper resource
  • File squatting, untrusted search path
  • Improper bindings
  • Link traversal and TOCTTOU
  • Program defenses are expensive
  • And programmers may not know when to use them
  • System defenses are incomplete
  • Unless we can deduce/determine programmer intent

27