Analysis and Experiences with Information Flow

Tracking as a Practical Means to Prevent Data

Leakage

Lisa L Fowler

Electrical Engineering and Computer SciencesUniversity of California at Berkeley

Technical Report No. UCB/EECS-2011-126

http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-126.html

December 9, 2011

Copyright © 2011, by the author(s).All rights reserved.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission.

Analysis and Experiences with Information Flow Tracking as aPractical Means to Prevent Data Leakage

by Lisa L. Fowler

Research Project

Submitted to the Department of Electrical Engineering and Computer Sciences,University of California at Berkeley, in partial satisfaction of the requirements forthe degree of Master of Science, Plan II.

Approval for the Report and Comprehensive Examination:

Committee:

Professor Scott ShenkerResearch Advisor

(Date)

* * * * * * *

Professor Ion StoicaSecond Reader

(Date)

Analysis and Experiences with Information Flow Tracking as aPractical Means to Prevent Data Leakage

Lisa L. FowlerUniversity of California at Berkeley

Abstract

Data leakage is a primary concern for companies andgovernmental agencies, for which information flow ismeans for mitigation. A popular technique used forevaluating pre-existing binaries is “taint tracking,”but such approaches in real-life application were im-practical due to excessive performance costs and nu-merous false positives due to taint explosion. Thenovel techniques used by our system PIFT directlyeliminated these concerns, but revealed new deeperand more troubling concerns. In using PIFT success-fully for information flow tracking on a commodityGUI-based operating system, and upon further in-spection, we discovered that the applications and op-erating systems that we use in day-to-day practice areimperfect components that violate the basic tenets ofinformation flow. In this thesis, we explore infor-mation flow tracking as a whole, elaborate on thesetroubling discoveries, and argue that no matter theperformance improvements or adjustments made tocorrect the metadata for information flow tracking,it will be impossible to provide useful data for theprevention of data leakage without addressing andresolving common practices prevalent across legacysoftware.

1 Introduction

Controlling data leakage is one of the top securityconcerns today. For many industries, data loss isthe top corporate security concern [2, 20, 55]; a con-cern that has increased as companies move to trust-ing third parties with their data, namely with theincrease in reliance on cloud computing [45, 56]. In or-der to prevent and mitigate data loss, the concernedparty must ensure that the target data and docu-ments are stored only at authorized locations and aredisseminated only to the appropriate parties. Thetarget data can be restricted in various ways, such asonly editable by a small group of corporate officers, orviewable only those with a particular security clear-ance, or forwarded to anyone within the organization

but not the general public. Unfortunately, the recenthistory of major data leaks1 suggests that most orga-nizations are severely deficient in this regard, includ-ing those in government [37, 49, 50, 54], education [8,44, 61], and the commercial world [19, 38, 43, 57, 59].

There are three main human vectors for data leak-age:

• Malicious external party

• Malicious internal party

• Well-meaning internal party

In practice, it is for all intents and purposes impossi-ble to prevent a determined internal party with oth-erwise legitimate access to the target data from exfil-trating that data. The determined malicious insidercan utilize any number of out-of-band techniques forleaking the data, e.g., printing the documents, tak-ing pictures of the documents, memorizing the data,sending information encoded as timed requests to atarget website, and so on. Given that a malicious in-sider is limited only by the extent of his imagination,we do not attempt to address this threat, and insteadseek to make their task more difficult.

We have seen corporate insiders intentionally leak-ing sensitive data in recent news [17], however noneof the incidents cited earlier were due to maliciousemployees: The leaks were the result of external at-tackers and/or carelessness on behalf of well-meaningemployees. In many cases, the organization had al-ready devoted significant resources to improving theirsecurity prior to the leak. Furthermore, even afterdetecting a leak and improving security, additionalsecurity breaches often still occur [3, 61]. It is appar-ent that data confinement is a serious problem andthe blame cannot be placed on organizational com-placency or internal malfeasance.

1.1 Imperfect components

Despite the clear threat, and the money and effortdevoted to developing new security technology, it is

1See http://blog.dataleaktoday.com for a litany of such in-cidents.

1

evident that it is hard to prevent leaks of sensitiveinformation even in well-managed organizationswith well-intentioned employees. In short, as weaddress herein, it is because most current efforts toconfine sensitive data rely on imperfect components,and furthermore, it is because of these imperfectcomponents that any effort to automatically detector prevent data loss has remained fruitless.

In the case of a malicious external party, the at-tacker must exploit a vulnerability in the system. Thevulnerability can be any number of: a security policyoversight, a social vulnerability, or a latent technicalvulnerability in the operating system or applicationsoftware. For simplicity, we assume a robust secu-rity policy, however this does not make the task anyeasier.

Consider the second vulnerability: the humancomponent. The attacker can trick otherwise well-meaning internal parties into revealing confidentialinformation. In this case, the attacker might imper-sonate a friendly party or someone in authority inorder to gain the target employee’s security creden-tials, or to trick the employee into installing malicioussoftware on their otherwise secure workstation, etc.Regardless of the particular attack, the outcome inthis scenario is the same: the sensitive data will beexfiltrated from the entity’s domain of control.

Next, we examine the technical vulnerabilities inthe systems that we are trying to protect. In orderto prevent leakage of the target computer data, we re-quire the operating system and application softwareto be resilient against attacks. However, most soft-ware in use today is rife with bugs that can easily beexploited for exfiltration [9]. This is an exceptionallyeffective vector for attack, and unfortunately there islittle hope that this will be rectified in the near future:Legacy code will remain in use for a long time andeven modern software has significant vulnerabilities.If we insist on using legacy software while attempt-ing to defend against data leakage, we must build aseparate supporting mechanism that compensates forthe extant bugs and vulnerabilities.

This system must also be able to detect whenunauthorized parties (such as malicious code, or per-sonnel lacking the required clearance) have accessedsensitive data. This is limited in part by the efficacyof the security policy and how well access controlmechanisms have been implemented. However, weconsider again that we are attempting to implementaccess control on legacy code, which may or maynot support such a mechanism. Furthermore, accesscontrol and data obfuscation techniques (such asencryption) often protect the data during only part

of its lifetime. For example, even though a creditcard number is encrypted and protected by ACLswhile stored in the database, it will have to bedecrypted, stored in memory, perhaps written tocache, and processed in the clear. In our currentoperating systems and applications, any of thoseintermediate states is likely not protected by thesame level of strict security. Our modern operatingsystems simply do not support protecting datathroughout its lifetime.

In the case of a well-meaning internal party, westill encounter hurdles. Confining sensitive data re-quires users to obey dissemination restrictions ondocuments and datasets. Yet we know that other-wise well-meaning users can be careless and occasion-ally email sensitive documents to the wrong parties,transfer data to insecure machines, or otherwise in-advertently allow data to leak.2

Stricter security regulations are not necessarily theanswer because, as Don Norman notes, “When se-curity gets in the way, sensible, well-meaning, ded-icated people develop hacks and workarounds thatdefeat the security” [34]. For example, to get arounddata restrictions implemented on corporate comput-ing systems, users might use a USB key to transferthe data to their personal laptop, thereby creating aneven worse security situation [50].

More generally, when given a choice between secu-rity and convenience, both the market and individualusers will choose the latter. For instance, one of thebiggest security problems is users running executablecode downloaded from an external source. However,this is a feature often required by web sites, so if secu-rity regulations forbid users from doing so, the userswill likely find some way around those regulations tocontinue doing what they wish to do.

Applications can even use legitimate techniques toachieve their goals—techniques that could later causesecurity holes. For example, Skype allows file trans-fers [24]. For legitimate reasons, all of Skype user ses-sion traffic is encrypted, including the file transfers.However, this end-to-end encryption means that nointermediate party can inspect the traffic for virusesor confidential data leaks. Skype currently providesno way of externally disabling file transfers; If one

2This does not take into account willful data theft, which isa case that we find out of scope for this analysis. Beyond thenow famous Wikileaks events [17], we have also seen that laxdata protection systems have enabled employees to steal sen-sitive company data prior to leaving the company. In a recentsurvey, 59% of ex-employees willfully took data without an em-ployer’s permission, with only a little over half of those datathieves reporting unfavorable views of their former employer[25].

2

wanted to prevent Skype file transfers, one must blockSkype entirely—which is a technique that companiesutilize for exactly this reason.3

1.2 Reducing the problem

It is clear that we must find a solution to dataloss prevention that supersedes the imperfect com-ponents. We see that ultimately the outcome in allof the above circumstances is that sensitive data hasleft its protected systems in one form or another. Wereduce the problem to addressing just this outcome,while considering the nuances of each vector.

Fundamentally, the goal in preventing data leakageis understanding data movement and data lifetime de-spite these imperfect components. In order to do so,we must know what is happening to the target data,presently or in the past:

1. Where are that data and its derivatives rightnow?

2. How are the data and its derivatives accessed?

A separate but no less important challenge is achiev-ing determining this with minimal intrusiveness in or-der to foster adoption and encourage continued use.

Many systems have attempted to provide correctinformation flow tracking with varying levels ofsuccess, as we discuss in Section 2. However, asof yet, no system has proven ideal. In our ownattempt to build a data loss prevention system, webelieved that the first two challenges of tracking datamovement were solved problems and the main hurdlewas instead reducing intrusiveness by decreasingthe perceived user slowdown. As such, we strove tosignificantly improve performance beyond the stateof the art into a practical, usable, information flowtracking substrate. After doing so, we discoveredthat in fact, answering the first two questionscorrectly was in fact nearly impossible due to ourunderestimation of the inherent flaws in our legacysystems. We believe that these inherent flaws inour imperfect components means that any effortsto develop a whole-system real-time system thatsufficiently captures data lifetime based on legacysystems will remain fruitless.

We provide herein an introduction to informationflow tracking, as well as a discussion of the varied rea-soning, techniques, and use-cases for information flowtracking. We briefly describe our own solution and

3C.f., promotional material for security products Watch-guard Firebox X Core http://www.watchguard.com/products/core-e/overview.asp and Trend Micro LeakProof http://

www.vmware.com/appliances/directory/193163

detail our experiences applying an information flowtracking technique for data loss prevention in mod-ern applications and operating systems. We continuewith pinpointing the flaws in the general approach ofdynamic analysis for information flow tracking, andconclude with our recommendations for properly ad-dressing data leakage prevention in future systems.

2 Information flow tracking

One way to gain insight into potential leaks of sensi-tive data is to measure information flow, namely thederivation of information in one data object o intoanother data object s. Among other uses, graphs ofinformation flow can be used to check confidential-ity (if a path exists between a confidential s and anunauthorized o, there is a leak) and integrity (e.g.,discovering if a path exists between a trusted s andan untrusted o).

Improved security of information flow can beachieved manually by the programmer, wherein theprogrammer directly makes each and every assertionnecessary to enforce the desired data flow. How-ever, this process is onerous, difficult to verify, andany oversights lead to critical vulnerabilities [9]—anddoes not take into account the dependencies betweendifferent co-existing systems and applications. In aneffort to alleviate this problem, researchers began ex-ploring providing information flow control (IFC) withthe application of information flow models [1, 12, 13].

In short, keeping track of the original sensitive dataand any of its derivatives enables us to see when thatdata is destined to an unapproved site or recipient.

