STING: Finding Name Resolution Vulnerabilities in Programs

Hayawardh Vijayakumar, Joshua Schiffman and Trent JaegerSystems and Internet Infrastructure Security Laboratory,

Department of Computer Science and Engineering,The Pennsylvania State University

{hvijay,jschiffm,tjaeger}@cse.psu.edu

AbstractThe process of name resolution, where names are re-solved into resource references, is fundamental to com-puter science, but its use has resulted in several classesof vulnerabilities. These vulnerabilities are difficult forprogrammers to eliminate because their cause is exter-nal to the program: the adversary changes namespacebindings in the system to redirect victim programs to aresource of the adversary’s choosing. Researchers havealso found that these attacks are very difficult to preventsystematically. Any successful defense must have bothknowledge about the system namespace and the programintent to eradicate such attacks. As a result, finding andfixing program vulnerabilities to such as attacks is ourbest defense. In this paper, we propose the STING testengine, which finds name resolution vulnerabilities inprograms by performing a dynamic analysis of name res-olution processing to produce directed test cases when-ever an attack may be possible. The key insight is thatsuch name resolution attacks are possible whenever anadversary has write access to a directory shared with thevictim, so STING automatically identifies when such di-rectories will be accessed in name resolution to producetest cases that are likely to indicate a true vulnerabilityif undefended. Using STING, we found 21 previously-unknown vulnerabilities in a variety of Linux programson Ubuntu and Fedora systems, demonstrating that com-prehensive testing for name resolution vulnerabilities ispractical.

1 Introduction

The association between names and resources is funda-mental to computer science. Using names frees computerprogrammers from working with physical references toresources, allowing the system to store resources in theway that it sees fit, and enables easy sharing of resources,where different programs may use the different names for

the same object. When a program needs access to a re-source, it presents a name to a name server, which usesa mechanism called name resolution to obtain the corre-sponding resource.

While name resolution simplifies programming inmany ways, its use has also resulted in several typesof vulnerabilities that have proven difficult to eliminate.Adversaries may control inputs to the name resolutionprocess, such as namespace bindings, which they canuse to redirect victims to resources of the adversaries’choosing. Programmers often fail to prevent such at-tacks because they fail to validate names correctly, fol-low adversary-supplied namespace bindings, or lack in-sight into which resources are accessible to adversaries.Table 1 lists some of the key classes of these vulnerabil-ities.

While a variety of system defenses for these attackshave been proposed, particularly for name resolution at-tacks based on race conditions [14, 20, 22, 39, 40, 48, 50–52, 57], researchers have found that such defenses arefundamentally limited by a lack of knowledge about theprogram [12]. Thus, the programmers’ challenge is tofind such vulnerabilities before adversaries do. How-ever, finding such vulnerabilities is difficult because thevectors for name resolution attacks are outside the pro-gram. Table 1 shows that adversaries may control names-pace bindings to redirect victims to privileged resourcesof their choice, using what we call improper binding at-tacks or redirect victims to resources under the adver-saries’ control, using what we call improper resource at-tacks. Further, both kinds of attacks may leverage thenon-atomicity of various system calls to create races,such as the time-of-check-to-time-of-use (TOCTTOU)attacks [6,38], which makes them even more difficult forvictims to detect.

Researchers have explored the application of dynamicand static analysis to detect namespace resolution at-tacks. Dynamic analyses [1, 32, 35, 36, 56] log observedsystem calls to detect possible problems, such as check-

Attack CWE IDImproper Binding AttacksUNIX Symlink Following CWE-61UNIX Hard Link Following CWE-62Improper Resource AttacksResource Squatting CWE-283Untrusted Search Path CWE-426Attacks Caused by Either Bindings or ResourcesTOCTTOU Race Condition CWE-362

Table 1: Classes of name resolution attacks.

use pairs that may be used in TOCTTOU attacks. How-ever, the existence of problems does not necessarilymean that the program is vulnerable. Many of the check-use pairs found were not exploitable. Static analyses usesyntactic analyses [6,53] and/or semantic models of pro-grams to check for security errors [15, 44], sometimesfocusing on race conditions [27]. These static analysesdo not model the system environment, however, so theyoften produce many false positives. In addition, severalof these analyses result in false negatives as they relyon simpler models of program behavior (e.g., finite statemachines), limited alias analysis, and/or manual annota-tions.

The key insight is that such name resolution attacksare possible only when an adversary has write access toa directory shared with the victim. Using this write ac-cess, adversaries can plant files with names used by vic-tims or create bindings to redirect the victim to files ofthe adversaries’ choice. Chari et al. [14] demonstratedthat when victims use such bindings and files planted byadversaries attacks are possible, so they built a systemmechanism to authorize the bindings used in name reso-lution. However, we find that only a small percentage ofname resolutions are really accessible to adversaries andmost of those are defended by programs. Further, thesolution proposed by Chari et al. is prone to false posi-tives, as any pure system solution is, because it lacks in-formation about the programs’ expected behaviors [12].Instead, we propose to test programs for name resolu-tion vulnerabilities by having the system assume the roleof an adversary, performing modifications that an adver-sary is capable of, at runtime. Using the access controlpolicy and a list of adversarial subjects, the system candetermine whether an adversary has write access to a di-rectory to be used in a name resolution. If so, the sys-tem prepares an attack as that adversary would and de-tect whether the program was exploited or immune tothe attack (e.g., did the program follow the symbolic linkcreated?). This is akin to directed black-box testing [23],where a program is injected with a dictionary of com-monly known attacker inputs.

In this paper, we design and implement the STING test

engine, which finds name resolution vulnerabilities inprograms by performing a dynamic analysis of name res-olution processing to produce directed test cases when-ever an attack may be possible. STING is an extensionto a Linux Security Module [58] that implements the ad-ditional methods described above to provide comprehen-sive, system-wide testing for name resolution vulnera-bilities. Using STING, we found 21 previously-unknownname resolution vulnerabilities in 19 different programs,ranging from startup scripts to mature programs, such ascups, to relatively new programs, such as x2go. We de-tail several bugs to demonstrate the subtle cases that canbe found using STING. Tests were done on Ubuntu andFedora systems, where interestingly some bugs only ap-peared on one of the two systems because of differencesin the access control policies that implied different ad-versary access.

This research makes the following novel contribu-tions:

• We find that name resolution attacks are always pos-sible whenever a victim resolves a name using adirectory where its adversaries have permission tocreate files and/or links, as defined in Section 3. If avictim uses such a directory in resolving a name, anadversary may redirect them to a resource of the ad-versary’s choosing, compromising victims that usesuch resources unwittingly.

• We develop a method for generating directed testcases automatically that uses a dynamic analysis todetect when an adversary could redirect a name res-olution in Section 4.1.

• We develop a method for system-wide test case pro-cessing that detects where victims are vulnerable toname resolution attacks, restores program state tocontinue testing, and manages the testing coveragein Section 4.2.

• We implement a prototype system STING for Linux3.2.0 kernel, and run STING on the current versionsof Linux distributions, discovering 21 previously-unknown name resolution vulnerabilities in 13 dif-ferent programs. Perhaps even more importantly,STING finds that 90% of adversary-accessible nameresolutions are defended by programs correctly,eliminating many false positives.

We envision that STING could be integrated into sys-tem distribution testing to find programs that do not ef-fectively defend themselves from name resolution at-tacks given that distribution’s access control policy be-fore releasing that distribution to the community ofusers.

2 Problem Definition

