STING: Finding Name Resolution Vulnerabilities in Programs

Transcription

1 STING: Finding Name Resolution ulnerabilities in Programs Hayawardh ijayakumar, Joshua Schiffman, Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University 1

2 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 IPC, P / var mail root 2

3 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 IPC, P open( /var/ mail/root ) / var mail root Name (filename) 2

4 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 IPC, Namespace (filesystem) P open( /var/ mail/root ) / var mail root Name (filename) 2

5 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 IPC, Namespace (filesystem) P open( /var/ mail/root ) / var mail root Name (filename) Bindings (directories) 2

6 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 IPC, Namespace (filesystem) P open( /var/ mail/root ) / var mail root Name Resource (filename) Bindings (directories) (file) 2

7 Namespace Sharing Problems 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 3

8 Attacks on Name Resolution Improper Binding Attack! Adversary controls bindings to redirect victim to a resource not under adversary s control (confused deputy)! Symbolic link, hard link attacks! ictim expects low integrity/secrecy, gets high instead root / var mail root etc passwd 4

9 Attacks on Name Resolution Improper Binding Attack! Adversary controls bindings to redirect victim to a resource not under adversary s control (confused deputy)! Symbolic link, hard link attacks! ictim expects low integrity/secrecy, gets high instead root open( /var/ / var mail root mail/root ) etc passwd 4

10 Attacks on Name Resolution Improper Binding Attack! Adversary controls bindings to redirect victim to a resource not under adversary s control (confused deputy)! Symbolic link, hard link attacks! ictim expects low integrity/secrecy, gets high instead root open( /var/ / var mail root mail/root ) A mail etc passwd 4

11 Attacks on Name Resolution Improper Binding Attack! Adversary controls bindings to redirect victim to a resource not under adversary s control (confused deputy)! Symbolic link, hard link attacks! ictim expects low integrity/secrecy, gets high instead root open( /var/ / var mail root mail/root ) A mail etc passwd Link 4

12 Attacks on Name Resolution Improper Binding Attack! Adversary controls bindings to redirect victim to a resource not under adversary s control (confused deputy)! Symbolic link, hard link attacks! ictim expects low integrity/secrecy, gets high instead root open( /var/ / var mail root mail/root ) A mail etc passwd Link 4

13 Attacks on Name Resolution Improper Resource Attack! Adversary controls final resource in unexpected ways! Untrusted search paths (e.g., Trojan library), file squatting! ictim expects high integrity, gets low integrity instead owner root root / var mail root 5

14 Attacks on Name Resolution Improper Resource Attack! Adversary controls final resource in unexpected ways! Untrusted search paths (e.g., Trojan library), file squatting! ictim expects high integrity, gets low integrity instead root open( /var/ owner root / var mail root mail/root ) 5

15 Attacks on Name Resolution Improper Resource Attack! Adversary controls final resource in unexpected ways! Untrusted search paths (e.g., Trojan library), file squatting! ictim expects high integrity, gets low integrity instead root open( /var/ owner root / var mail root mail/root ) A mail 5

16 Attacks on Name Resolution Improper Resource Attack! Adversary controls final resource in unexpected ways! Untrusted search paths (e.g., Trojan library), file squatting! ictim expects high integrity, gets low integrity instead root open( /var/ owner mail / var mail root mail/root ) A mail 5

17 Attacks on Name Resolution Improper Resource Attack! Adversary controls final resource in unexpected ways! Untrusted search paths (e.g., Trojan library), file squatting! ictim expects high integrity, gets low integrity instead root open( /var/ owner mail / var mail root mail/root ) A mail 5

18 Attacks on Name Resolution Race Conditions! Adversary exploits non-atomicity in check and use of resource to conduct improper resource and improper binding attacks! Well-known TOCTTOU attacks root lstat( /var/ / var mail root mail/root ) etc passwd 6

19 Attacks on Name Resolution Race Conditions! Adversary exploits non-atomicity in check and use of resource to conduct improper resource and improper binding attacks! Well-known TOCTTOU attacks root open( /var/ / var mail root mail/root ) A mail etc passwd Link 7