2.1 Applications of IFT

Information flow tracking (IFT) systems and ap-proaches currently have four main application do-mains:4

I Application securityAttack detection and prevention; unknown vul-nerability detection; measure the behavior of for-eign applications; detect malware (e.g., keylog-gers); automatic input filter generation (e.g., de-fending against command injection attacks). Ex-amples include Panorama [69], CWSandbox [67],TaintCheck [31].

II Data lifetimeProvide assertions on data deletion; enforc-ing information flow policies; auditing policy-

4The provided examples are not an exhaustive list.

3

compliant data usage.5 Examples include Taint-Bochs [6].

III Software testing & debuggingFind data leaks; discover input that causes a fail-ure; test case generation; verify or ensure policy-compliant data usage; ensure correctness. Ex-amples include PQL [23].

IV General useAny combination of the above. Examples includeTaintDroid [15], Neon [75], RESIN [70], Loki [72],DStar [74] and HiStar [73].

Despite the common goal of providing informationflow tracking, systems built for a target applicationdomain will often prove insufficient for another do-main, and even the general use IFT systems are of-ten limited in their application to different scenar-ios. Clearly, a system developed for automatic testcase generation will likely be insufficient for capturingreal-time command injection attacks. These differ-ences will prove to be critical when we later explorethe efficacy of IFT in the different scenarios.

2.2 Additional considerations

Regardless of the target application, the IFT systemdesigner must consider additional tradeoffs. Thesedecisions have a direct impact on the completeness ofthe approach. A system might choose to focus on anarrow problem, ignoring more general cases, or viceversa. We enumerate several common, but critical,tradeoffs.

Online or offline Is the target system to be pro-tected an interactive system? Does the IFT sys-tem need to measure real-time events? Will theanalysis be performed on a test machine or in anotherwise out-of-band manner? Section 2.2.1.

Restrictions on modifications Is modifying theapplication/operating system/runtime/etc anacceptable assumption? In particular: Can wemake changes to the hardware or are we limitedto only software changes? To what extent canwe modify the target system? What is thesmallest data representation that we are inter-ested in tracking? Section 2.2.2.

Whole-system analysis Are we only concernedwith behavior within a single application (e.g.,

5For example, detecting regulatory compliance violations,or providing assurances to customers that data is being han-dled in a particular way, such as promising that no user datawill be sent to third party applications [43].

sanitizing user input in a particular web appli-cation such as in [5]); or do we seek to providederived data management across multiple appli-cations or networked systems? Section 2.2.3.

Permanence Will it be necessary to maintain meta-data beyond a particular transaction or session?Should that metadata be maintained across sys-tems or instances? Section 2.2.4.

Policies How much should the system understand“policies”? Are actions on all sensitive itemstreated the same way? Will the system be re-quired to support an externally defined policy,or should it enable the definition of new policieson the fly (e.g., the marking of a particular emailas “Do not forward”)? Section 2.2.5.

We explore each of these tradeoffs in more detail.

2.2.1 Online or offline

Based on the expectations of interactivity and perfor-mance, information flow tracking can be done onlineor offline. It is necessary to perform IFT in real time(online) when you wish to take immediate action oninformation flow events, such as blocking the networktransmission of confidential records, or preventing anemployee from downloading a copy of the source codeto a USB drive.

In contrast, offline IFT can be done on a separatetest machine, or when performance is not a prior-ity. Offline IFT is often simpler due to these lowerperformance demands, more tolerance to false posi-tives and negatives (since the results can be verifiedor repeated), and better isolation. Offline IFT is par-ticularly appropriate for malware analysis [67, 69], aswell as software testing and debugging.

IFT can also be implemented partially online andoffline. For example, a web application request couldbe duplicated and a copy sent to a single “canary”machine out of thousands of datacenter servers in or-der to perform the slower analysis in a non-disruptivemanner. Similarly, one may also record live systemevents and replay those events on an offline IFT sys-tem to log any questionable events during an audit.It is also possible to delay certain IFT calculationsuntil a later point in time if the approach can toler-ate such a delay [46]. In this case, IFT can be delayeduntil a particular event triggers the need for verifica-tion, such as a user submitting a form for processing.

2.2.2 Restrictions on modifications

Depending on the assumptions regarding modi-fiability, the IFT system can have very different

4

incarnations. If one assumes that it is impossible tochange the hardware or to add supplemental hard-ware support, we are clearly restricted to place allIFT support only into the software. Other scenariosallow for changes to the software, but only via theruntime; or allow such extreme changes as rewritingthe entire operating system (e.g., Asbestos [63],HiStar [73], and LoStar [72]); or supports writingor rewriting programs in a different programminglanguage that natively supports IFT.

Can we make changes to the software or hardware?Many researchers choose to build hardware-based so-lutions for IFT [4, 11, 21, 46, 47, 53, 58, 62, 64].By providing IFT support in hardware, performancepenalties could be reduced, and absolutely no changeswould be necessary for the application and operatingsystem. In fact, the new architectures often incur lowperformance overheads and are completely transpar-ent to the existing programs

Of course, a hardware-based solution is sometimesimpossible if we are unable to make changes to thehardware, such as in the case of a deployment oncommodity hardware. Some software-based solutionsattempt to emulate these hardware changes throughthe use of emulators (such as QEMU) and software-based shadow memory [18, 52, 69].

Currently, commodity hardware does not supportthe basic notions of information flow tracking. Whilea hardware-based solution might be excessive whenone is merely verifying user input, it is useful toconsider the fundamental primitives that could bebuilt into hardware that would support IFT solutionsacross application domains.6

To what extent can we modify the target system?The approaches available to the system designer willbe very limited by where and how much they canmodify the target system.

Some of the more promising IFT systems used acustom operating system with IFT primitives pro-vided natively [22, 63, 70, 73]. If it is not possible tomodify the operating system and provide IFT prim-itives, the system designer must decide where in theapplication stack to insert the IFT mechanism.

If we cannot edit or view the source code, we arelimited to binary or dynamic analysis, which is per-formed on an executing program on real or virtualhardware and can be done without access to thesource code.7 Examples of this particular scenario

6We believe that this would be a ripe venue for future work.7For an in depth discussion of dynamic analysis (including

dynamic taint analysis and forward symbolic execution), pleasesee Schwartz, Avgerinos, and Brumley’s detailed guide, “All

are when we wish to provide IFT in commodity off-the-shelf proprietary software or downloaded foreignexecutables. Systems that use dynamic analysis in-clude [4, 7, 14, 16, 65, 69], whose target domains varyfrom security to software verification, and more.

If we can edit the source code of the target pro-gram, we can use static analysis, which can be per-formed without executing the program, and requiresaccess to the source code and/or object code. Someexamples include [28, 40, 66], which use static analy-sis for software verification and testing. Both meth-ods have advantages and disadvantages, and some ap-proaches espouse a combination of both static anddynamic analysis.

Additionally, the inter-positioning point for theIFT mechanism can vary based on the approach.Some techniques provide augmented libraries thatcan be used on the fly [5, 36]. Other approachesmight require recompiling the entire program, or evenrewriting the program in an advanced IFT-aware pro-gramming language.

Over time, it has become evident that hybridapproaches often are more fruitful than a systemthat depends only on dynamic analysis or only onstatic analysis. Dynamic analysis suffers greatlyfrom both false positives and false negatives (aswe explore later in this paper), and static analysiscannot be done on foreign binaries such as malware.Another technique that has shown great promise isimproving isolation (such as sandboxing the softwarethat you cannot inspect properly) and performingIFC at these boundary points, such as with [35, 42].

What is the smallest data representation that weare interested in tracking? Depending on the ap-proach used, IFT can be simplified when consideringlarger objects (process or file object rather than singlecharacters or bytes). However, there is a tradeoff, ashaving analysis available at a finer grain can enable alarger feature set. For some use-cases, an extremelyfine grain might be unnecessary (e.g., for detectingcommand injection attacks)

IFT can be performed at any level in the spec-trum of fine or coarse grained analysis. The granu-larity can have a large impact, both on performanceand on supported features. For example, an IFT sys-tem that tracks data at the byte-level could support“auto-redaction” wherein certain phrases in a docu-ment could be censored or revealed depending on therecipient’s security clearance level; such a task wouldbe impossible for a system that tracked information