Processes frequently require system level resources likefiles, libraries, and sockets. Since the system’s manage-ment of these objects is unknown to the process, namesare used as convenient references to the desired resource.A name resolution server is responsible for convertingthe requested resource name to the desired object via anamespace binding. Typical namespaces in Unix-basedsystems include the filesystem and System V IPC names-paces (semaphores, shared memory, message queues,etc.). Some namespaces may even support many-to-onemappings (e.g., multiple pathnames may be linked to thesame file inode).

Unfortunately, various name resolution attacks arepossible when an attacker is able to affect this indirectionbetween the desired resource and its name. In this sec-tion, we broadly outline two classes of name resolutionattacks and give several instances of them. We then dis-cuss how previous efforts attempt to defend against theseattacks and their limitations. Finally, we present our so-lution, STING, that overcomes many of these shortcom-ings.

V / var mail root

A

open("/var/mail/root")

Filesystem Namespace

etc passwd Link

V / var mail

root(adversary

mail contents)

A

open("/var/mail/root")

Filesystem Namespace

Improper Resource

Attack

Improper Binding Attack

- binding - resource

Figure 1: Improper binding and improper resource attacks. Aand V are adversary and victim processes respectively.

2.1 Name Resolution Attacks

Malicious parties can control the name resolution pro-cess by modifying the namespace’s binding to trickvictim processes into accessing unintended resources.We find that these attacks can be categorized into twoclasses. The first, improper binding attacks, are whenattackers introduce bindings to resources outside of theattackers control. This can give adversary indirect accessto the resource through the victim. Such attacks are in-stances of the confused deputy [33]. The second class,improper resource attacks, is when an attacker creates an

unexpected binding to a resource the adversary controls.Instances of these attacks depend on the namespace.

For example, the filesystem namespace is often exploitedthrough malicious path bindings like symbolic links andthe creation of files with frequently used names. Con-sider a mail reader program running as root attemptingto check mail from /var/mail/root. Users in the mailgroup are permitted to place files in this directory for theprogram to read and send. Figure 1 demonstrates howname resolution attacks from both categories could beperformed on this program.

• Symbolic link following: The adversary wishes toexfiltrate a protected file (/etc/passwd) that it can-not normally access. Since users in group mail arepermitted to create (and delete) bindings (files) in/var/mail, the adversary inserts a symbolic link/var/mail/root in the namespace that is bound tothe desired file. If a victim mail program running asroot does not check for this link, it might inadver-tently leak the protected file. A similar attack can belaunched through hard links. This is an instance ofan improper binding attack, where adversaries usecontrol of bindings to redirect victim programs withprivileges to access or modify resources the adver-saries cannot directly.

• Squatting: Even if the mail program defends itselfagainst link following attacks, the adversary couldsimply squat a file on /var/mail. If the mail pro-gram accepts this file, the adversary could spoof thecontents of mail read by root. This is an exampleof an improper resource attack, where the adversaryuses control of bindings to create a resource underher control when the victim does not expect to in-teract with the adversary.

• Untrusted search path: Programs frequently relyon files like system libraries or configuration files,but the names they supply to access these filesmay be wrong. One frequent cause is the programsupplying a name relative to its working directory,which causes a problem if the working directory isadversary controlled. Adversaries can then simplybind arbitrary resources at these filenames, possi-bly gaining control of the victim’s program. Thisis another instance of an improper resource attack,where the adversary supplies an improper resourceto the victim.

While the attacks an adversary can carry out are wellknown, the ways in which programs defend themselvesare often ad hoc and complex [13]. Even the mostdiligent programs may fail to catch all the ways inwhich an adversary might manipulate these namespaces.

Moreover, defenses to these attacks can often be cir-cumvented through time-of-check-to-time-of-use (TOCT-TOU) attacks. To do this, the adversary waits until themail program checks that /var/mail/root is a regularfile prior to opening it and then switches the file to a linkbefore the open call is made. Given the variety of possi-ble name resolution attacks and the complex code neededto defend against them, it should come as little surprisethat vulnerabilities of this type continue to be uncovered.Such attacks contribute 5-10% of CVE entries each year.

2.2 Detecting Name Resolution AttacksResearchers have explored a variety of dynamic andstatic analyses to detect instances of name resolution at-tacks, particularly TOCTTOU attacks. However, all suchanalyses are limited in some ways when applied to theproblem of detecting name resolution attacks.

Static Analysis Static analyses of TOCTTOU at-tacks vary from syntactic analyses specific to check-usepairs [6, 53], to building various models of programs tocheck for security errors [15,44,45], to race conditions ingeneral [27]. However, static analyses are disconnectedfrom essential environmental information, such as thesystem’s access control policy to determine whether anadversary can even launch an attack. For example, a pro-gram may legitimately accesses files in /proc withoutchecking for name resolution attacks; however, the samecannot be done in /tmp. Thus, these analyses yield asignificant number of false positives. Further, static tech-niques are limited to TOCTTOU attacks, due to the ab-sence of standardized program checks against name res-olution attacks in general.

Dynamic Analysis Dynamic analyses [1,32,35,36,56]typically take a system-wide view, logging observed sys-tem calls from processes to detect possible problems,such as check-use pairs. Dynamic analyses can also de-tect specific vulnerabilities, either at runtime [36] or afterthe fact [35]. Compared to static analyses, dynamic anal-yses can take into account the system’s environment, butsuffer the disadvantage of being unaware of the internalcode of the program. In addition, the quality of dynamicanalysis is strongly dependent on the test cases produced.Because name resolution attacks require an active adver-sary, the problem is to produce adversary actions in acomprehensive manner. Using benign system traces mayidentify some vulnerabilities, such as those built-in to thenormal system configuration [13], but will miss manyother feasible attacks. Finally, any dynamic analysismust distinguish program actions that are safe from thosethat are vulnerable effectively. We have found that pro-grams successfully defend themselves from a large per-

centage of the attempted name resolution attacks (only12.5% were vulnerable), so test case processing mustfind cases where program defenses are actually missingor fail. Since previous dynamic analyses lack insight intothe program, several false positives have resulted.

Symbolic Execution Researchers have recently hadsuccess finding the conditions under which a programis vulnerable using symbolic execution [7, 8, 10, 11, 18,19, 25, 29–31, 46]. Symbolic execution has been used toproduce test cases for programs to look for bugs [9, 37],to generate filters automatically [8, 18], and to generatetest cases to leverage vulnerabilities in programs [3] au-tomatically. In these symbolic execution analyses, theprogram is analyzed to find constraints on the input val-ues that lead to a program instruction of interest (i.e.,where an error occurs). Then, the symbolic executionengine solves for those constraints to produce a concretetest case that when executed would follow the same path.Finding name resolution attacks using symbolic execu-tion may be difficult because the conditions for attack aredetermined mainly by the operating environment ratherthan the program. While symbolic execution often re-quires a model of the environment in which to examinethe program, the environment needs to be the focus ofanalysis for finding name resolution attacks.

2.3 Our Solution

As a result, we use a dynamic analysis to find nameresolution vulnerabilities, but propose four key enhance-ments to overcome the limitations of prior analyses of alltypes.

First, each name resolution system call is evaluated atruntime to find the bindings used in resolution and to de-termine whether an adversary is capable of applying oneor more of the attack types listed in Table 1. If so, a testcase resource is automatically produced at an adversary-redirected location in the namespace and provided to thevictim. As a result, test cases are only applied whereadversaries have the access necessary to perform suchattacks.

Second, we track the victim’s use of the test case re-source to determine whether it accepts the resource aslegitimate. If the victim uses the resource (e.g., readsfrom it), we log the program entrypoint1 that obtainedthe resource as vulnerable. While it is not always pos-sible to exploit such a flaw to compromise the program,this approach greatly narrows the number of false posi-tives while still locating several previously-unknown true