20 How Serious a Problem? Who can launch local exploits?! Untrusted local users in a multi-user environment (e.g., university)! Remote attackers who have broken into networked programs through bugs or misconfigurations and want to further escalate privileges Downloaded malware, compromised server programs, Remote Attacker Local Attacker root 8

21 How Serious a Problem? Name resolution vulnerabilities accounts for 5-10% CE 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 9

22 Existing Program Defenses Name resolution attacks have been with us! TOCTTOU attacks first published by McPhee in 1974! Like buffer overflows known for decades Program API to convey intended context to OS! E.g., O_EXCL flag in open(): if a resource already exists, fail! mkstemp creates an unpredictable name O_NOFOLLOW don t follow a link on this name resolution openat and related allow use of same directory for access Programmers do not always use APIs properly! Lots of exceptions! Impractical to determine whether defenses should be on 10

23 Program Defenses Often don t work 11

24 Proposed System Defenses Many defenses have been proposed by researchers! And broken! Mainly for TOCTTOU Cai et al. [Oakland 2009] showed! All system defenses fundamentally limited because they do not have program knowledge Chari et al. [NDSS 2010] propose a system defense for improper binding attacks! Have false positives 12

25 This Work s Goal Given the difficulty of proper defenses, we propose actively finding name resolution vulnerabilities in programs! So programs can be fixed to perform correct checks! Or access control policies can be tightened 13

26 Prior Static Analysis 14

27 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU 14

28 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries 14

29 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries root / var mail root etc hosts 14

30 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries root open( /var/ / var mail root mail/root ) etc hosts 14

31 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries root open( /var/ mail/root ) / var mail root Adversary accessible! Needs program defense etc hosts 14

32 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries root open( /etc/ / var mail root hosts ) etc hosts 14

33 Prior Static Analysis Analyze program to find potentially vulnerable name resolution calls! Due to complexity of checks, mainly limited to TOCTTOU Deficiencies! False positives due to adversary inaccessibility! Our runtime study found only around 5% of name resolutions were accessible to adversaries root open( /etc/ hosts ) / var mail root Not adversary accessible! Needs no program defense etc hosts 14

34 Prior Runtime Analysis 15

35 Prior Runtime Analysis Have both access control policy and program system calls 15

36 Prior Runtime Analysis Have both access control policy and program system calls Still, many false positives! Program code might defend itself Manual audits impractical! In our study, only 13% of adversaryaccessible name resolutions are actually vulnerable 15

37 Prior Runtime Analysis Have both access control policy and program system calls Still, many false positives! Program code might defend itself Manual audits impractical! In our study, only 13% of adversaryaccessible name resolutions are actually vulnerable 15

38 Prior Runtime Analysis Have both access control policy and program system calls Still, many false positives! Program code might defend itself Manual audits impractical???! In our study, only 13% of adversaryaccessible name resolutions are actually vulnerable 15

39 Prior Runtime Analysis False negatives during normal runtime! Attacks require very specific conditions that do not occur in normal runtime Example: mountall untrusted search path vulnerability required:! Launching that program in an untrusted directory, and! Symbolic links named none and fusectl 16

40 Our Solution 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) 17

41 Our Solution 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) Generate Adversarial Input Study Program Response 17

42 Our Solution 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) Generate Adversarial test ; drop table name; Study Program Input Response 17

43 Our Solution 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) Generate Adversarial test ; drop table name; db.exec( drop table name ); Study Program Input Response 17

44 Our Solution 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) Generate Adversarial test ; drop table name; db.exec( drop table name ); Study Program Input Response ulnerable! 17

45 Grey-Box Test Using OS OS is in charge of namespace! Use OS to feed adversarial input in response to program name resolution requests, and study program response! System-wide testing Generate Adversarial Input Examine Program Response 18

46 Solution Overview (OS) Generate Adversarial Input / Namespace (OS) Study Program Response 19

47 Solution Overview Name res syscalls (OS) Generate Adversarial Input / Namespace (OS) Study Program Response 19

48 Solution Overview Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace (OS) Study Program Response 19

49 Solution Overview Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace All syscalls (OS) Study Program Response 19

50 Solution Overview Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

51 Solution Overview Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

52 Solution Overview System-wide? Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

53 Solution Overview System-wide? Adversary accessibility? Name res syscalls (OS) Generate Adversarial Input Modify Namespace / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

