cse543 - introduction to computer and network security...

CSE543 - Introduction to Computer and Network Security Page

CSE543 - Introduction to Computer and Network SecurityModule: Software Vulnerabilities

Professor Trent Jaeger

1Sunday, September 30, 12


Programming• Why do we write programs?‣ Function

• What functions do we enable via our programs?‣ Some we want -- some we don’t need‣ Adversaries take advantage of such “hidden” function



A Simple Program

int authenticated = 0; char packet[1000];

while (!authenticated) { PacketRead(packet); if (Authenticate(packet)) authenticated = 1; } if (authenticated) ProcessPacket(packet);



A Simple Programint authenticated = 0; char packet[1000];


4

What if packet is larger than 1000 bytes?

Sunday, September 30, 12


Address Space Layout• Stack‣ Can write the stack vars without

limits

• Type Safety‣ Can write outside a data structure

using its reference

• Execution Integrity‣ Can jump to arbitrary points in

the program• Function pointers

• Return addresses

5

Text

Data

Stack

Heap



Buffer Overflow• How it works

6

Local Var

Buffer

Local Var

Return Address

Func Parameters

Previous Function

New Rtn

Evil CodeEvil

Code

Stac

k Fr

ame



Buffer Overflow Defense• “Canary” on the stack‣ Random value placed

between the local vars and the return address

‣ If canary is modified, program is stopped

• Alternative:‣ How does this

prevent return-to-libc?

• Are we done?

7

Local Var

Buffer

Local Var

Return Address

Func Parameters

Previous Function

CANARY



A Simple Programint authenticated = 0; char packet[1000];


8

What if packet is only 1004 bytes?



Overflow of Local Variables• Don’t need to modify return address‣ Local variables may affect control

• What kinds of local variables would impact control?‣ Ones used in conditionals (example)‣ Function pointers

• What can you do to prevent that?



A Simple Programint authenticated = 0; char *packet = (char *)malloc(1000);


10

What if we allocate thepacket buffer on the heap?



Heap Overflow• Overflows may occur on the

heap also‣ Heap has data regions and

metadata

• Attack‣ Write over heap with target

address (heap spraying)‣ Hope that victim uses an

overwritten function pointer before program crashes



Another Simple Programint size = BASE_SIZE; char *packet = (char *)malloc(1000);char *buf = (char *)malloc(1000+BASE_SIZE);

strcpy(buf, FILE_PREFIX); size += PacketRead(packet); if ( size < sizeof(buf)) { strcat(buf, packet); fd = open(buf); }

12

Any problem with thisconditional check?



Integer Overflow• Signed variables represent positive and negative values‣ Consider an 8-bit integer: -128 to 127‣ Weird math: 127+1 = ???

• This results in some strange behaviors‣ size += PacketRead(packet) • What is the possible value of size?

‣ if ( size < sizeof(buf)) {• What is the possible result of this condition?

• How do we prevent these errors?



A Simple Programint authenticated = 0; char *packet = (char *)malloc(1000);

while (!authenticated) { PacketRead(packet); if (Authenticate(packet)) authenticated = 1; } if (authenticated) ProcessQuery(“Select”, partof(packet));

14

Any problem with this query request?



Parsing Errors• Have to be sure that user input can only be used for expected function

‣ SQL injection: user provides a substring for an SQL query that changes the query entirely (e.g., add SQL operations to query processing)

SELECT fieldlist

FROM table

WHERE field = 'anything' OR 'x'='x';

• Goal: format all user input into expected types and ranges of values‣ Integers within range

‣ Strings with expected punctuation, range of values

• Many scripting languages convert data between types automatically -- are not type-safe -- so must be extra careful



Character Strings• String formats‣ Unicode• ASCII -- 0x00 -- 0x7F

• non-ASCII -- 0x80 -- 0xF7

• Also, multi-byte formats

‣ Decoding is a challenge• URL: [IPaddr]/scripts/..%c0%af../winnt/system32

• Decodes to /winnt/system32

‣ Markus Kuhn’s page on Unicode resources for Linux• www.cl.cam.ac.uk/~mgk25/unicode.html


http://www.cl.cam.ac.uk/~mgk25/unicode.htm

http://www.cl.cam.ac.uk/~mgk25/unicode.htm


Secure Programming• David Wheeler’s Secure Programming for Linux and

UNIX‣ Validate all input; Only execute application-defined inputs!‣ Avoid buffer overflows (and other code injection problems)‣ Minimize process privileges‣ Carefully invoke other resources‣ Send information back carefully

17

ServerBadValidate Input

Avoid Overflows

Minimize Privilege

WorkerInvoke Safely

Return little



Name Resolution

18Systems 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!




21

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!









7

mail!var!!!Vroot!

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

etc! passwd!Amail!









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 Sunday, September 30, 12


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 Sunday, September 30, 12


Vulnerabilities Found

30

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].



Take Away• Programs have function‣ Adversaries can exploit unexpected functions

• Vulnerabilities due to malicious input ‣ Buffer overflows‣ Heap overflows‣ Injection attacks

• Is an integer overflow possible in type-safe languages? ‣ E.g., Java

• Vulnerabilities due to controlling name resolution‣ Improper resource: file squatting, untrusted search path‣ Improper bindings: link traversal and TOCTTOU


cse543 - introduction to computer and network security...

Documents