1A program entrypoint is a program instruction that invoked thename resolution system call, typically indirectly via a library (e.g.,libc).

vulnerabilities. We also log the test cases run by programentrypoint to avoid repeating the same attack.

Third, another problem with dynamic analysis isensuring that the analysis runs comprehensively eventhough programs may fail or take countermeasures whenattacks are detected. We take steps to keep programsrunning regardless of whether they fall victim to the at-tack or not. Our test case resources use the same data asthe expected resource to enable vulnerable programs tocontinue, and we automatically revert namespaces aftercompletion of a test and restart programs that terminatewhen an attempted attack on them is detected.

3 Testing Model

In this section, we define an adversarial model that weuse to generate test cases that can be used to identify pro-gram vulnerabilities.

Our goal is to discover vulnerabilities that will com-promise the integrity of a process. Classically, an in-tegrity violation is said occur when a lower integrity pro-cess provides input to a higher integrity process or ob-ject [5, 16]. For the name resolution attacks described inthe last section (see Table 1), integrity violations are cre-ated in two ways: (1) improper binding attacks, whereadversaries may redirect name resolutions to resourcesthat are normally not modifiable by adversaries, enablingadversaries to modify higher integrity objects, and (2)improper resource attacks, where adversaries may redi-rect name resolutions to resources that are under the ad-versaries’ control, enabling adversaries to deliver lowerintegrity objects to processes. In this section, we definehow such attacks are run and detected to identify the re-quirements for the dynamic analysis.

A nameserver performs namespace resolution by us-ing a sequence of namespace bindings, bi j = (ri,n j,rk),to retrieve resource rk from resource ri given a name n j.In a file system, ri is a directory, n j is an element of thename supplied to the nameserver for resolution, and rkis another directory or a file. Attacks are possible whenadversaries of a victim program have access to modifybinding bi j to (ri,n j,rk′) or create such a binding if itdoes not exist, enabling them to redirect the victim’s pro-cess to a resource r′k instead of rk. Since bindings cannotbe modified like files, adversaries generally require thedelete permission to remove the old binding and the cre-ate permission to create the desired binding to performsuch modification. Two types of name resolution attacksare possible when adversaries have such permission (e.g.,write permission to directories in UNIX systems).

Improper binding attacks use the permission tomodify a binding to create a link (symbolic or hard) to anexisting resource that is inaccessible to the adversary, as

in symbolic and hard link attacks described above. Thatis, the improper binding may lead to privilege escalationfor the adversary by redirecting the victim process to usean existing resource on behalf of that adversary.

Improper resource attacks use the permission tomodify a binding to create a new resource controlled bythe adversary. That is, the adversary tries to trick thevictim into using the improper resource to enable the ad-versary to provide malicious input to the victim, such asin resource squatting and untrusted search path attacksdescribed above.

STING discovers name resolution vulnerabilities byidentifying scenarios where an attack is possible and gen-erating test cases to validate the vulnerability. Whenevera name resolution system call is requested by the vic-tim (i.e., a system call that converts a name to a resourcereference, such as open), STING finds the bindings thatwould be used in the namespace resolution process to de-termine whether an adversary of the process has access tomodify one or more of these bindings. If so, STING gen-erates an attack test case by producing a test case re-source, which emulates either an existing, privileged re-source or a new adversary-controlled resource, and ad-justing the bindings as necessary to resolve to that re-source. A reference to this test case resource is returnedto the victim.

Vulnerability in the Victim. We define a victim to bevulnerable if the victim runs an accept system call usinga reference to the test case resource.

A victim accepts a test case resource if it runs an ac-cept system call, a system call that uses the returned ref-erence to the test case resource to access resource data(e.g., read or write). If a victim is tricked into readingor writing a resource inaccessible to the adversary, theadversary can modify the resource illicitly2. If a victimis tricked into reading or writing a resource that is con-trolled by the adversary, then the adversary can controlthe victim’s processing.

4 Design

The design of STING is shown in Figure 2. STING is di-vided into two phases. The attack phase of STING isinvoked at the start of a name resolution system call.STING resolves the name itself to obtain the bindings thatwould be used in normal resolution, and then determineswhether an attack is possible using the program’s adver-sary model. When an attack is possible, STING choosesan attack from the list in Table 1 that has not alreadybeen tried and produces a test case resource and asso-

2A read operation on a test case resource is indicative of integrityproblems if the resource is opened with read-write access.

SyscallInvocation

ShadowResolution

(name, entry point) Attack

ConditionsSatisfied?

AdversaryModel

Resouce

PossibleAdversaries

Attack Search HistoryProgram:Entry Point Attack History

mail:0xbeef Squat: NoHardlink: YesSymlink: ???

xord:0x4cb3 Squat: ???

Untested Attack

HandleSyscallNo

Rollback InformationProgram:Entry Point Changes

mail:0xbeef /var/mail/root ->/etc/high_int_file

AttackNamespace

Yes

Record changes to namespaceIndicate attack

in progress

Resume

(a) Launching an attack

SyscallInvocation

Program vulnerable to

modified resource?

TaintedResouce

HandleSyscallNo

RecordVulnerability

Recoverfrom changes

Yes

Attack Search HistoryProgram:Entry Point Attack History

mail:0xbeef Squat: NoHardlink: YesSymlink: ???

xord:0x4cb3 Squat: ???

Rollback Information

Changes

mail:0xbeef /var/mail/root ->/etc/high_int_file

Program:Entry Point

(b) Detecting a vulnerability

Figure 2: STING consists of two phases: (a) launching an attack, and (b) detecting a vulnerability due to the attack and recoveringoriginal namespace state.

ciated bindings to launch the attack. The detect phaseof STING is invoked on accept system calls. This phasedetects if a process “accepted” STING’s changes, indi-cating a vulnerability, and records the vulnerability in-formation in the previously added entry in the attack his-tory. STING reverts the namespace to avoid side-effects.These two phases are detailed below.

STING is designed to test systems, not just individualprograms, so STING will generate test cases for any pro-gram in the system that has an adversary model shouldthe opportunity arise. To control the environment underwhich a program is run, STING intercepts execve sys-tem calls. For example, programs that may be run byunprivileged users (e.g., setuid programs) are started inan adversary’s home directory by this interception code.Other than initialization, the attack and detect phases arethe same for all processes.

4.1 Attack PhaseShadow resolution. Whenever a name resolution sys-tem call is performed, STING needs identify whether anattack is possible against that system call. The first stepis to collect the bindings that would normally be usedin the resolution. We cannot use the existing name res-olution mechanism, however, since that has side-effectsthat may impact the process and also does not gather thedesired bindings for evaluation. Instead, we perform ashadow resolution that only collects the bindings.

There are two challenges with shadow resolution.First, we have to ensure that all name resolution opera-tions performed by the system are captured in the shadowresolution. This task can be tricky because some nameresolution is performed indirectly. For example, execresolves the interpreter that executes the program in the“shebang” line in addition to the program whose name isan argument to the system call. To capture all the nameresolution code, we use Cscope 3 to find all the system

3http://cscope.sourceforge.net/

calls that invoke a fundamental function of name reso-lution, do_path_lookup. Using this we find 62 systemcalls that do name resolution for the Linux filesystem.The three System V IPC system calls that do name reso-lution were identified manually.

Second, we need to modify the name resolution codeto collect the bindings used without causing side-effectsin the system. Fortunately, the name resolution code inLinux does not cause side-effects itself. The system callcode that uses name resolution creates the side-effects.Thus, we simply invoke the name resolution functionsdirectly when the system call is received. Some effortmust be taken to format the call to the name resolutioncode at the start of the system call, but fortunately thenecessary information is available (name, flags, etc.).