54 Solution Overview System-wide? Adversary accessibility? Name res syscalls (OS) Generate Adversarial Input Bindings adversary accessible? Modify Namespace Access Control Policy / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

55 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls (OS) Generate Adversarial Input Bindings adversary accessible? Modify Namespace Access Control Policy / Namespace All syscalls Accept? ulnerable! (OS) Study Program Response 19

56 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace / Access Control Policy Namespace 19

57 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace / Access Control Policy Namespace Reject Resource? 19

58 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace / Access Control Policy Namespace Reject Resource? 19

59 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace / Access Control Policy Namespace Reject Resource? Rollback Namespace? 19

60 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace Rollback Namespace / Access Control Policy Namespace Reject Resource? Rollback Namespace? 19

61 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Bindings adversary accessible? Modify Namespace Rollback Namespace / Access Control Policy Namespace Reject Resource? Rollback Namespace? 19

62 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Launch Phase Bindings adversary accessible? Modify Namespace Rollback Namespace / Access Control Policy Namespace Reject Resource? Rollback Namespace? 19

63 Solution Overview System-wide? Adversary accessibility? Manage Attacks? Name res syscalls All syscalls (OS) Generate Adversarial Input Not Already Attacked? Reject? Not vulnerable! Attack History Accept? ulnerable! (OS) Study Program Response Launch Phase Detect Phase Bindings adversary accessible? Modify Namespace Rollback Namespace / Access Control Policy Namespace Reject Resource? Rollback Namespace? 19

64 Launch Phase ictim (user root) User-space / Kernel etc var mail passwd root 20

65 Launch Phase ictim (user root) User-space / Kernel etc var mail passwd root 20

66 Launch Phase ictim (user root) fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail passwd root 20

67 Launch Phase ictim (user root) fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail passwd root 20

68 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail passwd root 20

69 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail passwd root 20

70 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail passwd root 20

71 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail Adversary (group mail) passwd root 20

72 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** 2"#3,4&15#,6,17# 89:'%;0#&,9.*<,1.= fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail Adversary (group mail) passwd root 20

73 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** 2"#3,4&15#,6,17# 89:'%;0#&,9.*<,1.= fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail Adversary (group mail) passwd root delete( /var/mail/root ); symlink( /etc/passwd, /var/mail/root ) 20

74 Launch Phase ictim (user root)!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** 2"#3,4&15#,6,17# 89:'%;0#&,9.*<,1.= fd = open( /var/mail/root, O_APPEND) / User-space Kernel etc var mail Adversary (group mail) passwd root delete( /var/mail/root ); symlink( /etc/passwd, /var/mail/root ) 20

75 Launch Phase ictim (user root) fd = open( /var/mail/root, O_APPEND) /!"#$%&'#(%&'%&)* +"#$%&'#,'-./*,/0#,11.** 2"#3,4&15#,6,17# 89:'%;0#&,9.*<,1.= >"#?:&@&4.#*0*A.9#1,BB User-space Kernel etc var mail Adversary (group mail) passwd root delete( /var/mail/root ); symlink( /etc/passwd, /var/mail/root ) 20

76 Detect Phase ictim (user root) User-space / Kernel etc var mail passwd root 21

77 Detect Phase ictim (user root) User-space / Kernel etc var mail passwd root 21

78 Detect Phase ictim (user root) write(fd) / User-space Kernel etc var mail passwd root 21

79 Detect Phase ictim (user root) write(fd) / User-space Kernel etc var mail passwd root 21

