cse543 - introduction to computer and network security...

CSE543 - Introduction to Computer and Network Security Page

CSE543 - Introduction to Computer and Network Security

Module: System Vulnerabilities

Professor Trent Jaeger

1


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


Name Resolution

3Systems 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, …!

2

/! var! mail! root!P! open(“/var/ mail/root”)

Name!(filename)" Bindings (directories)"

Resource (file)"

Namespace (filesystem)"

/! var! mail! root!


Attacks on Name Resolution



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

5

mail!var!!!

open(“/var/ mail/root”) /! root!var! mail! root!

owner root

root!

Amail!

Vroot!





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

6

mail!var!!!

open(“/var/ mail/root”) /! root!var! mail! root!

owner mail

Amail!

Vroot!



6

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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!

4

!!

open(“/var/ mail/root”) /! root!var! mail!var! mail!/!

etc! passwd!passwd!

root!root!Vroot!

Amail!





•  Race Conditions!

‣  Adversary exploits non-atomicity in “check” and “use” of resource to conduct improper resource and improper binding attacks!

‣  Well-known “TOCTTOU” attacks !

7

mail!var!!!Vroot!

lstat(“/var/ mail/root”) /! root!var! mail!

etc! passwd!Amail!





•  Race Conditions!

‣  Adversary exploits non-atomicity in “check” and “use” of resource to conduct improper resource and improper binding attacks!

‣  Well-known “TOCTTOU” attacks !

9

mail!var!!!Vroot! /! root!var! mail!var! mail!/!

etc! passwd!passwd!

root!root!root!open(“/var/ mail/root”)

Amail!


How Serious a Problem?


How Serious a Problem? •  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!

8


Difficult to Prevent