Find vulnerable bindings. To carry out an attack,STING has to determine whether any adversary of theprogram has the necessary permissions to the bindingsinvolved in the resolution. To answer this question, weneed to identify the program’s adversaries and evaluatethe permissions these adversaries have to bindings effi-ciently. We note that the specific permissions necessaryto launch an attack are specified in Section 3.

We do not want the dynamic analysis to depend on asingle adversary model for the system, but instead per-mit the use of program-specific adversary models. Theadversaries of a process are determined by the process’ssubject (i.e., in the access control policy) and optionalprogram-specific sets of subjects and/or objects that areadversaries or adversary-controlled, respectively. Fromthis information, a comprehensive set of adversary sub-jects are computed. Using a discretionary access control(DAC) policy, an adversary is any subject other than thevictim and the trusted superuser root. Chari et al. usedthe DAC policy in their dynamic analysis [13], whichworked adequately for root processes but incurred somefalse positives for processes run under other subjects. Forsystems that enforce a mandatory access control (MAC)policy, methods have been devised to compute the adver-

saries of individual subjects [34, 49]. We note that MACadversaries may potentially be running processes underthe same DAC user, so they are typically finer-grained.

Finding the permissions of a process’s adversaries atruntime must be done efficiently. If a process has severaladversaries, the naive technique of querying the accesscontrol policy for each adversary in turn is unacceptable.To solve this, we observe we can precompute the adver-saries of particular process as in a capability-list, whereeach process has a list of tuples consisting of an object(or label in a MAC policy), a list of adversaries with cre-ate permission to that object (or label), and the list ofadversaries with delete permission to that object (or la-bel). We store these in a hash table for quick lookup atruntime.

Identify possible attacks. Once we identify a bindingthat is accessible to an adversary, we need to choose anattack from which to produce a test case. For improperbinding attacks, an attack needs to modify a binding froman existing resource to the target resource using a sym-bolic or hard link. Such attacks are only possible in theLinux filesystem namespace, where a single file (inode)may have multiple names.

Improper resource attacks are applicable across allnamespaces. We consider two instances of improper re-source attacks (see Table 1). For resource squatting, at-tacks are only meaningful if the adversary can supply aresource with a lower integrity than the victim intendedto access. To determine the victim’s intent, we simplycheck if a non-adversarial subject has permissions to sup-ply the resource the adversary is attacking 4. This occursin directories shared by parties at more than one integritylevel. If so, we assume that the victim intended to accessthe higher integrity file (i.e., one that could be created bya non-adversarial subject), and attempt a squatting attackwhich succeeds if the victim later accepts the test case re-source. MOPS [44] uses a similar but narrower heuristicto identify intent and detect ownership stealing attacks,which are another case of resource squatting attacks.

Launch an attack. Launching an attack involvesmaking modifications to the namespace to generate re-alistic attack scenarios. Different attacks modify thenamespace in different ways. For improper binding at-tacks, we create a new test case resource (e.g., file)that represents a privileged resource, and change theadversary-modifiable bindings to point to it (e.g., sym-bolic link). For improper resource attacks, we replacethe existing resource (if present) with a new test case re-source and binding.

Modification of the filesystem namespace in particularpresents challenges of backing up existing files, rollback

4We discount root superuser permissions while checking non-adversarial subjects, as otherwise root will be a non-adversary in anydirectory.

and multiple views for different subjects. First, we haveto change the file system to create the test cases, suchas deleting existing files. Second, once the test case fin-ishes, we need to rollback the namespace to its originalstate. While we can back up files (costing the overheadof copy), other resources such as UNIX domain socketsare hard or impossible to rollback once destroyed. An-other requirement is that the attack should only be visibleto the appropriate victim subjects having the attacker asan adversary. Thus, direct modification of the existingfilesystem is undesirable.

To solve the above problems, we take inspiration fromthe related problem of filesystem unions. Union filesys-tems unite two or more filesystems (called branches) to-gether [2,59]. A common use-case is in Live CD images,where the base filesystem mounted from a CDROM isread-only, and a read-write branch (possibly temporary)is mounted on top to allow changes. When a file on thelower branch is modified, it is “copied up” to the up-per branch and thereafter hides the corresponding lowerbranch file. “Whiteouts” are created on the upper branchfor deleted files.

To support STING, our general strategy is thus to havea throw-away “upper branch” mounted on top of the un-derlying filesystem “lower branch”. STING creates re-sources only on the upper branch. As STING does notdeal with data, files are created empty. Next, STING di-rects operations to upper branches if the resource existson the upper branch and was created by an adversary tothe currently running process. This enables different pro-cesses to have different views of the filesystem names-pace.

Once a test case resource is created, we taint it us-ing extended attributes to identify when it is used in anaccept system call5, signaling a vulnerability. We alsorecord rollback information about the resources createdin a rollback table.

These changes to the bindings have to be done as theadversary. The most straightforward option is to have aseparate “adversary process” that is scheduled in to per-form needed changes. This was the first option we ex-plored; however, it introduced significant performancedegradation due to scheduling. Instead, we perform thechange using the currently running victim process itself.We change the credentials of the victim process to that ofthe adversary, carry out the change, and then revert to thevictim’s original credentials. We do this without leavingbehind side effects on the victim process’ state. For ex-ample, if we create a namespace binding using open, weclose the opened file descriptor.

5Some filesystems do not support extended attributes. Since we usetmpfs as the upper branch, we extended it to add such support for ourtesting. For other namespaces such as IPCs, we store the taint status ina field in the security data structure defined by SELinux.

There are some cases where the system needs to reverta test case resource back to a “benign” version. “Check”system calls [56] (e.g., stat, lstat) resolve the nameto verify properties of the resource, so attacks shouldpresent a benign resource to prevent the victim from de-tecting the attack. We simply redirect such accesses tothe lower branch.

In addition to adversarial modification of the names-pace, STING also changes process attributes relevant toname resolution. In particular, it changes the work-ing directory a process is launched in to an adversary-controlled directory.

We want to prevent STING from launching the sameattack multiple times. Trying the same attack on the samesystem call prevents forward exploration of the attackspace and further program code from being exercised. Aunique attack associates an attack type with a particularsystem call entrypoint in the program. Thus, when welaunch an attack, we check an attack history that storeswhich attack types have been attempted already and theirresult (see Figure 2). We do not attempt multiple bindingchanges for an attack type. We have not found any pro-grams that perform different checks for name resolutionattacks based on the names used. Tracking such historyrequires unique identification of system call entrypointsin the program, which we discuss in Recording below.

4.2 Detect Phase

Detect vulnerability. Detecting whether a victim is vul-nerable to an attack is relatively straightforward – wesimply have to determine if the program “accepted” thetest case resource. Definition of acceptance for differentattacks are presented in Table 2. On the other hand, weconclude that the program defends itself properly froman attack if it: (1) exits without accepting the test caseresource or (2) retries the operation at the same programentrypoint. When detection determines that a victim isvulnerable or invulnerable, it fills this information in theattack history entry created during the attack phase, andoptionally logs the fact.

STING detects successful attacks by identifying use ofa test case resource. Each test case resource is markedwhen returned to the victim. To detect when a victimuses a test case resource, we must have access to the in-ode, so such checking is integrated with the access con-trol mechanism (e.g., Linux Security Module). Once atest case resource is found, we need to determine if itis being accepted by retrieving the system call invoked.As an access control check may apply to multiple sys-tem calls, we have to retrieve the identity of the systemcall from the state of the calling process. Vulnerabilitiesfound have their attack history record logged into userspace.