80 Detect Phase ictim (user write(fd) / User-space Kernel etc var mail passwd root 21

81 Detect Phase ictim (user write(fd) / User-space Kernel etc var mail passwd root 21

82 Detect Phase ictim (user +"#D.1:/'#-4B&./,(%B%A0 write(fd) / User-space Kernel etc var mail passwd root 21

83 Detect Phase ictim (user +"#D.1:/'#-4B&./,(%B%A0 2"#D:BB(,17#&,9.*<,1. write(fd) / User-space Kernel etc var mail passwd root 21

84 Detect Phase ictim (user +"#D.1:/'#-4B&./,(%B%A0 2"#D:BB(,17#&,9.*<,1. write(fd) / User-space Kernel etc var mail passwd root 21

85 Detect Phase ictim (user +"#D.1:/'#-4B&./,(%B%A0 2"#D:BB(,17#&,9.*<,1. >"#D.*A,/A#*0*A.9#1,BB write(fd) / User-space Kernel etc var mail passwd root 21

86 Find Accessible Bindings root open( /var/ mail/root ) / var mail root etc passwd 22

87 Find Accessible Bindings Find bindings - Shadow resolution! Extract name resolution code inside kernel and obtain bindings before system call starts root open( /var/ mail/root ) / var mail root etc passwd 22

88 Find Accessible Bindings Find bindings - Shadow resolution! Extract name resolution code inside kernel and obtain bindings before system call starts root open( /var/ mail/root ) / var mail root etc passwd 22

89 Find Accessible Bindings Find bindings - Shadow resolution! Extract name resolution code inside kernel and obtain bindings before system call starts Find adversary-accessible bindings - Adversary model! Use access control policy DAC model: Any other user apart from root MAC model: (SELinux) root open( /var/ mail/root ) / var mail root etc passwd 22

90 Find Accessible Bindings Find bindings - Shadow resolution! Extract name resolution code inside kernel and obtain bindings before system call starts Find adversary-accessible bindings - Adversary model! Use access control policy DAC model: Any other user apart from root MAC model: (SELinux) root open( /var/ mail/root ) / var mail root A mail etc passwd 22

91 Launching an Attack root open( /var/ mail/root ) / var mail root A mail etc passwd 23

92 Launching an Attack Modify namespace to generate attack test case! Existing data should be backed up! Unix domain sockets, cannot be recovered if deleted! Attack should be visible only to victims of the adversary Not to all processes root open( /var/ mail/root ) / var mail root A mail etc passwd 23

93 Launching an Attack Modify namespace to generate attack test case! Existing data should be backed up! Unix domain sockets, cannot be recovered if deleted! Attack should be visible only to victims of the adversary Not to all processes root A mail open( /var/ mail/root ) / var mail root etc passwd Link 23

94 Launching an Attack 24

95 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs 24

96 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Read-write upper branch Read-only lower branch /var/root/mail 24

97 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Read-write upper branch /var/root/mail Read-only lower branch /var/root/mail 24

98 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call Read-write upper branch /var/root/mail Read-only lower branch /var/root/mail 24

99 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call Adversary upper branch /var/root/mail Original fs lower branch /var/root/mail 24

100 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call A Adversary upper branch /var/root/mail Original fs lower branch /var/root/mail 24

101 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call Adversary upper branch A /var/root/mail A is adversary Original fs lower branch /var/root/mail 24

102 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call Adversary upper branch Original fs lower branch A /var/root/mail /var/root/mail A is adversary A is not adversary 24

103 Launching an Attack Solution - Union filesystems! Combines lower read-only and upper read-write fs Adversary changes only upper filesystem! Show upper or lower branch depending on adversary and system call Adversary upper branch Original fs lower branch A /var/root/mail /var/root/mail A is adversary A is not adversary stat() 24

104 Manage Attacks 25

105 Manage Attacks Only run an attack test case once! How to identify current system call originates from code that has already been tested? 25

106 Manage Attacks Only run an attack test case once! How to identify current system call originates from code that has already been tested? Program entry points as unique identifiers! Program instruction calling library that performs system call Obtained by user-stack backtrace within kernel Extensions for interpreters (11-59 LOC per interpreter) 25

107 Manage Attacks Only run an attack test case once! How to identify current system call originates from code that has already been tested? Program entry points as unique identifiers! Program instruction calling library that performs system call Obtained by user-stack backtrace within kernel Extensions for interpreters (11-59 LOC per interpreter)./a.out./a.out libc libc (syscall) 25

108 Manage Attacks Only run an attack test case once! How to identify current system call originates from code that has already been tested? Program entry points as unique identifiers! Program instruction calling library that performs system call Obtained by user-stack backtrace within kernel Extensions for interpreters (11-59 LOC per interpreter)./a.out./a.out libc libc (syscall) 25

109 Detect ulnerability How do we know victim process has accepted or rejected the resource? Accept resource! Program uses accept system calls on test case ( upper layer ) resource Reject resource! Program retries system call at same entry point or exits without accepting 26

110 Detect ulnerability Acceptance for attacks we consider! Not all system calls on tainted resources signify vulnerabilities. 27

111 Recovery and Rollback Namespace rollback! Wipe adversarial resource from upper branch Further name resolutions get resource from lower branch! Since we operate at FS layer, we can redirect open file descriptors to lower layer Process recovery! Some processes retry we don t do anything! For those that exit we restart process Linux has some rollback facilities we will examine, if necessary 28

112 Implementation STING as a kernel patch for Linux 2.6 and 3! ~2700 LOC User-space support! Init ramdisk scripts to mount stacked filesystem, load attack history log, load adversary model We have a package for Ubuntu 12.04! apt-get install sting Once installed, STING automatically starts testing the whole system! No special runtime environment or setup needed 29

113 Results - ulnerabilities 30

114 Results - ulnerabilities Both old and new programs 30

115 Results - ulnerabilities Special users to root 30

116 Results - ulnerabilities Known but unfixed! 30

117 Results - ulnerabilities 30

118 ulnerabilities by Entrypoint 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 31

119 ulnerabilities by Entrypoint 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 Static Analysis False + 31

120 ulnerabilities by Entrypoint 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 Static Analysis False + Normal Runtime False + 31

121 STING detects TOCTTOU races STING can deterministically create races, as it is in the system ictim Adversary 32

122 STING detects TOCTTOU races STING can deterministically create races, as it is in the system ictim Adversary 32

123 STING detects TOCTTOU races STING can deterministically create races, as it is in the system ictim Adversary 32

124 STING detects TOCTTOU races STING can deterministically create races, as it is in the system ictim Adversary 32

125 STING creates scenarios That do not occur in normal runtime 33

126 STING creates scenarios That do not occur in normal runtime Adversary 33

127 STING creates scenarios That do not occur in normal runtime Adversary ictim 33

128 STING creates scenarios That do not occur in normal runtime Adversary ictim 33

129 Detects easily overlooked 34

130 Detects easily overlooked Manual checks can easily overlook vulnerabilities 34

131 Detects easily overlooked Manual checks can easily overlook vulnerabilities Squat during create 34

132 Detects easily overlooked Manual checks can easily overlook vulnerabilities Squat during create Symbolic link 34

133 Detects easily overlooked Manual checks can easily overlook vulnerabilities Squat during create Symbolic link Hard link, race conditions 34

134 Detects easily overlooked Manual checks can easily overlook vulnerabilities Squat during create But, misses already existing file squat! Symbolic link Hard link, race conditions 34

135 Shows OS distributor challenge STING also found vulnerabilities where the problem seemed to be the system s access control policy! When contacted, a developer refused to fix bug claiming fault in system s access control policy! We found other vulnerabilities that seemed better fixed by the access control than code E.g., postgres init script 35

136 Performance STING causes around 8% overhead on macrobenchmarks! Noticeable overhead, but we were able to use system! We are looking for further avenues to improve performance 36

137 Conclusions Name resolution is a fundamental process! But, has long been vulnerable to various attacks It is both difficult to prevent name resolution attacks and find program vulnerabilities! We use runtime grey-box testing STING is a system-wide, online tool that finds name resolution vulnerabilities in programs! By producing malicious test case when a program s adversary can modify bindings used in resolution Found 21 previously-unknown vulnerabilities! Highlights various issues 37

138 Availability STING webpage : Please contact hvijay@cse.psu.edu for access to repository We envision STING be used on distributions during testing (e.g., alpha, beta) or by administrators on test systems before deployment to fix vulnerabilities before adversaries exploit them We have a package for Ubuntu 12.04! apt-get install sting 38

139 Thank You! Questions? for contact : hvijay@cse.psu.edu 39

140 Results Retry vs Restart Around 32% of programs retried, whereas the rest had to be restarted! Programs that retry integrate well with STING! Restarted programs may lose state! We are investigating integrating process checkpointing for graceful recovery of process state 40

141 Guarantees If a process accepts an adversarial resource! There is a vulnerable name resolution! Reads may not be exploitable Depends on program internals 41