Detects easily overlooked •  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 sure12 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_dev21 || fdbuf.st_ino != filebuf.st_ino22 || fdbuf.st_nlink != 123 || filebuf.st_nlink != 124 || (fdbuf.st_mode & S_IFMT) != S_IFREG)) {25 error (_("%s must be a plain file26 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!


Fundamental Problem


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


STING Approach


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

15

V!Generate!

Adversarial!Input!

Study!Program !Response!

‘test’; drop table name;

db.exec(‘drop table name’);

Vulnerable!!


Adversary Accessibility


Vulnerabilities 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


Vulnerabilities Found

14

Adversary model Total Resolutions Adversary Access VulnerableDAC - Ubuntu 2345 134 (5.7%) 21 (0.9%)DAC - Fedora 1654 66 (4%) 5 (0.3%)

Table 4: Table showing the total number of distinct entrypointsinvoking system calls performing namespace resolutions, num-ber accessible to adversaries under an adversary model, andnumber of interfaces for which STING detected vulnerabilities.

6.1.1 Finding Vulnerabilities

Using a DAC attacker model, in total, STING found26 distinct vulnerable resolutions across 20 distinct pro-grams (including scripts). Of the 26 vulnerable resolu-tions, 5 correspond to problems already known but un-fixed. 17 of these vulnerabilities are latent [13], meaninga normal local user would have to gain privileges of someother user and can then attempt further attacks. For ex-ample, one bug we found required the privileges of theuser postgres to carry out a further attack on root.This can be achieved, for example, by remote networkattackers compromising the PostgreSQL daemon. Forall vulnerabilities found, we manually verified the sourcecode that a name resolution vulnerability existed. Sev-eral bugs were reported, of which 2 were deemed notexploitable (although a name resolution vulnerability ex-isted) (Section 6.1.3).

Table 4 shows the total number of distinct name res-olutions received by STING that were attackable . Thisdata shows challenges facing static and normal runtimeanalysis. Only 4-5.7% of the total name resolutionsare accessible to the adversary under the DAC adver-sary model. Therefore, static analysis that looks at theprogram alone will have a large number of false pos-itives, because programs do not have to protect them-selves from name resolutions inaccessible to the adver-sary. Second, normal runtime analysis cannot differen-tiate between when programs are vulnerable and whenthey protect themselves appropriately. We found < 1%of the name resolutions accessible to the adversary areactually vulnerable to different name resolution attacks.Further, 6 of these vulnerabilities would simply not havebeen uncovered during normal runtime; they are un-trusted search paths they require programs to be launchedin insecure directories.

Table 5 shows the total number of vulnerabilities bytype. A single entrypoint may be vulnerable to more thanone type of attack. We note that STING was able to findvulnerabilities of all types, including 7 that required raceconditions.

Table 6 shows the various programs across which vul-nerabilities were found. Interestingly, we note that 6of the 24 vulnerable name resolutions in Ubuntu werefound in Ubuntu-specific scripts. For example, CVE-

Type of vulnerability TotalSymlink following 22Hardlink following 14File squatting 10Untrusted search 6Race conditions 7

Table 5: Number and types of vulnerabilities we found. Raceis the number of TOCTTOU vulnerabilities, where a check ismade but the use is improper. A single entrypoint in Table 6may be vulnerable to more than one kind of attack.

Program Vuln. Priv. Escalation Distribution PreviouslyEntry DAC: uid->uid known

dbus-daemon 2 messagebus->root Ubuntu Unknownlandscape 4 landscape->root Ubuntu UnknownStartup scripts (3) 4 various->root Ubuntu Unknownmysql 2 mysql->root Ubuntu 1 Knownmysql upgrade 1 mysql->root Ubuntu Unknowntomcat script 2 tomcat6->root Ubuntu Knownlightdm 1 *->root Ubuntu Unknownbluetooth-applet 1 *->user Ubuntu Unknownjava (openjdk) 1 *->user Both Knownzeitgeist-daemon 1 *->user Both Unknownmountall 1 *->root Ubuntu Unknownmailutils 1 mail->root Ubuntu Unknownbsd-mailx 1 mail->root Fedora Unknowncupsd 1 cups->root Fedora Knownabrt-server 1 abrt->root Fedora Unknownyum 1 sync->root Fedora Unknownx2gostartagent 1 *->user Extra Unknown19 Programs 26 21 Unknown

Table 6: Number of vulnerable entrypoints we found in vari-ous programs, and the privilege escalation that the bugs wouldprovide.

2011-4406 and CVE-2011-3151 were assigned to twobugs in Ubuntu-specific scripts that STING found. Fur-ther, the programs containing vulnerabilities range frommature (e.g., cupsd) to new (e.g., x2go). We thus be-lieve that STING can help in detecting vulnerabilities be-fore an adversary, if run on test environments before theyare deployed.

MAC adversary model. We carried out similar ex-periments for a MAC adversary model on Fedora 16’sdefault SELinux policy. We assume an adversary limitedonly by the MAC labels, and allow the adversary per-missions to run as the same DAC user. This is one of theaims of SELinux – even if a network daemon running asroot gets compromised, it should still not compromisethe whole system arbitrarily. However, we found that theSELinux policy allowed subjects we consider untrusted(such as the network-facing daemon sendmail_t) cre-ate permissions to critical labels such as etc_t. ThusSTING immediately started reporting vulnerable nameresolutions whenever any program accessed /etc. Thus,either the SELinux policy has to be made stricter, the ad-versary model must be weakened for mutual trust amongall these programs, or all programs have to defend them-selves from name resolution attacks in /etc (which isprobably impractical). This problem is consistent withthe findings that /etc requires exceptional trust in theSELinux policy reported elsewhere [42].


Preventions• How to prevent such vulnerabilities?

15


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



protected from such attacks• Expensive and incomplete


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



protected from such attacks• What do you need to check for?


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



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

19





Deployment

Cause - Multiple Parties

22

ProgrammerAdministrator OS distributor

CodeConfiguration Access Control Policy

??? ???

open(config_file) open(html_file) open(tmp_file) mismatch

mismatch

Expectations mismatch, blame each other




• 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


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


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” one exists• What is safe and unsafe? What if program provides an

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




file


• Premise: Don’t use an “unsafe” name for a file if a “safe” one exists• What if program provides an unsafe name to access an

unsafe file? Or vice versa? 24Systems 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




file




•  Write defensive checks (filters) to protect resource accesses‣  Name filters

‣  Binding filters

Resource Access Filters

28




file




.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


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

cse543 - introduction to computer and network security...

Documents