Attack AcceptSymbolic link write-like, read, readlinkHard link write-like, readFile squat write-like, readUNIX-domain socket squat connect

System V IPC squat msgsnd, semop, shmat

Table 2: Table showing calls that signify acceptance, and there-fore detection, for various attacks. write-like system calls areany calls that modifies the resource’s data or metadata (e.g.,fchmod).

We note that the process of detecting a vulnerabilityis the same for all attack types, including those based onrace conditions. STING automatically switches resourcesbetween check and use as discussed above, so we onlyneed to detect when an untrusted resource is accepted.fstat is not an accept system call, so the “use” of thetest case resource in that system call does not indicate avulnerability. Thus, if the program should somehow de-tect an attack using fstat, preventing further use of thetest case resource, then STING will not record a vulnera-bility.

Update attack history. Once a particular attack hasbeen tried on a system call, trying it again in future invo-cations of the program is redundant and may prevent fur-ther code from being exercised. Avoiding this problemrequires storing attacks tested for system calls in the at-tack history. The challenge is unique identification of thesystem call entrypoint, which uniquely identifies the in-struction from which the program made the system call.To find this instruction, we perform a backtrace of theuser stack to find the first frame within the program thatis not in the libraries. We also extend our system to sup-port interpreters by porting interpreter debugging codeinto the kernel that locates and parses interpreter datastructures to the current line number in the script, for theBash, PHP and Python interpreters. Only between 11 and59 lines of code were necessary for each interpreter. Weuse the current line number in the script as the entrypointfor interpreted programs.

Namespace recovery. Finally, we make changes sothat STING can work online despite changing the names-pace state. While it appears that such changes couldcause processes to crash, we have not found this to bethe case. Unlike data fuzzing, we find changes in names-pace state do not cause programs to arbitrarily crash,as we preserve data and only change resource meta-data. When an attack succeeds, the only change neededis to redirect the access to the corresponding resourcein the lower branch of the unioned filesystem that con-tains the actual data (if one exists), and delete the re-source in the upper branch. On the other hand, if theattack fails, STING again deletes the resource in the up-

per branch. Programs that protect themselves proceed intwo ways. First, the program might retry the same sys-tem call again. Interestingly, we find this happens in afew programs (Section 6.2). In this case, STING will notlaunch an attack at that entrypoint again, and the pro-gram again continues. Second, the program might exit.If so, STING records that the attack failed at that entry-point and restarts the program with its original arguments(recorded via execve interception). For many programsthat exit, restarting them from the beginning does not af-fect system correctness. Thus, we find our tool can per-form online without complex logic. We are currently ex-ploring how to integrate process checkpointing and roll-back [17] to carry out recovery more gracefully for theexit cases.

5 Implementation

VictimProcess

ShadowName

Resolve

TestAttack

Conditions

GetProcess

EntrypointLaunch Attack

DetectVulnerable

AccessRecord

Modify Environment

Core

Sting

AdversaryModel

Log andHistory

Recover

SyscallBegin

LSMHooks

SYS

CALL

SYS

RET

User SpaceKernel Space

Figure 3: STING is implemented in the Linux kernel and hookson to the system call beginning and LSM hooks. It has a modu-lar implementation. We show here in particular the interactionbetween user and kernel space.

Figure 3 shows the overall implementation of STING .STING is implemented in the Linux 3.2.0 kernel. It hooksinto LSM through the SELinux function avc_has_perm

for its detect phase, and into the beginning of systemcalls for its attack phase. STING has an extensible archi-tecture, with modules registering themselves, and rulesspecifying the order and conditions under which mod-ules are called.

The modules implement functionality correspondingto the steps shown in the design (Figure 2). The en-trypoint module uses the process’ eh frame ELF sec-tion to perform the user stack unwinding. eh frame

replaces the DWARF debug frame section, and is en-abled by default on Ubuntu 11.10 and Fedora 15 systems.Stack traces in interpreters yield an entrypoint inside theinterpreter, and not the currently executing script. Weextended our entrypoint module to identify line num-bers inside scripts for the Bash, PHP and Python inter-preters [54].

Server Programs InstalledBIND DNS Server Apache Web ServerMySQL Database PHPPostfix Mail Server Postgresql DatabaseSamba File Server Tomcat Java Server

Table 3: Server programs installed on Ubuntu and Fedora.

The data for the MAC adversary model is pushed intothe kernel through a special file, and code to use each ofthese to decide adversary access is in the test attack con-ditions module. After launching an attack, the modifiedresources are tainted through extended attributes for laterdetection when a victim program uses the resource. Wehad to extend the tmpfs filesystem to handle extendedattributes. The recording module can print vulnerabili-ties as they are detected, and also log the vulnerabilitiesand search history into userspace files through relayfs.A startup script loads the attack search history into thekernel during bootup, so the same attacks are not triedagain.

We prototyped a modified version of the UnionFSfilesystem [59] for STING. We mount a tmpfs as the up-per branch, and the root filesystem as the lower branch.The main change involved redirecting to the upper orlower branches depending on a subject’s adversaries, anddisabling irrelevant UnionFS features such as copy-up.

6 Evaluation

We first evaluate STING ’s ability to finding bugs, as wellas broader security issues in Section 6.1. We then ana-lyze the suitability of STING as an online testing tool inSection 6.2

6.1 Security EvaluationThe aim of the security evaluation is to show that:

• STING can detect real vulnerabilities with a highpercentage of them being exploitable in both newerprograms, and older, more mature programs, and

• Normal runtime and static analysis would result in alarge number of false positives, and normal runtimewould also miss some attacks.

We tested STING on the latest available versions oftwo popular distributions - Ubuntu 11.10 and Fedora16. In both cases, we installed the default base Desktopdistribution, and augmented them with various commonserver programs (Table 3). Note that STING requires noadditional special setup; it simply reacts to normal nameresolution requests at runtime. We collected data on bothsystems over a few days of normal usage.

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

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, ...)

Figure 4: Code from the GNU mail program in mailutils

illustrating a squat vulnerability that STING found.

6.1.2 Examples

In this section, we present particular examples highlight-ing STING’s usefulness, and also broader lessons.

Mail Programs. GNU mail is the default mail clienton Ubuntu 11.10, in which STING found a vulnerability.This example shows the difficulty of proper checking inprograms, and why detection tools with low false pos-itives are necessary – programmers can easily get suchchecks wrong, and there are no standardized ways towrite code to defend against various name resolution at-tacks.

The code shows the program preparing to read the file/var/mail/root. In summary, this program creates anempty file when the file doesn’t already exist (lines 4-10), using flags (O_EXCL) to ensure that a fresh file iscreated. The program performs several checks to verifythe safety of the file opened, guarding against race con-ditions and link traversal (both symbolic and hard links)(11-29). Unfortunately, the program fails to protect it-self against a squatting attack if the file already exists, asit does not check st_uid or st_gid; any user in groupmail can control the contents of root’s inbox. Interest-ingly, it protects itself against squatting attacks on line6.

X11 script STING found a race condition exploitableby a symbolic link attack on the script that creates/tmp/.X11-unix in Ubuntu 11.10. The code snippetis shown in Figure 5. The aim of the script is to cre-

01 SOCKET_DIR=/tmp/.X11-unix

...