you ever wanted to know about dynamic taint analysis andforward symbolic execution (but might have been afraid toask” [48].

5

flow to and from file objects alone.

2.2.3 Whole-system analysis

Another major decision for feature trade-off is in thechoice between whole-system analysis, or targetedanalysis. In the case of automatic input filter gen-eration for a single application (such as for defendingagainst command injection attacks), it might sufficeto provide IFT for only those data used by that ap-plication, as in [5, 32, 39, 68].

Privacy Oracle [11] and TightLip [29] arelightweight tools that are capable of analyzing appli-cations for information leaks without any application-level instrumentations. However, these systems arelimited to the software whose outputs only depend oninputs (and externally controllable parameters suchas time and system configurations) and not scalableto tracing multiple input data.

Other use-cases for IFT require a more completeunderstanding of data movement. In the case of mal-ware analysis, it is critical to understand what otherdata the malware might be accessing, meaning thatfundamentally, the scope is not limited to a singleapplication. Another case is of detecting keyloggers,or other forms of unintended data leakage. The userwishes to know all the places where that data resides,and not just limited to the scope of a single applica-tion. An even larger scale is to consider the interac-tion across multiple systems, such as in [75] and [26].Additional examples of systems that provide whole-system analysis are: Panorama [69], TaintBochs [6],and our own system [16].

2.2.4 Permanence

When considering a particular need for IFT, one mustevaluate whether or not historical information flowmetadata should be retained. Should the IFT be per-formed only on a per-session basis (such as in the caseof evaluating command injection attacks), or shouldthe metadata persist despite major state changes suchas system shutdowns?

Clearly for many instances of software verification,it is sufficient to consider the information flow historyfor a limited amount of time. When using IFT toprevent data leakage, a confidential document shouldbe treated as confidential over its lifetime, and thusthe metadata must be kept in persistent storage andprotected as much as the data itself.

2.2.5 Policies

Depending on the particular application for IFT, thepolicy needs can vary greatly. In a system with only

one well-defined attack vector, such as with commandinjection attacks on a particular web form, or fordetermining if a particular piece of malware has ac-cessed sensitive data, it is sufficient to treat all dataas either suspect or not (or more generally, suspect,sensitive, and neither).

For other applications, the system might want tosupport elaborate policies encoded as metadata. Forexample, it might be necessary to flag a particularemail as “Do not forward” and enforce that that emailand its derivatives are never sent over the networkinterface, while at the same time supporting a “Donot print” notion.

Clearly, information flow tracking can also becomeinformation flow control if the system chooses to en-force the desired policies regarding information flow.

Another point of consideration for implementationis that of defining the policies themselves. Somesystems, such as those performing offline analysisof particular software (either for testing or securityevaluation), can have the policies defined deus exmachina and will never change throughout the IFTprocess, e.g., keystrokes coming over the networkinterface are to be treated as suspect and nothingelse. Other systems might want to enable the user todeclare policy on the fly, e.g., letting the user decidethat a new document is confidential.

After this exploration of the history and tradeoffsin developing an information flow tracking system, wepresent our own approach to preventing data exfil-tration, named PIFT for Practical Information FlowTracking, and comment on our experiences using sucha system.

3 System overview

Conceptually, our system architecture is analogousto a recently proposed IFT system (Neon [75]) andmakes use of similar building blocks to it and itspredecessor [18]—namely, a hypervisor and an aug-mented QEMU-based emulator that tracks informa-tion flow. However, Neon fails to meet the impor-tant requirements of high performance and correctyet parsimonious label propagation for the followingreasons:

1. Taint tracking by plain instrumented emulationis extremely expensive. For example, even asimple computation on tainted data can incur aslowdown on the order of 95×8 when only 1/64thof the input file is tainted [75] (no data is pro-vided on how the system behaves with a more

8According to [75]-Table 3.

6

stressful amount of taint). Such a slowdown isunacceptable in practice and significantly hin-ders the adoption of dynamic taint tracking sys-tems for everyday use.

2. To be comprehensive, taint tracking has to trackinformation flow across pointer references, i.e.,taint the referenced data with the same taint asthe pointer. However, prior work [51] shows thatthis leads to accidental tainting of kernel datastructures, meaning that soon any other appli-cation interacting with the kernel also acquirestaint, and eventually, the taint status propagatesto all data in the system. Such taint explosionrenders the effort of IFT ineffective and substan-tially impairs the performance of the system.

In order for any data leakage prevention systemto be successful in the face of such willful yet well-meaning circumvention:

• The system must minimize any impact to theuser—the user should be able to continue be-having as they would otherwise, with minimalperformance impact;

• The system must be fine-grained enough to sup-port the desired policies—As in our Skype filetransfers case, blocking Skype entirely would beundesirable; we merely wish to prevent the lossof sensitive data;

• The system must support legacy applicationsand operating systems.

We propose three novel techniques that help usaddress the above challenges and bring real-timetaint tracking closer towards the realm of practicality.Specifically:

(1) PIFT performs taint tracking in the emulator ata higher abstraction level than Neon and otherprevious systems. Emulators such as QEMUbreak down each emulated guest instruction intoa series of micro-instructions. Prior work per-forms taint tracking by changing each micro-instruction to propagate taint, which immedi-ately incurs a significant but non-essential over-head. In contrast, PIFT tracks the flow of in-formation directly at the native instruction levelof the protected VM, which enables a range ofoptimizations that are difficult or impossible toapply at the micro-instruction level.

(2) PIFT performs taint-tracking asynchronouslyand in parallel with the main emulation code-path. The key insight is that up-to-date taint

information is only needed under certain con-ditions (e.g., when switching from emulated tonative execution or when invoking a policy).Hence, instead of tracking the propagation oftaint labels synchronously and in lockstep withemulation, PIFT generates separate streams oftaint tracking instructions and executes themasynchronously on another CPU core. In Sec-tion 5, we show that asynchronous taint trackingperformed at a level of abstraction that directlymatches the machine architecture can producea 60× performance improvement over the bestprevious results.

(3) Finally, we identify via empirical evaluation thataccidental tainting of kernel data structures hap-pens through a very narrow interface—a few spe-cific functions in the kernel. We design tech-niques to intercept such channels of taint explo-sion and securely control taint flow, such thatkernel data structures do not unnecessarily gettainted. We propose several minor modifica-tions to the Linux kernel that eliminate acciden-tal tainting and solve the kernel taint explosionproblem for all practical purposes.

After building this system with a goal of fast per-formance with fine grained analysis on legacy soft-ware, we evaluated it on commodity off the shelf soft-ware. In doing so, we discovered that we had under-estimated the final requirement of “supporting legacyapplication and operating systems.” We continue todetail our approach for an IFT solution despite thissetback, and address our discoveries after presentingour technique.

3.1 Design choices

As we detailed in Section 1, any developer of an IFTsolution must consider particular tradeoffs with re-spect to what can or should be modified in the targetsystem. We elaborate on our choices herein.

3.1.1 Software-based solution

Our solution must work on legacy systems, and oncommodity off-the-shelf software as well as hardware.As such, we are limited to a software-based solution.Currently, we can assume that the hardware providesno IFT primitives, and thus we chose to use emulationin order to achieve those primitives.

3.1.2 Whole-system analysis

Information flow tracking across the entire operatingsystem can enable a number of useful tasks. By en-

7

Control VM Protected VM

QEMU / Tag Tracker

Page Tag

Descriptors

Protected

VM

(emulated)

PIFT-ext3

Filesystem NFS Server

Xen-RPC

NFS Client

Xen-RPC

VFS

Kernel(ring 1)

User(ring 3)

App1 App2

PageTag

MaskShadow

page tables

Xen-PIFT (ring 0)

Event channel

Shared ring buffer

Figure 1: PIFT System Architecture. The protected VMis emulated via QEMU in the control VM when it accessestainted data. The PTT-ext3 filesystem is located in thecontrol domain and the protected VM communicates withit via a shared memory RPC mechanism.

abling the programmer to discover deviations fromthe expected flow logic, IFT-aware systems can pro-vide tools for stronger security and debugging. IFT-aware systems can also provide support for strongerpolicies to protect sensitive data or intellectual prop-erty. For example, given a whole-system IFT mecha-nism, one could enforce a policy that no derivationsof the contents of a particular sensitive file can besent over any network interface.

For our target application of preventing data exfil-tration, we must provide a whole-system fine-grainedsolution.

3.1.3 Dynamic analysis via taint tracking

A primary means for achieving IFT on binaries is amethod wherein a label is recorded in shadow mem-ory, and that label is propagated as contents of thememory are computed upon and moved. This label issometimes referred to as a “taint” label, a term thatoriginated from “taint mode” in Perl, wherein all usersupplied input is treated as tainted and suspect un-less the programmer explicitly approves the data [36].Taint-tracking systems have been used for malwareanalysis [69], software verification [7], and protectingdata of interest [71]. Some of these uses require online(or real-time) analysis [75], whereas others are suit-able for offline analysis [30]. Like our predecessors [18,75], we use this technique.

3.1.4 Prevent data leaks

There is a large literature of taint tracking techniqueswhich were successfully applied for malicious codeanalysis (e.g., [5, 18, 30, 31, 52]). Recently, many

approaches focused on information flow tracking forprotecting user data or preventing data leaks [26, 75,76]. In our PIFT system, we also strove to providefull-system fine-grained information flow tracking fordaily use defending against data leakage.

3.1.5 Persistent metadata

For our use case of preventing data leaks, clearly aconfidential document should always be treated asconfidential, even if the user reboots their system.As such, we must require that any IFT metadata haspermanence. We also wish to provide metadata thatcan be transmitted between distributed systems.

3.1.6 Policies

Following [33], at a conceptual level the behavior ofour system is dictated by three policies:

• Input Policy: The input policy determineswhat data is tainted and what taint to apply.For example, an input policy might be to taintall data from a socket with a particular label, andtrack it as it flows through the system. Of course,users and administrators can always mark tainton files and data themselves.

• Propagation Policy: A propagation policy de-termines how taint is propagated from one lo-cation to another. By default, our propagationpolicy carries taints from data sources to datasinks for all data movement (MOV, MOVS, PUSH,

POP, ADD, CMOV, etc.) instructions.

• Assert Policy: An assert policy determineswhen to take action and what actions to take,based on the taint. For example, for data exfil-tration, the appropriate assert policy would beto check taints and prevent exfiltration only atexit points, such as writing to a network device.By default, we worked with an exfiltration-styleassert policy.

Figure 1 sketches a high-level picture of our systemarchitecture, and more detail can be found in [16].

3.2 Prior work

Our system builds on extensive prior work in informa-tion flow tracking (IFT) and dynamic taint analysis(or “taint tracking”) in commodity operating systemsand applications. Information flow tracking was in-troduced nearly 30 years ago as a technique for secu-rity policy enforcement [12, 13]. Early efforts focusedon static analysis (such as the popular work in infor-mation flow control by Myers and Liskov [28]), with

8

later techniques supporting dynamic information flowlabels by combining static and run-time checking,such as [27] and [29]. Another recent work in dynamicinformation flow tracking [70] offers a language run-time that propagates policy objects along with data,and applies this policy by filtering objects at systemI/O boundaries. However, each of these language-based techniques require significant alterations to ap-plication, and the static techniques cannot supportdynamic changes to policy without recompilation.

PIFT associates taint labels with low-level ele-ments of the machine state (individual bytes in CPUregisters, in physical memory, and on disk) and trackstheir propagation at the level of machine instruc-tions. Previous systems such as Asbestos [63], HiStar[73], and LoStar [72] employ an alternate approach—attaching data labels to OS-level primitives such asfile descriptors, sockets, address spaces, and pro-cesses.

In order to perform information flow tracking in en-vironments that do not provide such language, com-piler, or OS support, recent efforts have relied on bi-nary rewriting at runtime as a way of introducing IFTinto commercial applications and operating systems.This has been used to address numerous security-related issues. For example, one body of work [30, 60,69] applies taint tracking mechanisms to the problemof malware detection and analysis. These projectsimpose significant slowdowns, but performance is asecondary concern for offline analysis. Other systemsuse taint tracking mechanisms to understand the is-sues of data lifetime and leakage (e.g., [6], [10], or toenforce security policies on the flow of sensitive userdata in networked environments [75]).

Byte-level taint tracking faces significant perfor-mance challenges and a number of optimizations havebeen suggested in earlier work. Demand emulationand shadow page table trapping were first proposedin [18] and our system directly leverages these tech-niques. Similar in spirit to our work, the Log-BasedArchitecture proposed in [46] attempts to improve theperformance of fine-grained information flow analy-sis through asynchrony and parallelism, but dependson a major hardware extension. Speck [33] proposesa set of techniques for parallelizing security checks(including taint tracking) on commodity hardware.Speck focuses on tracking within one user-level pro-cess and assumes OS-level support for speculative ex-ecution, while our work achieves full-system trackingusing a hardware emulator.

4 Designing for practical infor-mation flow tracking

After building PIFT and addressing the performancehurdles that prevented other systems from beingutilized in daily use, we explored in-practice usingPIFT as an information flow tracking substrate.We present those findings herein, as well as revealour insights into improving the state of the art ininformation flow tracking.

We illustrate the overall machinery of PIFT byconsidering a typical usage scenario—enforcing con-fidentiality policy on the contents of a sensitive file.For simplicity of exposition, we assume that the usertaints the entire file with a single policy label. Ini-tially, the tainted file resides on disk that is man-aged by the taint-aware filesystem and applicationsin the protected VM execute directly the native hostCPU. When an application opens the tainted file, thecall is routed via the hypervisor to the filesystem inthe control VM. Before returning the file handle, thefilesystem makes a call to the hypervisor, informingit of the file’s taint label. In response, the hypervisormarks the memory pages where the file contents arestored as tainted.

Shortly thereafter, the protected VM tries to accessthe file data and since the corresponding pages arenow marked as tainted, the hardware generates a pagefault and delivers it to the hypervisor. The hypervi-sor saves the protected VM’s context and switches toemulated execution in a user- space QEMU processwithin the control VM.

The emulator is instrumented to track the move-ment of taint labels in the manner that reflects thecomputation performed by the protected VM. AsQEMU proceeds with the emulation, it executes addi-tional logic to update data structures that keep trackof taint labels for machine registers and memory ad-dresses. When the protected VM ceases to manipu-late tainted data, the QEMU suspends the emulatedmachine context and notifies the hypervisor, whichreverts the protected VM back to native virtualizedexecution.

The final step is when the policy is invoked. Forexample, the policy might specify that an exceptionshould be raised if tainted data is being externalizedthrough a network interface or a removable blockstorage device, such as a USB stick. The exceptionthrown could be an existing processor fault (e.g.,an invalid opcode) or a new specialized exception.The exception handler provides an opportunity towrite custom policy filters, which can either deny theaction, log it for audit purposes, or filter the content

9

being externalized.

Joining the efforts to provide information flowtracking at a level that would reduce the hurdlesto adoption, we created PIFT. Through our systemPIFT, we provide users with a way of tagging files orparts of their files, track which (non-malicious) ap-plications access that data and how the data is com-puted upon, and ultimately to where (if at all) thedata or any derivative is shipped. Note that PIFT’sgoal is not to secure sensitive data—tracking in PIFTcould be thwarted by additional focused effort from amalicious application. Rather, PIFT enables users tomonitor their personal data and its interactions withcommonly used benign applications. The goal is thatthis functionality be then used to analyze whetheran application is accessing more data than it needs,help implement application access control, or to pre-vent users from accidentally breaking data restric-tions (e.g., ensuring that a secret company file doesnot unknowingly get sent to an offsite email address).

The typical implementation approach to build suchinformation flow tracking is to instrument hardwareemulators such as QEMU with tracking instructions.Hardware emulation is extremely slow, so to improveperformance, modern implementations [18] use em-ulation only for those regions of code that interactwith tagged data. These efforts proved quite use-ful for binary analysis [30], but the performance isstill not adequate for real-time use. In addition, fine-grained tracking often results in accidentally taggingcontrol information such as kernel data structures,which then amplifies into a taint explosion that un-necessarily taints significant portions of data.

These two concerns, poor performance and taintexplosion, have rendered full-system fine-grainedinformation tracking impractical for deploymentoutside of a laboratory environment. This paperpresents our progress in addressing these two prob-lems and thereby making fine-grained taint trackingmore practical. However, this advance enableddeeper testing and evaluation of this approachagainst legacy software, and presented some trou-bling results. We present our approach regardless,since we provided significant performance advancesbeyond the state of the art, and evaluate thosetroubling results in our analysis.

Our approach (which we call PIFT for practical in-formation flow tracking) begins with completely stan-dard building blocks: PIFT uses the Xen hypervisorto run the tracked system within a virtual machine,and (as in [18]) dynamically switches execution on toand off of an augmented QEMU hardware emulator

as tracking is required.To improve performance, we track tags at a

higher abstraction level and in an asynchronous fash-ion. Specifically, instead of instrumenting the micro-instructions QEMU generates to track data, we createa separate stream of tag tracking instructions fromthe x86 instruction stream itself. This provides twobenefits:

• For the tracking instructions, we avoid the am-plification that occurs when we go from onex86 native instruction to multiple QEMU micro-instructions.

• Since this is a separate stream, the tracking canbe done asynchronously and in parallel withoutstopping the emulation context.

In essence, this approach is both directly more ef-ficient (because it generates fewer tracking instruc-tions), and it also allows us to execute those instruc-tions asynchronously; it is the combination of thesetwo effects that give PIFT better performance.

Graphical environments present a non-trivial chal-lenge for fine-grained taint tracking systems such asPIFT. Although such environments rarely imposehigh computational demands, the key challenge isdealing with window rendering systems when tainteddata is present on the screen. A simple screen refreshwill involve moving tainted data around, and hencelead to constant oscillating switches between nativeand emulated execution.

A direct application of PIFT to a graphical envi-ronment with tainted data on the screen leads to sig-nificant performance impairment, to the point thatthe user perceives serious interactivity problems. Thereason is a thrashing behavior resulting from repeatedscreen repaint operations. In typical usage scenar-ios, basic user actions (such as mouse movements andkeystrokes) trigger application-level events that causethe window image to be recomputed. For instance, ifa text window is showing tainted data and the user isentering text from the keyboard, each keystroke causea page fault and transition to emulation. When theguest system finishes computing the new window con-tents (reflecting the keystroke) and relinquishes theCPU, we switch back to the native mode, but findourselves re-entering emulation once again upon thenext keystroke.

We found that the overall performance and usabil-ity of the system can be greatly improved in such sit-uation by making a simple fix: persistently switchingto emulation mode and remaining in emulation modefor as long as tainted data remains on screen. Keep-ing the system persistently in emulation also enables

10

us to leverage significant benefits from asynchronousparallelized tracking. In fact, interactive graphicalenvironments seem to be a fairly compelling use casefor asynchronous taint tracking. Since the guestworkload is interrupt-driven and proceeds mostly athuman timescales, the taint tracker can easily keepup with the producer and the log helps absorb theshort burst of computation resulting from basic useractivity.

Persistent emulation with asynchronous tainttracking led us to a fully-operational and usablegraphical environment. In this environment, usersobserve almost no perceivable degradation of interac-tivity for simple UI actions (e.g., moving the mouse,entering text, scrolling), which we show in Section 6.

For taint explosion (a common problem forapproaches such as ours), we show that a majorsource of the explosion is the tainting of kernel datastructures via a few kernel entry functions. Weshow that the taiting is accidental, and does notreflect explicit information flow. PIFT leverages thisinsight to effectively eliminate kernel taint explosionby interposing and scrubbing taint labels at specificand appropriate points, but unfortunately revealsthat taint explosion is a problem that persists intodesktop applications.

The cumulative effect of our techniques is makingfine-grained information flow tracking significantlymore practical. In fact, PIFT is usable and sup-ports a full graphical user interface, enabling real useractivities—we edited portions of this paper with it!It is this substantial advance that enabled us to moredeeply evaluate the technique of taint tracking as ameans for information flow tracking on legacy soft-ware. From this analysis, we find that dynamic anal-ysis for real-time information flow tracking is funda-mentally flawed due to the reliance on the imperfectcomponents in the target legacy code. There is morework to be done, however we wanted to report on ourprogress and findings so that the community can helpin overcoming the remaining barriers.

4.1 Caveats

It was difficult for us to provide direct comparisonswith previous work. In the two specific cases wherewe could do so, PIFT achieved a slowdown ofroughly 1.4× (compared to native code execution),as opposed to previous efforts (in [75], based on [18])in which the two comparison cases had slowdownsof roughly one and two orders of magnitude, respec-tively. We hasten to note that these two comparison

cases were optimistic ones, and there are other caseswhere our slowdown is higher (roughly 20×).

As we noted, many similar approaches struggledwith the problem of taint explosion [10, 18, 30, 51],wherein in certain paths of data flow, key systemcomponents become tainted, and spread that taintto irrelevant and unrelated data. For taint explosion,we asserted that the source is accidental tainting ofkernel data structures via a few system calls. By in-terposing at these specific system calls, and securelyscrubbing taint, we prevented accidental tainting ofkernel data structures. This prevents incorrect taintpropagation to other data, which we believed wouldeliminate kernel taint explosion in practice. Sincethis enabled us to analyze information flow in appli-cations (rather than the operating system), we dis-covered that not only does taint explosion occur dueto pointer tainting in the kernel, but common pro-gramming paradigms in legacy software also result intaint explosion.

While repeating the technique of interposing atkey points in the application (just as we did with thekernel) to scrub the taint and prevent taint explosionwould be successful, it becomes intractable, andforces us to augment the software, which is againstour earlier assertions that we could not make suchchanges.

Before proceeding, we note that there is anotherproblem with taint tracking: Implicit informationflows (e.g., copying by branching) are not detectableby dynamic analysis and do not leave behind a tainttrail. This can be a problem for certain applicationsof taint tracking such as data exfiltration prevention.However, here we are focusing on making taint track-ing practical for applications such as auditing, debug-ging and data tracking where malicious taint scrub-bing via implicit flows is not a concern. Note thatresearchers are attempting to address this particularflaw by providing a hybrid solution between dynamicanalysis and static analysis or programming languagetechniques. Thus, while implicit information flowsare an important issue for some applications of tainttracking, we do not address this problem here.

In our current design, PIFT tracks all explicit dataflows resulting from variable assignments and arith-metic operations. The emulator monitors the com-putation on tainted data at the level of machineinstructions and propagates the labels accordingly.We also track indirect flows that occur as the resultof pointer dereferencing, whereby a tainted value isused as a base pointer or an offset to access anothervalue in memory. However, like other similar systems,

11

PIFT does not currently track the flow of informationthrough implicit channels that arise from control flowdependencies, such as when the value of a tagged byteinfluences a conditional branch.

5 Performance evaluation

In this section, we evaluate the performance overheadof our prototype implementation under a variety ofworkloads, which include synthetic microbenchmarksand real-world applications. We find the following:

• For a system with 10% of the data tainted, thecomputational overhead over native execution is40%. In the worst case (when all data is tainted),the overhead is 20×. Both of these results ap-pear to be significantly better than prior work,though we can only make exact comparisons intwo specific senarios.

• The performance improvement is the result of acombination of high-level taint flow instrumenta-tion and asynchronous parallel execution of tainttracking.

• PIFT can support graphical windowing environ-ments, ensuring a reasonable level of interactiv-ity and application-level performance. To thebest of our knowledge, PIFT is the first onlinetaint tracking system to demonstrate support forinteractive workloads in a graphical desktop en-vironment.

5.1 Setup

Our test machine is a Dell Optiplex 755 with aquad-core Intel 2.4Ghz CPU and 4GB of RAM. Thehypervisor-level component of our implementation isbased on Xen 3.3.0. The emulator and taint track-ing modules (based on QEMU v0.10.0) run in theprivileged Xen domain as a multi-threaded user-levelprocess. The guest domain is configured with 512MBof RAM and one VCPU (as our current implementa-tion does not yet offer support for multi-processorguest environments). The guest runs a paravirtual-ized Linux kernel v2.6.18-8.

Our experiments evaluate the overhead in the fol-lowing configurations:

• NL: Linux on native hardware• PVL: Paravirtualized Linux on Xen hypervisor• Emul: Linux in a fully-emulated environment

using unmodified QEMU• PTT: Our prototype implementation of Practi-

cal Taint Tracking

- PTT-S: Synchronous taint-tracking- PTT-A(x): Asynchronous parallel tainttracking with x MB of memory reserved for thelog. We explore using log sizes of 512MB, 1GB,and infinite (∞)

We compare our system primarily with Neon [75]when possible. Neon builds on top of the on-demandemulation-based taint tracking system developed byHo et al. [18], and hence provides a comparison toboth systems most closely related to us. However, wewere unable to get the code for [18] working on oursystem since it is based on a heavily outdated versionof QEMU and has fragile dependencies, and as suchwould not work on our test systems. Thus, the onlyway we could provide direct comparisons was to runthe same experiments as reported on in [75] and usetheir published results to compare the two systems.

5.2 Application-level overhead (dataprocessing tools)

We evaluate the overall performance penalty of tainttracking in common usage scenarios via microbench-marks, as perceived by potential users of the system.The goal is to measure if our taint tracking substratecan be used for everyday computing activities.

5.2.1 Copying and compressing

We begin by considering two simple but very commondata manipulation activities:

LocalCopy - Copying a partially-tainted file to an-other file in the guest filesystem using the cp com-mand.

Compress - Compressing a partially-tainted inputfile using thegzip command. Compression repre-sents a somewhat more stressful scenario as it in-volves a nontrivial amount of computation on theinput data.

This experiment exercises the ability of PIFT totransition efficiently between virtualized and emu-lated execution modes. Ideally, one would expectthe slowdown to scale linearly with the fraction oftaint, since the amount of taint should dictate theamount of time spent in emulated taint trackingmode. Our system does not show linear scaling be-cause the heuristics for transitioning are not perfect.The heuristics err on the conservative side, keepingthe system in emulated mode even if one could havetransitioned back to native virtualized mode a bitearlier. Hence, the overhead at low levels of taint islarger than the linear scaling would suggest.

12

0.0 0.2 0.4 0.6 0.8 1.0

010

20

30

40

Fractional amount of tainted data

Slo

wdow

n facto

r com

pare

d to N

Lcopy

PTT−A(512)

Neon

0.0 0.2 0.4 0.6 0.8 1.0

020

40

60

80

100

Fractional amount of tainted data

gzip

Figure 2: Performance overhead in the LocalCopy andCompress experiments.

Finally, although we do not have enough data todraw definitive conclusions, we believe that these re-sults yield a favorable comparison to Neon. In a sce-nario with f = 1/64, where f is the fraction of tainteddata, Neon reports slowdown factors of 10× and 95×for file copy and compression, respectively. This isthe only data point for this experiment reported in[75] (Table 3). We see that taint tracking with PIFTincurs significantly less overhead. The overhead forboth file copy and compression is only 1.4× over na-tive execution. In Figure 2, we can see the perfor-mance of PIFT over the range of f , but have no cor-responding data from [75] except for f = 1/64.

5.2.2 Searching

In the next experiment, we consider another com-mon usage scenario: text search. We use the grepcommand to search the input data set for a single-word string and measure the overall running time.Our input dataset for this experiment is a 100-MBtext corpus spread across 100 equal-sized files. Thesefiles reside on disk at the start of the experiment. Wemeasure the command completion time in all configu-rations of interest and compute the slowdown relativeto native execution, i.e., NL. For PIFT, we repeatthe experiment multiple times, varying the numberof files f marked as tainted. Unfortunately we can-not compare with Neon, since they do not report anymeasurements for this scenario.

Table 1 reports the results of this experiment forthe most stressful scenario, i.e., when all files aretainted (f = 1). As expected, the performance issignificantly worse compared to native execution forthis worst case scenario. PIFT with asynchronous

NL PVL Emul PTT PTT-S -A(512)

Synch Asynch

Completiontime (s)

2.42 2.87 18.45 58.865 25.57

Slowdownfactor

1.00 1.18 7.62 24.32 10.56

Table 1: Text search performance in the worst-case sce-nario (f = 1.0).

parallelized taint tracking is slowed down by a fac-tor of 10×. For more modest amounts of taint, whenonly 10% of the files are tainted, the overhead is 46%over native execution.

Table 1 also quantifies the gain over synchronoustaint tracking obtained by performing taint track-ing in an asynchronous parallelized fashion. Asyn-chronous tracking using multiple cores roughly pro-vides a 2.5× gain over synchronous sequential track-ing on a single core. The best case gain that canbe obtained from parallelization of taint tracking isif it creates an illusion that there is no taint track-ing at all, i.e., it has the same performance as pureemulation. PIFT with parallelized tracking incurs a40% overhead over pure emulation. This nontrivialoverhead is to be expected, especially since the em-ulated instruction sequence has to be instrumentedto write to the log operands that are needed by thetaint tracking instruction sequence.

5.3 Graphical text editor

To measure the performance impact on graphicalapplication-level operations, we instrumented thegedit text editor application and ran a simple usersession. This session included launching the editor,opening a 1.2MB text file, making some changes,computing document statistics, and saving the fileunder a different name. Table 2 reports the resultsfrom this experiment and Figure 3 shows a trace oftaint tracking log usage and CPU utilization in thecontrol domain for this user session.

Although the text editor was fully usable and re-sponsive during this user session, the measured per-formance degradation was somewhat higher than weexpected. Notably, the component of the overheaddue to taint tracking does not increase from previousexperiments in the text console environment. At thesame time, the costs of basic system emulation in-crease to about 20×. Further investigation revealedthe likely source of this discrepancy. The GNOMEgraphical environment on x86 makes extensive use of

13

0 1000 2000 3000 4000

020

40

60

80

100

Timestep (100ms intervals)

% U

sage

CPU Usage and Log Usage while using Text Editor

QEMU CPU (top)Log (512MB)

Figure 3: Time series of log usage and host CPU usageby the QEMU process. Note that the 100% CPU usagemark represents full utilization of both processor cores(producer and consumer).

Action NL Emul PTT-A(512)

Launch editor 2403 7472 8741Open file 302 2087 4634

Compute document stats 307 7309 12491Save file 420 8300 15086

Table 2: Completion time (in ms) for a range of useractions in the gedit text editor experiment.

the SSE instruction set extensions and QEMU doesnot currently optimize the emulation of these proces-sor features. Current versions of QEMU dynamicallyrecompile arithmetic and memory access instructionsinto native code and try to optimize the use of hostregisters. At this time, QEMU does not perform JITrecompilation for SSE instructions and does not takeadvantage of the SSE registers available on the hostprocessor. We expect that the overhead of our sys-tem will be reduced further with orthogonal improve-ments in emulation technology.

6 In-practice performance eval-uation

In the earlier sections, we evaluated the raw perfor-mance of PIFT in several focused use cases. We nowexplore using PIFT as an information flow trackingsubstrate in interactive situations, on a system with amodern GUI, in order to see if our performance gainslisted in Section 5 still persist when performing morecomplicated tasks.

We focus on the user-perceived overhead when per-forming common tasks in applications such as spread-sheets, word processors, web browsers, etc. We also

evaluate the exact overhead of applying a policyagainst the taint labels in a real-world situation inorder to enforce concepts such as, “You may not sendfiles with label xyz over the network.”

Graphical environments are difficult for fine-grained taint tracking systems due to their highly in-teractive nature. Additionally, keyboard and mouseactions will cause many window updates (which maycontain tainted data) and thus may trigger manytransitions to and from emulation. We found thatthe overall performance and usability of such a sys-tem can be greatly improved by making a simple fix:Persistently switch to emulation mode and remain inemulation mode for as long as tainted data remainson screen. Doing so also enables us to leverage signif-icant benefits from asynchronous parallelized track-ing. In fact, interactive graphical environments seemto be a compelling use case for asynchronous tainttracking. Since the guest workload is interrupt-drivenand proceeds mostly at human timescales, the tainttracker can easily keep up with the producer and thelog helps absorb the short burst of computation re-sulting from user activity. This is the primary devi-ation from the sources of performance gains listed inSection 5.

6.0.1 Graphical environment test setup

For the following series of performance tests in inter-active environments, we used a Lenovo H320 with anIntel Core i3 540 processor and 6GB DDR3 RAM.Our guest environment was again configured with512MB RAM, one VCPU, and a modified Linux ker-nel v2.6.18-8. The taint tracking log was fixed at1GB for PIFT-A, and the tests took place entirely inemulated mode. We used the X Window server andGNOME desktop environment. We used vncplay9 tomeasure and replay user input in order to evaluatethe slowdown of various configurations. We providethe following new testing parameters:

PIFT-x/C The guest is “clean” (notainted data in the system).

PIFT-x/T The application is instructedto open or manipulate atainted file.

6.0.2 Graphical application launch test

In the first set of experiments in a graphical envi-ronment, we measure the time it takes to launch aprogram, render the graphical components, load afile, and quit. The programs we measured were Abi-word (an open source word processing program) and

9http://suif.stanford.edu/vncplay/

14

NL Emul PIFT−A/C PIFT−A/T PIFT−S/C PIFT−S/T

020

40

60

80

NL Emul PIFT−A/C PIFT−A/T PIFT−S/C PIFT−S/T

020

40

60

80

Application Launch Task (seconds)

Abiword

OpenOffice Calc

Figure 4: Completion time in seconds for starting anapplication and opening a file (tainted and clean), in bothAbiword and OpenOffice Calc across all configurations.

Ideal NL PIFT-S/T PIFT-A(1GB)/T

WPM WPM %ofIdeal

WPM %ofIdeal

WPM %ofIdeal

60 58.51 98 58.51 98 58.51 98110 107.86 98 107.86 98 107.86 98140 137.72 98 137.72 98 137.72 98150 146.75 98 144.39 96 146.75 98200 198.93 99 168.91 84 198.93 99

Table 3: Time (in seconds) to type a passage at varyingWPM, using vncplay to synthesize keypresses.

OpenOffice Calc (the spreadsheet component of theOpenOffice.org productivity suite). All tests wereperformed with cold filesystem caches.

In this computationally- and graphically-intensivesituation, we confirm the benefits of asynchronyand see that slowdowns are moderate (Figure 4).Compared against emulation alone, asynchronoustaint tracking results in less than a 2× slowdownfor launching an application, even when opening atainted document.

6.0.3 Common GUI-based task test

To measure the performance impact on user experi-ence for common tasks, we measured the time that ittakes a user to complete a series of tasks in GUI-basedapplications. We examined three interactive tasks inparticular: Typing into a word processor, updating aspreadsheet, and browsing webpages.

Typing: To evaluate any perceived slowdown fortyping, we used a slightly modified vncplay to recordthe entry of a passage of text into OpenOffice Writerand play back the entry of the passage with the timingadjusted to simulate typing at a number of differentspeeds (the ideal WPM). When replayed, we mea-sured the time for the entire passage to appear and

NL Emul PIFT−A/C PIFT−A/T PIFT−S/C PIFT−S/T

050

100

150

200

NL Emul PIFT−A/C PIFT−A/T PIFT−S/C PIFT−S/T

050

100

150

200

Productivity Task (seconds)

Web Browsing

Spreadsheet

Figure 5: Time in s to complete the given productivitytask (update spreadsheet in OpenOffice Calc, or browseand click through 10 web pages) in all configurations.

used this to calculate an actual WPM. During play-back, the passage was “typed” into the beginning ofa document that was already tainted (except in theNL case). The results of this test are in Table 3.

Beyond this, we experience no perceptible differ-ence in text entry speed using PIFT, from 60 WPMthrough a very fast 110 WPM, and regardless of taint-edness.10 For PIFT-S, we see performance degrada-tion begin around 140–150 WPM. PIFT-A, however,kept pace with NL throughout the entire test.

Spreadsheet: We measured the impact to user ex-perience when performing a series of basic spread-sheet tasks, such as formatting and copying cells, typ-ing referential formulas, and navigating the spread-sheet using both mouse and keyboard. We measuredthe time that it took a user to complete the overalltask in OpenOffice Calc on each configuration. In NL,the complete task took roughly 1m15s to complete.It should be noted that this test focused on speed—the task being mechanically completed as quickly aspossible, and did not allow for ‘think-time’, whichwould reduce the impact of the overhead.

Our tests showed that emulation itself causesroughly a 2× slowdown compared to NL (Figure 5),and PIFT-A only incurs approximately another 15%overhead regardless of taintedness.

Webpage Browsing: Finally, we evaluated brows-ing and scrolling webpages. We created 10 samplewebpages of varying lengths, containing only verysimple HTML, CSS, and JavaScript. We added 10-20 hyperlinks to each page, and gave the user thetask of finding and clicking on a specific hyperlink oneach page, which would then direct the browser to

10The difference of the measured WPM for all tests (includ-ing native Linux) from the ideal is attributable to overheadfrom VNC and vncplay. Indeed, before some modification tothe timing code in vncplay, the difference between ideal andmeasured WPM was much greater.

15

another page in the series. The user used the Kon-queror web browser with caching disabled and usedonly the mouse for the duration of the test. All fileswere local to the user.

We can see in Figure 5 that the user experiencesa 1.96× slowdown for completing the web browsingtask in the worst-case of PIFT-S/T compared to NL.With PIFT-A(1GB), the task takes on average 1.48×longer. Like the spreadsheet updating task, this taskwas heavily dependent on screen updates, since theuser was required to scroll through and search for aspecific link on each page. As such, we suffer a perfor-mance penalty due to this dependency on graphicalcomponents, but it is no worse than 2× slower thanNL.

6.0.4 Impact of policy checking

One use of information flow tracking is monitoringthe flow of sensitive data, perhaps with the end goalof auditing the export of sensitive data, or blockingthe export of such data outright. We challenge thebenefits gained by asynchronous taint tracking by in-serting a policy check into a regular program, suchthat all data will be checked against the policy anddata flagged with certain taint labels will be blockedfrom export. We predict that the times that we re-quire the logs to become current in order to performthe policy check will be so infrequent that the over-head of policy checking will be minimal.

In this test, we performed a scripted series of tasks,including copying a 20MB file, compressing a direc-tory (23MB uncompressed), appending tainted datato another file, deleting files, and then attemptingto export a potentially controlled file via a modifiedtftp. These tasks were carefully chosen to both ex-plore the benefits of asynchronous taint tracking andto narrowly focus on the overhead of checking thedata against a custom policy, such as, “You cannotsend files with taint label xyz.”

We performed this test in two forms: (A) tftp

compiled from source as-is. (B) tftp is modifiedto support a semantic-aware policy checking mech-anism. Six lines were added to the tftp source code,including a reference to the PIFT helper library. Theoutbound file is examined in 512B increments, witheach block checked for a matching taint label. If anymatching taint label is discovered, we present a noti-fication and the file will be blocked and not sent.

In this test, we attempt to send a tainted file thatwill pass the policy check, so that the times for trans-fers will be included across all tests. We can see in Ta-ble 4 that adding policy checking increases the vari-ance in time to completion by roughly 3×, and adds

Environment PolicyCheck?

Avg Std Dev

Emul N/A 19.69 0.75PIFT-A(1GB)/T Yes 36.72 2.44PIFT-A(1GB)/T No 36.35 0.91PIFT-S/T Yes 44.91 1.82PIFT-S/T No 44.38 0.52

Table 4: Evaluating the overhead of policy checking.Time (in seconds) to complete a sequence of basic tasks,with policy checking code enabled and disabled.

a 1% overhead to complete the task.

One should note that the version of tftp thatperforms policy checking innately requires morelines of code in order to perform the policy checkand handle errors gracefully. It is possible that adeveloper could extend their target program withinefficient policy checking code. Since PIFT onlyprovides the information flow tracking substrate, wecannot control how the final developer writes thepolicy checking code, and thus cannot estimate thefinal overhead for all programs under all circum-stances. In this experiment, we see a very smalloverhead to perform the policy check, and we foreseethat given enough care on behalf of the developer,future applications that leverage the informationflow tracking benefits of our system will see similaroverheads.

In summary, through three key improvements,PIFT provides performance benefits across all taskswhen compared to prior work. For novel features,such as support of graphical environments, eventhough tainted data on the screen effectively forcesthe system to stay in emulated mode, we see en-couraging results for confirming the benefit of asyn-chronous taint tracking. For graphically intensivetasks, we see that it will take the user no more than2–3× longer to complete a task with taint trackingthan without. For applications with minimal graph-ical updates (such as word processing), the impactis imperceptible. Furthermore, we see that when us-ing asynchronous taint tracking for some CPU-heavyworkloads, around 40–50% of the overhead is from theemulation and not the actual taint tracking. Thus,additional improvements to our performance in theseworkloads are possible through further optimizationof the core emulation mechanisms used by QEMU.

Despite these advances, we discovered somethingtroubling about our assumptions. We believed thatperformance was the key hindrance against adoption(solving which enabled us to test our system againsta fully functional GUI), and that we had solved the

16

kernel taint explosion problem by removing the extra-neous taint labels from selected system calls (solvingwhich enabled us to get useful results in practice).However, since we were able to test our system inpractice on common desktop software, we discoveredthat our system was dependent on imperfect compo-nents, and these imperfections would prevent us fromever achieving our goals using this approach.

7 Imperfect components

Once we were able to get a usable system-wide infor-mation flow tracking system, we were able to explorethe effectiveness of taint tracking information flow incommodity applications. When we started, we be-lieved that performance was the primary hurdle pre-venting the adoption of IFT solutions. After our eval-uation, we have decided that performance, while stillimportant, is negligible when considered in the lightof so many false-positives and false-negatives. Cur-rent applications and operating systems consistentlyviolate the basic tenets of information flow such thatany IFT solution based on dynamic analysis is in-tractable.

7.1 Implicit flows

We face the problem of implicit flows with the useof several common programming constructs, namelybranching. Consider the following code sample:

int x = 0;

char ch = getchar ();

if (ch == ’a’)

x = 1;

We can see that in this case, any taint associatedwith ch cannot be directly propagated to the vari-able x using our technique. x does not explicitlydepend on ch, but could be used to leak informationregarding the value of ch. We assume that theuser is benign and will only use programs that theybelieve to be well-behaved, thus we do not concernourselves with handling these cases directly. Instead,we argue that if the user or administrator determinesthat implicit flows such as these are essential to aprogram’s function, he will instead opt to confinethe execution of that program to a separate virtualmachine. Any program that requires branching(e.g., if and switch statements) to perform its mainfunction should be evaluated on a case-by-case andper-site basis.

Consider another case:

char ch = getchar ();

int x = my_array[ch];

As described in Section 4, any taint associated withch is propagated to x.

We seek to argue that the second case of usingtainted data as an index into an array of potentiallyuntainted data is in fact a more common techniquethan using branching to generate output.

Case study: tr

tr is a simple command-line text replacement tool.The basic function of this program is to replace a setof single characters in a given input string with corre-sponding characters, or delete those target charactersentirely.

In the case of character replacement, the methodis straightforward and taint-maintaining. tr createsan array, string1[] such that all 256 ASCII char-acters appear in the following manner: For everya = 0..255, where a is the numerical ASCII repre-sentation for a character, string1[a] = a. If a char-acter a is due to be replaced with b, tr then setsstring1[a] = b. After performing all the desired sub-stitutions to this character index, tr then executesthe replacement by merely reading the input stringcharacter by character, and using each character asan index into the string1 array, creates a new stringwith the desired characters replaced. Since taints arepropagated when using tainted data as an index toan array, we can still enforce data confinement.

while ((ch = getchar ()) != EOF)

(void)putchar(string1[ch]);

In the case of character deletion, we face the prob-lem of implicit flows. In this case, tr sets the valuesof string1[a] to be either 1 or 0 indicating whetheror not the character is due to be deleted. Then, uponreading the input string character by character, thenew string is created by only those characters forwhich string1[a] == 0.

while ((ch = getchar ()) != EOF)

if (! string1[ch])

(void)putchar(ch);

In this case, the taint on the deleted characters willnot be propagated, due to the fact that the taintedcharacter would only be used in the if statement,and as written, the tainted character will not appearin the output string.

While tr could be used in a manner that re-tained taint, one usage case could potentially leakinformation, and as such, we would leave it to

17

the administrator to decide if this program shouldbe limited to execution in a separate virtual machine.

Case study: TEX and dvipng

When rendering a DVI as a PNG, the process isvery straight-forward. DVI commands correspond-ing to the numerical representation of the character,such as SETC_127, indicate that the program shouldtypeset the character 127. Pixels are plotted directlyfrom the information retrieved from the font table(e.g., ptr=currentfont->chr[c];), as indexed by thecharacter’s numerical representation. As such, thedata retrieved from the font table is directly used toset pixels (Figure 6).

We can see that the conversion from DVI to PNGdoes not use any form of branching based on poten-tially tainted data, and will thus maintain taints.

Looking at the conversion of TEX to DVI, we havean implicit flow problem with the use of ligatures.TEX attempts to locate sequential characters thatcould be represented by a ligature, such as in thecases of “fi” and “ffi’, and replaces them with the ap-propriate ligature, if supported by the desired font.Unlike with other ASCII characters, the original char-acters will not be transcribed directly into the outputDVI file, and thus the taint for these few characterswill disappear.

In summary, using an application such as dvipng

would not be restricted, but an administrator mightchoose to execute tex and variants in separate virtualmachines.

Case study: gnuplot

gnuplot is a popular open-source command-linedata and function plotting utility. We explore howgnuplot decides which pixels to draw to the outputimage.

In evaluating functions, gnuplot uses a stack tohold intermediate values. Each incoming value ispushed to the stack, which is then popped from thestack and evaluated according to the desired mathe-matical function as a simple passed argument, withthe output pushed back on the stack. This is easilyhandled with our technique for taint propagation. Assuch, calculating sin(x) where x is tainted will resultin a tainted output.

Results are stored in a struct that maintains the co-ordinates that will be plotted. Coordinates are con-verted to terminal coordinates, using the followingmacro code (where variable is the tainted value):

(int) (( axis_array[axis]. term_lower) \

+ (( variable) - axis_array[axis].min) \

* axis_array[axis]. term_scale + 0.5)

Taint is still propagated. The resultant values arethen passed to the terminal driver.

If using X11, commands for graphing lines or plot-ting points are stored in a buffer, in well-defined for-mats, featuring the potentially tainted data directly.For example, a point would be retrieved as follows:sscanf(buffer + 1, "%d-%d-%d", &point, &x, &y);

which would then be stored into a pixmap using theX11 function: XDrawPoint. This pixmap is laterrendered using the X11 drivers. Advanced pointrepresentations such as diamonds and crosses arehandled using simple arithmetic to create a seriesof segments, which are then stored in the outputpixmap. Cairo performs its graphing functionssimilarly.

One might consider the information leaked by dy-namic axes, but we find that the axes are expandedor contracted based on tracking the max and minvalues for each axis. As such, taint is maintainedthroughout. We find no instances where branchingis essential to the flow of data through gnuplot.

7.2 Problematic programmingparadigms

In our evaluation of commodity off-the-shelf applica-tions, we discovered that some common programmingparadigms severely inhibit our ability to perform use-ful information flow tracking. If our tolerance for er-rors (be they false positives or false negatives) is low,these paradigms will be found to be too common toenable correct and useful information flow tracking.

7.2.1 Shared libraries and components

For example, when exploring text editors, such asgedit, medit, and AbiWord, we discovered thatmerely loading a tainted file into memory would causeany subsequent file written by any other programin that set to be marked with the same taint la-bel. What we discovered was that each of these pro-grams used the glib+ libraries, and in particular, themessage bus of glib had become tainted. All fileswritten or loaded into memory by glib would gainthat taint label, including user-level state files suchas ~/.recently-used.xbel, ~/gtkfilechooser.ini, aswell as several other metadata or session files. Theuse of common libraries and constructs such as a mes-sage bus is not that uncommon, and in fact is relatedto a general lack of isolation between distinct compo-nents. We believe that the GUI (and even GPU) willalso be a place where IFT semantics can be abused.

18

for( y=0; y<ptr ->h; y++) {

for( x=0; x<ptr ->w; x++) {

if (ptr ->data[pos]>0) {

pixelgrey=gammatable [(int)ptr ->data[pos ]/2];

bgColor = gdImageGetPixel(page_imagep , hh + x, vv + y);

// snip set color of pixel

gdImageSetPixel(page_imagep , hh + x, vv + y, pixelcolor );

}

pos++;

}

}

Figure 6: Case study: TEX and dvipng

7.2.2 Branching

Another common programming paradigm is that ofusing switch statements. Unicode translation is suchan example of branching that evades taint propaga-tion. Mentioned as early as 2004, the researchers whodeveloped TaintBochs discovered that the Windows2000 kernel uses this form of branching to translatekeyboard scancodes into unicode [6]. As such, theydiscovered that a tainted password would appear inmemory in both a tainted form (scancode) and an un-tainted form (unicode). Researchers continued to ex-perience this particular problem in Taint Eraser [76]and [30], among others. As of yet, this problem hasnot been resolved in any dynamic analysis system.Panorama [69] addressed this exact problem in Win-dows XP by specially instrumenting an instructionwithin the function xxxInternalToUnicode.

While we used the technique of taint scrubbing orwhitelisting specific system calls that we manuallyverified to not mandate the propagation of taint la-bels, since this pattern appears in the desktop appli-cations as well, we find that we are at an impasse.Since we asserted that we are not allowed to changethe desktop applications in order to provide IFT, weare unable to proceed, and consequently any tech-nique with similar goals will also remain fruitless.

7.3 Lack of GUI isolation

The lack of GUI isolation has been known to be a se-curity concern for many years [41, 42]. An example ofthis particular concern can be explored by the readerthrough xinput. A short recipe is as follows:

1. Install xinput.2. As user, attach and run xinput to the system’s

keyboard3. Open a terminal window as root

4. Type into the root-owned terminal window

The user terminal running xinput will reveal allkeys entered in that root-owned terminal window.

The general theme of lack of isolation is a troublingone. The lack of isolation enables attackers to crossthese boundaries between systems with potentiallydiffering policy demands.

7.4 Additional threats

As the above examples demonstrate, informationleakages happen because current systems provide amyriad number of channels through which data canbe easily pilfered or lost. PIFT aims to prevent suchleakage by allowing administrators to tag sensitivedata, track it, intercept and enforce security poli-cies on all exchanges between principals. However,we do not expect users to be malicious. An adver-sarial insider can always photograph a screen withsensitive data, an attack that any software based ap-proach cannot defend against, yet we allow users to becareless. Users can access untrusted sites, downloadpotentially unsafe external applications, and use allthe normal means of communication they have cometo expect (email, peripherals, etc).

PIFT treats the hypervisor, emulator and backenddrivers as part of the trusted computing base, but itmakes no assumptions about the operating systems orapplications. Second, we assume that at startup, thehypervisor can be securely loaded before any othercode executes. With the advent and wide availabilityof trusted computing hardware in computers, such anassumption is feasible. Finally, we assume that theexistence of a key infrastructure within the trustedboundary, so hypervisors can sign and verify mes-sages from each other.

19

8 Conclusion

We began seeking to address the problem of dataexfiltration. Common approaches using informa-tion flow tracking seemed to be promising, with thebiggest hindrance to adoption being the dramaticoverhead incurred due to the taint tracking tech-niques used. We saw three possible areas for im-provement: Track taint labels at a higher abstractionlevel, namely at the native instruction level of the pro-tected VM; Perform taint tracking asynchronously,only evaluating the IFT metadata as needed accord-ing to the policy demands; and eliminate kernel taintexplosion by separating the system calls into thosewhich should logically propagate the taint labels vs.those that should not. These three changes proved tobe those which decreased our performance overheadto a level that enabled real users to interact witha IFT-aware GUI-based commodity applications andoperating system (with usable results), a feat we be-lieve to be the first of its kind.

It is because of this new ability that we were able toevaluate the technique of taint tracking as a meansto achieve information flow tracking on commodityapplications and operating systems. What we discov-ered was that early results expressing concern abouttaint explosion where founded, but not sufficient intheir scope. We discovered that our legacy appli-cations and operating systems are imperfect compo-nents that rely on techniques that fundamentally vi-olate the notions of information flow, particularly asrevealed by dynamic analysis. If we seek to provideinformation flow tracking or information flow controlto extant application binaries, we will most likely fail.

So what is a researcher to do? We need to thinkabout information flow tracking at all stages of ourdesign. Support for IFT needs to be built nativelyinto the programming languages, with the needs ofthe programmer in mind, and IFT needs to be sup-ported by the (trusted) hardware, and the operatingsystem. More importantly, we need to enforce andsupport isolation. As our systems become more com-plex, it becomes even more important to sandbox andisolate foreign or untrusted code. Recent efforts tonatively support isolation in the operating system asa security measure have shown great promise.

For future work, we recommend: Evaluating theCPU changes with the most potential for assistingwith IFT; and exploring IFT only on the messagessent between isolated virtual machines, each of whichenables legacy or suspect software to run unhinderedand unattended. In the latter case, it could be con-ceivable to use programming language techniques toimplement the IFT between the isolated components.

We believe that isolation and programming language-based techniques for information flow tracking will bethe correct path to achieving practical informationflow tracking on a daily basis.

9 Acknowledgements

With sincere gratitude to Scott Shenker, SachinKatti, Andrei Ermolinskiy, and James Murphy Mc-Cauley, without whose advice and hard work thiswould have been impossible; and to Kevin Jeffay forhis constant support and encouragement. This workwas funded in part by the National Science Founda-tion and the University of California.

References

[1] G. R. Andrews and R. P. Reitman and. “An Ax-iomatic Approach to Information Flow in Pro-grams”. In: ACM Trans. Program. Lang. Syst. 2(1 1980), pp. 56–76.

[2] H. Barwick. Identity theft, e-fraud top Australiansecurity concerns: Unisys. Computerworld. May2011. url: http://www.computerworld.com.au/article/385356/identity_theft_e-fraud_top_

australian_security_concerns_unisys/.

[3] T. Bradley. Sony Hacked Again: How Not toDo Network Security. PCWorld Business Center.June 2011. url: http : / / www . pcworld . com /

businesscenter/article/229351/sony_hacked_

again_how_not_to_do_network_security.html.

[4] S. Chen. “Defeating memory corruption attacks viapointer taintedness detection”. In: In IEEE Inter-national Conference on Dependable Systems andNetworks (DSN. 2005, pp. 378–387.

[5] E. Chin and D. Wagner and. “Efficient character-level taint tracking for Java”. In: Proceedings of the2009 ACM workshop on Secure web services. SWS’09. Chicago, Illinois, USA: ACM, 2009, pp. 3–12.

[6] J. Chow. “Understanding data lifetime via wholesystem simulation”. In: SSYM’04. San Diego, CA,2004, pp. 22–22.

[7] J. Clause and A. Orso and. “Penumbra: automat-ically identifying failure-relevant inputs using dy-namic tainting”. In: Proceedings of the eighteenthinternational symposium on Software testing andanalysis. ISSTA ’09. Chicago, IL, USA: ACM, 2009,pp. 249–260.

[8] G. Cluley. University of Florida warns students andstaff of security breach. Sophos. Feb. 2009. url:http : / / www . sophos . com / blogs / gc / g / 2009 /

02/20/university- florida- warns- students-

staff-security-breach.

20

[9] Common vulnerabilities and exposures (CVE)database. The MITRE Corporation. url: http://cve.mitre.org/data/downloads/.

[10] M. Dalton, H. Kannan, and C. Kozyrakis, and.“Tainting is not pointless”. In: SIGOPS Oper. Syst.Rev. 44.2 (2010), pp. 88–92.

[11] M. Dalton, H. Kannan, and C. Kozyrakis, and.“Raksha: a flexible information flow architecturefor software security”. In: Proceedings of the 34thannual international symposium on Computer ar-chitecture. ISCA ’07. San Diego, California, USA:ACM, 2007, pp. 482–493.

[12] D. E. Denning. “A lattice model of secure in-formation flow”. In: Commun. ACM 19.5 (1976),pp. 236–243.

[13] D. E. Denning and P. J. Denning and. “Certifica-tion of programs for secure information flow”. In:Commun. ACM 20.7 (1977), pp. 504–513.

[14] P. Dhoolia. “Debugging model-transformation fail-ures using dynamic tainting”. In: Proceedingsof the 24th European conference on Object-oriented programming. ECOOP’10. Maribor, Slove-nia: Springer-Verlag, 2010, pp. 26–51.

[15] W. Enck. “TaintDroid: an information-flow track-ing system for realtime privacy monitoring onsmartphones”. In: Proceedings of the 9th USENIXconference on Operating systems design and im-plementation. OSDI’10. Vancouver, BC, Canada:USENIX Association, 2010, pp. 1–6.

[16] A. Ermolinskiy. Towards Practical Taint Track-ing. Tech. rep. UCB/EECS-2010-92. EECS Depart-ment, University of California, Berkeley, 2010. url:http://www.eecs.berkeley.edu/Pubs/TechRpts/

2010/EECS-2010-92.html.

[17] L. Greenemeier and C. Q. Choi and. WikiLeaksBreach Highlights Insider Security Threat. Scien-tific American. Dec. 2010. url: http : / / www .

scientificamerican . com / article . cfm ? id =

wikileaks-insider-threat.

[18] A. Ho. “Practical taint-based protection using de-mand emulation”. In: SIGOPS Oper. Syst. Rev.40.4 (2006), pp. 29–41.

[19] S. R. Hunt. Symantec leaks credit card data. APCMagazine. Mar. 2009. url: http://apcmag.com/symantec-says-credit-card-data-could-have-

leaked-from-india.htm.

[20] Indian companies find data loss biggest securityconcern. CXO today. Nov. 2009. url: http://www.cxotoday.com/story/indian- cos- find- data-

loss-biggest-security-concern/.

[21] H. Kannan, M. Dalton, and C. Kozyrakis, and.“Decoupling Dynamic Information Flow Trackingwith a dedicated coprocessor”. In: Dependable Sys-

tems Networks, 2009. DSN ’09. IEEE/IFIP Inter-national Conference on. 2009, pp. 105 –114.

[22] M. Krohn and E. Tromer and. “Noninterferencefor a Practical DIFC-Based Operating System”. In:Proceedings of the 2009 30th IEEE Symposium onSecurity and Privacy. Washington, DC, USA: IEEEComputer Society, 2009, pp. 61–76.

[23] M. S. Lam and M. Martin and. “Securing webapplications with static and dynamic informationflow tracking”. In: In ACM Symposium on PartialEvaluation and Semantics-based Program Manipu-lation. 2008, pp. 3–12.

[24] H. Max and T. Ray and. Skype: The DefinitiveGuide. Que, 2006.

[25] More than half of ex-employees admit to stealingcompany data according to new study. SymantecCorp and the Ponemon Institute. Feb. 2009. url:http://www.symantec.com/about/news/release/

article.jsp?prid=20090223_01.

[26] Y. Mundada. Practical data-leak prevention forlegacy applications in enterprise networks. Tech.rep. GT-CS-11-01. Georgia Tech, 2011.

[27] A. C. Myers. “JFlow: practical mostly-static in-formation flow control”. In: POPL. San Antonio,Texas, United States, 1999, pp. 228–241.

[28] A. C. Myers and B. Liskov and. “A decentral-ized model for information flow control”. In: SOSP.Saint Malo, France, 1997, pp. 129–142.

[29] S. K. Nair. “A virtual machine based informationflow control system for policy enforcement”. In:Electron. Notes Theor. Comput. Sci. 197.1 (2008),pp. 3–16.

[30] J. Newsome and D. X. Song and. “Dynamic TaintAnalysis for Automatic Detection, Analysis, andSignature Generation of Exploits on CommoditySoftware”. In: NDSS. 2005.

[31] J. Newsome. “Dynamic Taint Analysis for Auto-matic Detection, Analysis, and Signature Genera-tion of Exploits on Commodity Software”. In: 2005.

[32] A. Nguyen-tuong. “Automatically Hardening WebApplications Using Precise Tainting”. In: In 20thIFIP International Information Security Confer-ence. 2005, pp. 372–382.

[33] E. B. Nightingale. “Parallelizing security checks oncommodity hardware”. In: ASPLOS XIII. Seattle,WA, USA: ACM, 2008, pp. 308–318.

[34] D. A. Norman. “When security gets in the way”.In: interactions 16 (6 2009), pp. 60–63.

[35] I. Papagiannis. “PrivateFlow: decentralised infor-mation flow control in event based middleware”. In:Proceedings of the Third ACM International Con-ference on Distributed Event-Based Systems. DEBS’09. Nashville, Tennessee: ACM, 2009, 38:1–38:2.

21

[36] Perl Security. Perl. url: http://perldoc.perl.

org/perlsec.html.

[37] Personal information: data breaches are frequent,but evidence of resulting identity theft is limited;however, the full extent is unknown. US Govern-ment Accountability Office. June 2007. url: http://www.gao.gov/products/GAO-07-737.

[38] L. Phifer. Top 10 data breaches of 2010. eSe-curity Planet. Jan. 2011. url: http : / / www .

esecurityplanet.com/features/article.php/

3921656/Top-10-Data-Breaches-of-2010.htm.

[39] T. Pietraszek. “Defending against Injection Attacksthrough Context-Sensitive String Evaluation”. In:In Recent Advances in Intrusion Detection (RAID.2005.

[40] M. Pistoia. TAJ: Effective Taint Analysis of WebApplications. 2009.

[41] A. Pretschner. “Usage Control Enforcement withData Flow Tracking for X11”. In: Proc. 5th Intl.Workshop on Security and Trust Management(STM). 2009.

[42] Qubes OS. Invisible Things Lab. 2011. url: http://qubes-os.org/.

[43] F. Y. Rashid. Most websites regularly leak sensitive,personal data: survey. eWeek.com. June 2011. url:http://www.eweek.com/c/a/Security/Most-Web-

Sites - Regularly - Leak - Sensitive - Personal -

Data-Survey-640359/.

[44] D. Raywood. University College Berkeley hit bysecond data breach in six months as details ofalmost 500 applicants are hacked. SC Magazine.2009. url: http : / / www . scmagazineuk . com /

University-College-Berkeley-hit-by-second-

data-breach-in-six-months-as-details-of-

almost-500-applicants-are-hacked/article/

146593/.

[45] T. Ristenpart. “Hey, you, get off of my cloud:exploring information leakage in third-party com-pute clouds”. In: Proceedings of the 16th ACMconference on Computer and communications secu-rity. CCS ’09. Chicago, Illinois, USA: ACM, 2009,pp. 199–212. url: http://doi.acm.org/10.1145/1653662.1653687.

[46] O. Ruwase. “Parallelizing dynamic informationflow tracking”. In: Proceedings of the twentieth an-nual symposium on Parallelism in algorithms andarchitectures. SPAA ’08. Munich, Germany: ACM,2008, pp. 35–45.

[47] H. J. Saal and I. Gat and. “A hardware architecturefor controlling information flow”. In: Proceedings ofthe 5th annual symposium on Computer architec-ture. ISCA ’78. New York, NY, USA: ACM, 1978,pp. 73–77. url: http://doi.acm.org/10.1145/

800094.803030.

[48] E. J. Schwartz, T. Avgerinos, and D. Brumley, and.“All you ever wanted to know about dynamic taintanalysis and forward symbolic execution (but mighthave been afraid to ask”. In: In Proceedings of theIEEE Symposium on Security and Privacy. 2010.

[49] Sensitive TSA manual posted on web. USA To-day. Dec. 2009. url: http : / / www . usatoday .

com / travel / flights / 2009 - 12 - 08 - airport -

security_N.htm.

[50] N. Shachtman. “Under Worm Assault, MilitaryBans Disks, USB Drives”. In: (2008). url: http://www.wired.com/dangerroom/2008/11/army-

bans-usb-d/.

[51] A. Slowinska and H. Bos and. “Pointless tainting?:evaluating the practicality of pointer tainting”. In:EuroSys ’09. Nuremberg, Germany, pp. 61–74.

[52] K. Z. Snow. “SHELLOS: enabling fast detectionand forensic analysis of code injection attacks”. In:Proceedings of the 20th USENIX conference on Se-curity. SEC’11. San Francisco, CA: USENIX Asso-ciation, 2011, pp. 9–9.

[53] G. E. Suh. “Secure program execution via dynamicinformation flow tracking”. In: Proceedings of the11th international conference on Architectural sup-port for programming languages and operating sys-tems. ASPLOS-XI. Boston, MA, USA: ACM, 2004,pp. 85–96.

[54] B. Sullivan. Government agency exposes day-caredata. 2010. url: http://www.msnbc.msn.com/id/4186130/.

[55] Survey: SMBs are getting serious about informa-tion protection. Symantec. 2010. url: http://www.symantec.com/about/news/resources/press_

kits/detail.jsp?pkid=smbsurvey2010.

[56] K. Thomas. Microsoft Cloud Data Breach Her-alds Things to Come. 2010. url: http://www.

pcworld.com/businesscenter/article/214775/

microsoft_cloud_data_breach_heralds_things_

to_come.html.

[57] T. Thorsen. PSN data leak cost could top $24 bil-lion. Gamespot. Apr. 2011. url: http : / / www .

gamespot.com/news/6310436.html.

[58] M. Tiwari. “Complete information flow trackingfrom the gates up”. In: Proceeding of the 14th in-ternational conference on Architectural support forprogramming languages and operating systems. AS-PLOS ’09. Washington, DC, USA: ACM, 2009,pp. 109–120.

[59] Trend Micro hit by massive Web hack. InfoWorld.2008. url: http : / / www . infoworld . com / d /

security-central/trend-micro-hit-massive-

web-hack-212.

22

[60] J. Tucek. “Sweeper: a lightweight end-to-end sys-tem for defending against fast worms”. In: SIGOPSOper. Syst. Rev. 41.3 (2007), pp. 115–128.

[61] University of California hit by data breach thatmay affect 160,000 past and present students. SCMagazine. 2009. url: http://www.scmagazineuk.com/University-of-California-hit-by-data-

breach- that- may- affect- 160000- past- and-

present-students/article/136499.

[62] N. Vachharajani. “RIFLE: An architectural frame-work for user-centric information-flow security”.In: In MICRO 37: Proceedings of the 37th annualIEEE/ACM International Symposium on Microar-chitecture. IEEE Computer Society, 2004, pp. 243–254.

[63] S. Vandebogart. “Labels and event processes in theAsbestos operating system”. In: ACM Trans. Com-put. Syst. 25.4 (2007).

[64] G. Venkataramani. “FlexiTaint: A programmableaccelerator for dynamic taint propagation”. In:High Performance Computer Architecture, 2008.HPCA 2008. IEEE 14th International Symposiumon. 2008, pp. 173 –184.

[65] T. Wang. “TaintScope: A Checksum-Aware Di-rected Fuzzing Tool for Automatic Software Vul-nerability Detection”. In: Security and Privacy,IEEE Symposium on 0 (2010), pp. 497–512.

[66] M. Weiser. “Program slicing”. In: Proceedings ofthe 5th international conference on Software engi-neering. ICSE ’81. San Diego, California, UnitedStates: IEEE Press, 1981, pp. 439–449.

[67] C. Willems, T. Holz, and F. Freiling, and. “To-ward Automated Dynamic Malware Analysis Us-ing CWSandbox”. In: IEEE Security and Privacy5 (2007), pp. 32–39.

[68] W. Xu, E. Bhatkar, and R. Sekar, and. “Taint-enhanced policy enforcement: A practical approachto defeat a wide range of attacks”. In: In 15thUSENIX Security Symposium. 2006, pp. 121–136.

[69] H. Yin. “Panorama: capturing system-wide infor-mation flow for malware detection and analysis”.In: CCS ’07. Alexandria, Virginia, USA, pp. 116–127.

[70] A. Yip. “Improving Application Security with DataFlow Assertions”. In: SOSP. Big Sky, Montana,2009.

[71] A. R. Yumerefendi, B. Mickle, and O. P. Cox, and.“TightLip: Keeping applications from spilling thebeans”. In: In Proc. 2007 NSDI. 2007.

[72] N. Zeldovich. “Hardware Enforcement of Applica-tion Security Policies Using Tagged Memory”. In:OSDI. 2008, pp. 225–240.

[73] N. Zeldovich. “Making information flow explicitin HiStar”. In: OSDI. Seattle, Washington, 2006,pp. 263–278.

[74] N. Zeldovich, S. Boyd-Wickizer, and D. Mazieres,and. “Securing distributed systems with infor-mation flow control”. In: Proceedings of the 5thUSENIX Symposium on Networked Systems Designand Implementation. NSDI’08. San Francisco, Cal-ifornia: USENIX Association, 2008, pp. 293–308.

[75] Q. Zhang. “Neon: system support for derived datamanagement”. In: VEE ’10. Pittsburgh, Pennsyl-vania, USA, 2010, pp. 63–74.

[76] D. Y. Zhu. “TaintEraser: protecting sensitive dataleaks using application-level taint tracking”. In:SIGOPS Oper. Syst. Rev. 45 (1 2011), pp. 142–154.

23