02 set_up_socket_dir () {03 if [ "$VERBOSE" != no ]; then

04 log_begin_msg "Setting up X server socket directory"

05 fi

06 if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then

07 mv $SOCKET_DIR $SOCKET_DIR.$$

08 fi

09 mkdir -p $SOCKET_DIR

10 chown root:root $SOCKET_DIR

11 chmod 1777 $SOCKET_DIR

12 do_restorecon $SOCKET_DIR

13 [ "$VERBOSE" != no ] && log_end_msg 0 || return 0

14 }

Figure 5: Code from an X11 startup script in Ubuntu 11.10 thatillustrates a race condition that STING found.

ate a root-owned directory /tmp/.X11-unix. Lines 6-8check if such a file already exists that is not a directory,and if so, moves it away so a directory can be created.In Line 9, the programmer creates the directory, and as-sumes it will succeed, because the previous code had justmoved any file that might exist. However, because /tmpis a shared directory, an adversary scheduled in betweenthe moving of the file and the mkdir might again createa file in /tmp/.X11-unix, thus breaking the program-mer’s expectation. If the file is a link pointing to, for ex-ample, /etc/shadow, the chmod on Line 11 will makeit world-readable. STING was able to detect this racecondition by changing the resource into a symbolic linkafter the move and before the creation on line 9, as it actsjust before the system call on line 9. This script has ex-isted for many years, showing how it is easy to overlooksuch conditions. This also shows how STING can syn-chronously produce any race condition an adversary can,because it is in the system. This script was independentlyfixed by Ubuntu in its latest release. The discussion pagefor the bug [21] shows how such checks are challengingto get right even for experienced programmers. Conse-quently, manually scanning source code can also easilymiss such vulnerabilities.

mountall This program has an untrusted search paththat is not executed in normal runtime but was dis-covered by STING. This Ubuntu-specific utility simplymounts all filesystems in /etc/fstab. When launchedin an untrusted directory, it issues mount commands thatsearch for files such as none and fusectl in the cur-rent working directory. If these are symbolic links, thenthe contents of these files are read through readlink,and put in /etc/mtab. Thus, the attacker can influence/etc/mtab entries and potentially confuse utilities thatdepend on this file, such as unmounters. This is an exam-ple of how very specific conditions are required to detectthe attack – the program needs to be launched in an ad-versarial directory, and the name searched for needs tobe a symbolic link. Normal runtime would not give anyhint of such attacks.

postgresql init script. This vulnerability high-lights the challenge facing developers and OS distrib-utors. This script runs as root, and is vulnerable tosymbolic and hard link attacks on accessing files in/etc/postgresql. That directory is owned by the userpostgres, which could be compromised by remote at-tacks on PostgreSQL, who can then use this vulnerabil-ity to gain root privileges. The problem is that the de-velopers who wrote the script did not expect the direc-tory /etc/postgresql to be owned by a non-root user.However, the access control policy did not reflect this as-sumption. STING is useful in finding such discrepanciesin access control policies as it can run with attacker mod-els based on different policies.

6.1.3 False Positives

Two issues in STING cause false positives.Random Name. The programs

yum, abrt-server, zeitgeist-daemon in Ta-ble 6 were vulnerable to name resolution attacks, butdefended themselves by creating files with randomnames. Library calls such as mktemp are used to createsuch names. STING cannot currently differentiate be-tween “random” and “non-random” names. Exploitingsuch vulnerabilities requires the adversary to guessthe filename, which may be challenging given properrandomness. In any case, such bugs can be fixed byadding the O_EXCL flag to open when creating files.

Program Internals. STING does not know the in-ternal workings of a program. Thus, it cannot know ifuse of a resource from a vulnerable name resolution canaffect the program or not, and simply marks it for fur-ther perusal. A vulnerable name resolution involvinga write-like accept operation can always be exploited.However, whether those involving read can be exploiteddepends on the internals of the program. Eight of the26 vulnerable name resolutions in Table 6 are due toread. While this has led to some false positives (twoadditional vulnerable name resolutions involving read

not in Table 6 were deemed to not affect program func-tioning), STING narrows the programmers’ effort signifi-cantly. Nonetheless, more knowledge regarding programinternals would improve the accuracy even further.

6.2 Performance Evaluation

We measured the performance of STING to assess itssuitability as an online testing tool. While the perfor-mance of STING is of not of primary importance be-cause it is meant to be run on test environments in non-production systems before deployment, it must neverthe-less be responsive to online testing. We measured per-formance using micro- and macro-benchmarks. While

Case Time (µs) OverheadAttack Phase: open system call

Base 14.57 –+ Find Vulnerable Bindings 31.44 2.15×+ Obtain entrypoint and 211.20 12.33×check attack history+ Launch attack 365.87 25.1×

Detect Phase: read system callBase 8.73 –+ Detect vulnerability 9.18 1.05×+ Namespace recovery 63.08 7.22×

Table 7: Micro-overheads for system calls showing medianover 10000 system call runs.

Benchmark Base STING OverheadApache 2.2.20 151.65s 163.79s 8%compileApachebench:Throughput 231.77Kbps 221.89Kbps 4.33%Latency 1.943ms 2.088ms 7.46%

Table 8: Macro-benchmarks showing compilation and Apache-bench throughput and latency overhead. The standard deviationwas less than 3% of the mean.

STING does cause noticeable overhead, it did not impedeour testing. All tests were done on a Dell Optiplex 980machine with 8GB of RAM.

Micro-performance (Table 7) was measured by thetime taken for individual system calls under varying con-ditions. For an attack launch, system call overhead iscaused by the time to (1) detect adversary accessibility,(2) get and compare process entrypoint against attackhistory, and (3) launch the attack. The main overheadis due to obtaining the entrypoint to check the attack his-tory and carrying out the attack. However, obtaining theentrypoint is required only if the name resolution is ad-versary accessible (around 4-5.7% in Table 4), and anattack is launched only once for a particular entrypoint,thereby alleviating their impact on overall performance.For the detection phase, we have (1) detect vulnerableaccess, and (2) rollback namespace. Namespace recov-ery through rollback is expensive, but occurs only onceper attack launched.

Macro-benchmarks (Table 8) showed upto 8% over-head. Apache compilation involved a lot of name res-olutions and temporary file creation. During our systemtests, the system remained responsive enough to carry outnormal tasks, such as browsing the Internet using Firefoxand checking e-mail. We are investigating further oppor-tunities to improve performance.

Program retries and restarts. We came across thir-teen programs that retried a name resolution system callon failure due to a STING attack test case. The most

common case was temporary file creation – programsretry until they successfully create a temporary file witha random name. Programs that retry integrate well withSTING , which maintains its attack history and does notretry the same attacks on the same entrypoints. On theother hand, a few programs exited on encountering an at-tack by STING . We currently simply restart such pro-grams (Section 4.2). For example, dbus-daemon ex-ited during boot due to a STING test case and had tobe restarted by STING to continue normal boot. How-ever, programs may lose state across restarts. We are in-vestigating integrating process checkpoint and rollbackmechanisms [17].

7 Related Work

Related work that deals with detecting name resolutionattacks was presented in Section 2.2. Here, we discussdynamic techniques to detect other types of programbugs, and revisit some dynamic techniques that detectname resolution attacks.

Black-box testing. Fuzz testing, an instance of black-box testing, runs a program under various input data testcases to see if the program crashes or exhibits unde-sired behavior. Particular program entrypoints (usuallynetwork or file input) are fed totally random input withthe hope of locating input filtering vulnerabilities such asbuffer overflows [24, 41, 47]. Black-box fuzzing gener-ally does not scale because it is not directed. To alleviatethis, techniques use some knowledge of the semanticsof data expected at program entrypoints. SNOOZE [4]is a tool to generate fuzzing scenarios for network pro-tocols using which bugs in programs were discovered.TaintScope [55] is a directed fuzzing tool that generatesfuzzed input to pass checksum code in programs. Webapplication vulnerability scanners [23] supply very spe-cific strings to detect XSS and SQL injection attacks.

We find a parallel can be drawn between our approachand directed black-box testing, where semantics of in-put data is known. While such techniques change thedata presented to a program to exercise program pathswith possible vulnerabilities, we change the resource, orthe metadata presented to the application for the samepurpose. Thus, STING can be viewed as an instanceof black-box testing that changes the namespace state toevaluate program responses.

Taint Tracking. Taint techniques track flow of tainteddata inside programs. They can be used to find bugsgiven specifications [60], or can detect secrecy leaks inprograms [26]. Flax [43] uses a taint-enhanced fuzzingapproach to detect input filtering vulnerabilities in webapplications. However, taint tracking by itself does notactively change any data presented to applications, andthus has different applications.

Dynamic Name Resolution Attacks Detection. Asmentioned in Section 2.2, most dynamic analysis are spe-cific to detecting TOCTTOU attacks. Chari et al. [13]present an approach to defend against improper bindingattacks; however, they cannot detect them until they ac-tively occur in the system. We use active adversaries togenerate test cases and to exercise potentially vulnerablepaths in programs to detect vulnerabilities that would notoccur in normal runtime traces. Further, none of the ap-proaches deal with improper resource attacks, of whichwe detect several.

8 Discussion

Other System State Attacks. More program vulnerabil-ities may be detected by modifying system state. For ex-ample, non-reentrant signal handlers can be detected bydelivering signals to a process already handling a signal.Similarly, return values of system calls can be changedto cause conditions suitable for attack (e.g., call to dropprivileges fails). While STING could be easily extendedto perform these attacks, we believe that these cases aremore easily handled through static analysis, as standardtechniques are available (e.g., lists of non-reentrant sys-tem calls, unchecked return value) through tools such asFortify [28]. For the reasons we have seen, no such stan-dard techniques are available for name resolution attacks.

Solutions. One of the more effective ways we haveseen programs defending against improper binding at-tacks is by dropping privileges. For example, the priv-ileged part of sshd drops privileges to the user wheneveraccessing user files such as .ssh/authorized_keys.Thus, even if code is vulnerable to improper binding at-tacks, the user cannot escalate privileges.

User directory. Administrators running as root

should take extreme care when in user-owned directo-ries, as there are several opportunities for privilege esca-lation. For example, we found during our testing that ifthe Python interpreter is started in a user-owned direc-tory, Python searches for modules in that directory. If auser has malicious libraries, then they will be loaded in-stead. More race conditions are also exploitable as a usercan delete even root-owned files in her directory.

Integration with Black-box Testing. We believe thatSTING can also integrate with other data fuzzing plat-forms [41]. Such tools need special environments (e.g.,attaching to running processes with debuggers) to carryout their tests on running programs. Instead, we can takeinput from these platforms and use STING to feed suchinput into running processes. Since STING also takes intoaccount the access control policy, opportunities to supplyadversarial data can readily be located.

Deployment. We envision that STING would be de-ployed during Alpha and Beta testing of distribution re-

leases. We plan to package STING for distributions, sousers can easily install it through the distribution’s pack-age managers. STING will test various programs as usersare running them, and program vulnerabilities found canbe fixed before the final release. Being a runtime anal-ysis tool, STING can possibly find more vulnerabilitiesas it improves its runtime coverage. Even if a small per-centage of users install the tool, we expect a significantincrease in the runtime coverage, because different usersconfigure and run programs in different ways.

9 Conclusion

In this paper, we introduced STING, a tool that detectsname resolution vulnerabilities in programs by dynami-cally modifying system state. We examine the deficien-cies of current static and normal runtime analysis fordetecting name resolution vulnerabilities. We classifyname resolution attacks into improper binding and im-proper resource attacks. STING checks for opportunitiesto carry out these attacks on victim programs based onan adversary model, and if an adversary exists, launchesattacks as an adversary would by modifying namespacestate visible to the victim. STING later detects if the vic-tim protected itself from the attack, or it was vulnerable.To allow online operation, we propose mechanisms forrolling back the namespace state. We tested STING onFedora 15 and Ubuntu 11.10 distributions, finding 21previously unknown vulnerabilities across various pro-grams. We believe STING shall be useful in detectingname resolution vulnerabilities in programs before at-tackers. We plan to release and package STING for dis-tributions for this purpose.

References[1] A. Aggarwal and P. Jalote. Monitoring the security health of soft-

ware systems. In ISSRE-06, pages 146–158, 2006.[2] Aufs. http://aufs.sourceforge.net/.[3] T. Avgerinos, S. K. Cha, B. L. T. Hao, and D. Brumley. Aeg:

Automatic exploit generation. In Network and Distributed SystemSecurity Symposium, Feb. 2011.

[4] G. Banks et al. . Snooze: Toward a stateful network protocolfuzzer. In of Lecture Notes in Computer Science, 2006.

[5] K. J. Biba. Integrity considerations for secure computer systems.Technical Report MTR-3153, MITRE, April 1977.

[6] M. Bishop and M. Digler. Checking for race conditions in fileaccesses. Computer Systems, 9(2), Spring 1996.

[7] P. Boonstoppel, C. Cadar, and D. Engler. Rwset: attacking pathexplosion in constraint-based test generation. In Proceedings ofthe Theory and practice of software, 14th international confer-ence on Tools and algorithms for the construction and analysisof systems, 2008.

[8] D. Brumley, J. Newsome, D. Song, H. Wang, and S. Jha. To-wards automatic generation of vulnerability-based signatures. InProceedings of the 2006 IEEE Symposium on Security and Pri-vacy, 2006.

[9] C. Cadar, D. Dunbar, and D. R. Engler. KLEE: Unassisted andautomatic generation of high-coverage tests for complex systems

programs. In Proceedings of the 8th USENIX Symposium onOperating Systems Design and Implementation, pages 209–224,2008.

[10] C. Cadar and D. R. Engler. Execution generated test cases: Howto make systems code crash itself. In SPIN, 2005.

[11] C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, and D. R.Engler. EXE: Automatically generating inputs of death. ACMTrans. Inf. Syst. Secur., 12(2), 2008.

[12] X. Cai et al. . Exploiting Unix File-System Races via AlgorithmicComplexity Attacks. In IEEE SSP ’09, 2009.

[13] S. Chari and P. Cheng. Bluebox: A policy-driven, host-basedintrusion detection system. ACM Transaction on Infomation andSystem Security, 6:173–200, May 2003.

[14] S. Chari et al. Where do you want to go today? escalating privi-leges by pathname manipulation. In NDSS ’10, 2010.

[15] B. Chess. Improving computer security using extended staticchecking. In Proceedings of the 2002 IEEE Symposium on Se-curity and Privacy, 2002.

[16] D. D. Clark and D. R. Wilson. A comparison of commercial andmilitary computer security policies. Security and Privacy, IEEESymposium on, 0:184, 1987.

[17] Container-based checkpoint/restart prototype. http://lwn.

net/Articles/430279/.[18] M. Costa, M. Castro, L. Zhou, L. Zhang, and M. Peinado.

Bouncer: securing software by blocking bad input. In SOSP,pages 117–130, 2007.

[19] M. Costa, J. Crowcroft, M. Castro, A. Rowstron, L. Zhou,L. Zhang, and P. Barham. Vigilante: end-to-end containment ofinternet worms. In Proceedings of the twentieth ACM symposiumon Operating systems principles, 2005.

[20] C. Cowan, S. Beattie, C. Wright, and G. Kroah-Hartman. Race-guard: Kernel protection from temporary file race vulnerabilities.In Proceedings of the 10th USENIX Security Symposium, Berke-ley, CA, USA, 2001. USENIX Association.

[21] init script x11-common creates directories in insecure man-ners. http://bugs.debian.org/cgi-bin/bugreport.

cgi?bug=661627.[22] D. Dean and A. Hu. Fixing races for fun and profit. In Proceed-

ings of the 13th USENIX Security Symposium, 2004.[23] Doup, Adam and Cova, Marco and Vigna, Giovanni. Why Johnny

Can’t Pentest: An Analysis of Black-Box Web VulnerabilityScanners. In DIMVA, 2010.

[24] W. Drewry and T. Ormandy. Flayer: exposing application inter-nals. In Proceedings of the first USENIX workshop on OffensiveTechnologies, 2007.

[25] M. Emmi, R. Majumdar, and K. Sen. Dynamic test input gener-ation for database applications. In Proceedings of the 2007 in-ternational symposium on Software testing and analysis, ISSTA’07, 2007.

[26] W. Enck et al. Taintdroid: an information-flow tracking systemfor realtime privacy monitoring on smartphones. In Proceedingsof the 9th USENIX conference on Operating systems design andimplementation, 2010.

[27] D. Engler and K. Ashcraft. Racerx: effective, static detection ofrace conditions and deadlocks. In Proceedings of the nineteenthACM symposium on Operating systems principles, 2003.

[28] Hp fortify static code analyzer (sca). https://www.fortify.

com/products/hpfssc/source-code-analyzer.html.[29] P. Godefroid. Compositional dynamic test generation. SIGPLAN

Not., 2007.[30] P. Godefroid, N. Klarlund, and K. Sen. Dart: directed automated

random testing. In Proceedings of the 2005 ACM SIGPLAN con-ference on Programming language design and implementation,2005.

[31] P. Godefroid, M. Y. Levin, and D. A. Molnar. Automated white-box fuzz testing. In Network Distributed Security Symposium(NDSS). Internet Society, 2008.

[32] B. Goyal, S. Sitaraman, and S. Venkatesan. A unified approachto detect binding based race condition attacks. In InternationalWorkshop on Cryptology And Network Security, 2003.

[33] N. Hardy. The confused deputy. Operating Systems Review,22:36–38, 1988.

[34] T. Jaeger, R. Sailer, and X. Zhang. Analyzing Integrity Protec-tion in the SELinux Example Policy. In Proceedings of the 12thUSENIX Security Symp., 2003.

[35] A. Joshi, S. T. King, G. W. Dunlap, and P. M. Chen. Detectingpast and present intrusions through vulnerability-specific predi-cates. In Proceedings of the twentieth ACM symposium on Op-erating systems principles, SOSP ’05, pages 91–104, New York,NY, USA, 2005. ACM.

[36] C. Ko and T. Redmond. Noninterference and intrusion detection.In Proceedings of the 2002 IEEE Symposium on Security and Pri-vacy, pages 177–, Washington, DC, USA, 2002. IEEE ComputerSociety.

[37] C. Kruegel, E. Kirda, D. Mutz, W. Robertson, and G. Vigna. Au-tomating mimicry attacks using static binary analysis. In Pro-ceedings of the 14th conference on USENIX Security Symposium- Volume 14, pages 11–11, Berkeley, CA, USA, 2005. USENIXAssociation.

[38] W. S. McPhee. Operating system integrity in OS/VS2. IBM Syst.J., 13:230–252, September 1974.

[39] OpenWall Project - Information security software for open envi-ronments. http://www.openwall.com/, 2008.

[40] J. Park, G. Lee, S. Lee, and D.-K. Kim. Rps: An extension ofreference monitor to prevent race-attacks. In PCM (1) 04, 2004.

[41] Peach fuzzing platform. http://peachfuzzer.com/.[42] S. Rueda, D. H. King, and T. Jaeger. Verifying compliance of

trusted programs. In Proceedings of the 17th USENIX SecuritySymposium, pages 321–334, Aug. 2008.

[43] P. Saxena et al. Flax: Systematic discovery of client-side valida-tion vulnerabilities in rich web applications. In NDSS, 2010.

[44] B. Schwarz, H. Chen, D. Wagner, J. Lin, W. Tu, G. Morrison, andJ. West. Model checking an entire linux distribution for securityviolations. In Proceedings of the 21st Annual Computer SecurityApplications Conference, 2005.

[45] B. Schwarz, H. Chen, D. Wagner, J. Lin, W. Tu, G. Morrison, andJ. West. Model checking an entire linux distribution for securityviolations. In Proceedings of the 21st Annual Computer SecurityApplications Conference, pages 13–22, Washington, DC, USA,2005. IEEE Computer Society.

[46] K. Sen, D. Marinov, and G. Agha. Cute: a concolic unit test-ing engine for c. In Proceedings of the 10th European software

engineering conference held jointly with 13th ACM SIGSOFT in-ternational symposium on Foundations of software engineering,2005.

[47] Sharefuzz. http://sourceforge.net/projects/

sharefuzz/.[48] K. suk Lhee and S. J. Chapin. Detection of file-based race condi-

tions. Int. J. Inf. Sec., 2005.[49] W. Sun, R. Sekar, G. Poothia, and T. Karandikar. Practical proac-

tive integrity protection: A basis for malware defense. In Pro-ceedings of the 2008 IEEE Symposium on Security and Privacy,May 2008.

[50] D. Tsafrir, T. Hertz, D. Wagner, and D. Da Silva. Portably solv-ing file tocttou races with hardness amplification. In Proceedingsof the 6th USENIX Conference on File and Storage Technolo-gies, FAST’08, pages 13:1–13:18, Berkeley, CA, USA, 2008.USENIX Association.

[51] E. Tsyrklevich and B. Yee. Dynamic detection and preventionof race conditions in file accesses. In Proceedings of the 12thUSENIX Security Symposium, pages 243–255, 2003.

[52] P. Uppuluri, U. Joshi, and A. Ray. Preventing race condition at-tacks on file-systems. In SAC-05, 2005.

[53] J. Viega, J. T. Bloch, Y. Kohno, and G. McGraw. Its4: A staticvulnerability scanner for c and c++ code. In ACSAC, 2000.

[54] H. Vijayakumar, G. Jakka, S. Rueda, J. Schiffman, and T. Jaeger.Integrity Walls: Finding Attack Surfaces from Mandatory AccessControl Policies. In AsiaCCS, 2012.

[55] T. Wang, T. Wei, G. Gu, and W. Zou. TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnera-bility Detection. In IEEE Symposium on Security and Privacy,2010.

[56] J. Wei et al. Tocttou vulnerabilities in unix-style file systems: ananatomical study. In USENIX FAST ’05, 2005.

[57] J. Wei et al. A methodical defense against TOCTTOU attacks:the EDGI approach. In IEEE International Symp. on Secure Soft-ware Engineering (ISSSE) , 2006.

[58] C. Wright, C. Cowan, S. Smalley, J. Morris, and G. Kroah-Hartman. Linux Security Modules: General security support forthe Linux kernel. In Proceedings of the 11th USENIX SecuritySymposium, pages 17–31, August 2002.

[59] C. P. Wright and E. Zadok. Unionfs: Bringing File Systems To-gether. Linux Journal, pages 24–29, December 2004.

[60] W. Xu, E. Bhatkar, and R. Sekar. Taint-enhanced policy enforce-ment: A practical approach to defeat a wide range of attacks. InIn 15th USENIX Security Symposium, pages 121–136, 2006.