So, thanks to my Super Awesome Postdoc, we coined a new field as a result. It stands to reason that Information Flow analysis can be performed on types, just as it has previously been performed on values. A collection of questions suggest themselves:

1. Is it useful? Does sensitive/interesting/important information actually leak as a result of polymorphism? For a typical program, how much does the polymorphic dispatch reveal about your system? On the one hand, I think not so much; because the dispatch is taken on type-compatible instances. On the other, perhaps alot, if you represent much of the problem’s domain in the type system (AuthenticatedCustomer vs Guest). How do standard practices such as Design Patterns affect a programs information type flow?
2. What does the analysis entail? Does it require a statically typed language, so that you can easily identify the polymorphic call sites? Do you still have to provide instrumentation that take place at runtime?
3. What about dynamic languages? Does type-information make its way into dynamic programs? Even in a dynamic language, are the programmers developing as if they had a strongly typed world?

/* pick s from 1 to 3, inclusive */
switch(s) {
case 1: k = 1; break;
case 2: k = 2; break;
case 3: k = 2; break;
}

After this code segment has executed: k is one of two values: 1 or 2. However, one of these values is more informative for the observer. If an observer sees k == 1 then she can infer that s == 1. On the other hand, if the observer sees k == 2 then she can only infer s != 1 (or s in {2,3} with knowledge of s‘s distribution).

For control structures this simple, a static analysis could be run on the code, and provide a result graph of how influential each variable is on others. This graph could be used to quantify how much information might be leaked to an observer. Unfortunately, it comes with the limitation that each branch is considered as drawn from a uniform distribution, which may not be true of actual runtime values.

Nevertheless, I think the ability to statically quantify how much information can be leaked via control flow branches, might be useful for:

1. deciding which variables need tracking,
2. where instrumentation/wrappers/labels might be omitted,
3. where inspections/checks must be inserted,
4. finding variables which fall below a certain leak threshold.

I would really like such an analysis to tell me, for example, whether a variable holding a password is potentially leaked, and if so, how many bits. Or, to list me all the variables of my program in order of how much they might leak.

The inference here sounds like the same as in Probabilistic Predicative Programming by Eric C.R. Hehner (whom I met when Wayne Hayes invited him to give a Friday Seminar talk in Dec 2010), except that it runs backwards on the control flow.

Explicit Flows

The most direct that information can flow between variable is through an assignment statement. For example, the simple line of code: b := a causes information to be transferred a→b. However, we could also have a series of dependent assignments, in which information will flow a→b→c. This kind of indirect flow, a→c can be seen in the series of statements: b := f(..., a, ...); c := g(..., b, ...);.

Implicit Flows

Since, we are trying to assess the influence of some variables on other variables, we must also take into account control flow within the program. For example, a variable might be given a particular value only if some condition is satisfied. I’ve constructed an example of this kind of implicit flow x→y:

bool x := ...
bool y := 1
bool z := 0
if (x == 0) then
    y := 0
else
    y := 1
    z := 1

Any observer examining the value of y after the code is run combined with an a-priori knowledge (gained from a static analysis) can infer the value of x in the conditional. Lest we think that such powers of inference are not worth investigating, consider if the observer is some code that an attacker was able to inject into the system and x represents a secret pin or bit of authentication. Further scrutinizing the above code, we will go through each of the two possible cases (for observers restricted to inspecting the variable y:
x == 0: The variable y is modified to 0. The executed branch exerts a direct influence on the value of observed variable. The observer can determine which branch was taken by inspecting the value of the modified variable.
x == 1: Even though y is modified, it’s value remains unchanged. Because there are only two branches, and y is set to a unique value in each one, the observer can still determine the value of of the conditional variable x.

Let’s now change the game slightly, and restrict the observer to inspecting the variable z. There are still two cases to consider:
x == 0: The variable z is left untouched. But, because the observer knows the value was left unchanged, it can still determine which branch was taken.
x == 1: The variable z is modified, and thus directly informs the observer of which branch was taken.

It should be clear now, that if an attacker can inject code like that above, they can use knowledge of branches not taken to infer values of variables used in the branch conditional. In a world of binary branches, observing variables left unmodified can be just as revealing as a direct assignment.

We therefore have to carefully distinguish between information gained via branches taken (accessible by dynamic analysis at runtime) from those not taken (accessible by static analysis of the source code). Denning’s work did not fully distinguish these two cases; so some recent famous work [3] re-used the term ‘indirect’ for implicit flows from branches taken at runtime. However, in seeking clarity, I now prefer the term active flows for implicit flows in branches taken at runtime, and passive flows for implicit flows from branches not taken. (these choices were made in consultation with my postdoc, who first noticed that ‘indirect’ had been accidentally overloaded).

Let’s summarize this terminology in a nice table:

b := a

b = f(..., a, ...)
c = g(..., b, ...)

x := true
if (x)
   y := 1
else
   ...

x := true
z := 0
if (x)
   ...
else
   z := 1

References

[1] @article{denning1976lattice,
    title={A lattice model of secure information flow},
    author={Denning, D.E.},
    journal={Communications of the ACM},
    volume={19},
    number={5},
    pages={236--243},
    year={1976},
    publisher={ACM}
}

[2] @article{denning1977certification,
    title={Certification of programs for secure information flow},
    author={Denning, D.E. and Denning, P.J.},
    journal={Communications of the ACM},
    volume={20},
    number={7},
    pages={504--513},
    year={1977},
    publisher={ACM}
}

[3] @inproceedings{jang2010empirical,
    title={An empirical study of privacy-violating information flows in
    JavaScript web applications},
    author={Jang, D. and Jhala, R. and Lerner, S. and Shacham, H.},
    booktitle={Proceedings of the 17th ACM conference on Computer and
    communications security},
    pages={270--283},
    year={2010},
    organization={ACM}
}

22 March 2007. The new version of the type system is compiled and tested today. This is about 12 days after I started the revision. The next problem, causing a core dump today, is that range types get frozen but are left unresolved at the end of MatchFunction, so we can’t be sure about coercions and run-time types at that point; we have to defer those until we descend again, during code generation. So there is some re-thinking and rewriting to do there.

23 March 2007. Sorting out the relationship between coercions and subtype tests. This has led to a realization that subtypes have to be tested twice: once when manifesting, without asking for coercions because they are unavailable in the presence of range types, and once during code generation after range types have all been resolved, at which point an error could occur. Also privatised expr_rec further, hiding it from its own subtypes.

28 March 2007. Finally finished working on the relationship between coercions and subtype tests. There were two problems: when the upper constraint is a meet type, and when the lower constraint is a variable. Solutions to both have now been documented, implemented and tested. The next step is to insert subtype calls, and the resulting coercions, during code generation.

As you can see, it’s a pretty high-level summary of the coding concerns for that day. This log runs from 2002 to 2008, and documents the progress of the project. Since, I’ve now moved to WebKit in my Information Flow project, I’ve also started keeping a similar log. Recording each minor milestone of implementation work. I’m expecting this log to help me write my thesis, as it will give me remembrance of details that I might otherwise forget.

I’ve also experienced a secondary benefit from keeping this log. The desire to grow the log, compels me to make progress in my work. I’m motivated to do tasks, just so I can mark them as done in the log. Additionally, since the log is geared toward recording smaller changes, I can break big todo’s up into a series of loggable items. I no longer get flummoxed by thinking of the sum total of work that might go into the implementation. Instead, I’m motivated by smaller tasks, which are easily accomplished.

Finally, the very act of documenting the work, and putting my thoughts into words, has helped to concretize my ideas and concerns. Instead of worrying abstractly about nebulous feelings, I now have mold them into precise explanations. Doing this helps me to realize which aspects are ignorable, and what specific actions I can take to answer the open questions.

Finally, I have a technique that allows me to make steady, targeted progress.

• Source Translation.
  Does a source-to-source translation of JS into a secure subset. The technique is used to jail an included javascript, passing to it only those references to the outside world that it absolutely needs, and preventing it from following reference chains to an outside environment.
  Pros: flexible, follows the object capabilities model, references passed in can implement security monitoring.
  Cons: requires parsing the included script, disallows some JS forms (eval), not much can be done if the included script was written in a way that required passing in more authority than is needed.
  Used by: Caja, Jacaranda, FBJS, ADSafe
• Security Typing.
  Since non-interference can be proved within a sufficiently powerful (and convenient) typing system, we naturally reach for a language solution.
  Pros: the type system can prove the code obeys non-interference
  Cons: crufty syntax introduced for label types, label types difficult to model (polymorphic labels, subtyping, tracking the program counter label, etc), programmer must simultaneously satisify two type systems (admissible program lies in the intersection of orthogonal type systems), requires static type system
  Used by: JiF
• Bytecode Instrumentation.
  Addition of security bytecodes, and necessary modifications to an existing VM so that it ensures non-interference dynamically.
  Pros: works for dynamic languages, fails only on code that actually tries to leak (rather than rejecting code that might leak)
  Cons: difficult to implement, runtime slowdown
  Used by: JSFlow (my project)
• Bytecode Typing.
  Perform security typing on the bytecode instead of on the source.
  Pros: a verifier can refuse code that might leak when that code is loaded (could support eval, by staging the non-interference proofs), this verifier could itself be proved (if implemented in something like Coq)
  Cons: bytecode has less knowledge than the source text (although, with JavaScript the parser could annotate the bytecode with security-related hints, or techniques for typing SSA could also be used), intrepeter produced by Coq would almost certainly underperform.
  Used by: ???
• Bytecode Translation.
  Similar to the secure source subset, but now we parse JavaScript into a bytecode that’s secure by construction (then execute it on a secure VM).
  Pros: The bytecode/VM can be based on a proved core language (such as Flanagan and Austin’s lambda-info)
  Cons: No such VM exists (could be a research project unto itself), would have to implement a JS source-to-secure bytecode translator, and interfacing the secure VM to a browser would be very onerous.
  Used by: ???

In general, I think that the approach we currently use gives the best trade-off in terms of implementation detail, client-visible changes, and implementation effort. However, because I happen to have acquired paranoia (one of the side-effects of working with the security conscious), I find that I cannot completely trust that our implementation behaves as desired. In particular, I wish to have a formal proof that we handle all cases appropriately. I see two major obstacles: (1) Giving a full and complete specification of JS is tedious and itself error-prone, but has been done by hand, and (2) having a proof on one hand, and an implementation on the other does not guarantee that the implementation meets the proof, while an auto-generated implementation from the proof is a no-go because of both performance and integration.

I’d like to repeat an example (given my Mark Miller in his work on E), of two different ways to copy a file, and the security implications of each. First,

shell$ cp foo.txt bar.txt

This command invokes a copy program that will:

1. recognize foo.txt as a filename.
2. recognize bar.txt as another filename.
3. open the file indicated by (1) and read its bytes.
4. open the file indicated by (2) and write bytes into it.

Clearly, the cp command has been delegated quite a bit of power. Much of this authority comes from the interaction with the file system: it needs to be granted access to read from the first file, and it must be granted access to create and write to the second file.

But, we can accomplish the same task by another phrasing:

shell$ cat < foo.txt > bar.txt

In contrast to the above, cat needs no more than access to only the 2 file handles that the shell grants (and this is only stdin and stdout). It does not need to interact with the file system in any other fashion.

This example proves itself enlightening, when we recognize that within any programming language many phrasings can accomplish the same task. The programmers choice of phrasing then becomes a critical aspect of any subsequent analysis. In the above example, even though both programs have the same effect, when we assess the security implications we find very different outcomes. In the case of cp we worry greatly over the potential abuse of authority.

Reasoning about programs.

Even though the above example concerned itself with a trivial task on the command line, we find the same results when we turn our eyes toward full programs. In order to feel comfortable about running a program we’d like to be able to analyze it first, to be sure that it doesn’t “go wrong”. In particular, my research work focuses on enforcing non-interference. So, “going wrong” means that secret information is potentially inferable from publicly observable information.

With that aim in ming, many of the information flow papers that I read treat non-interference as a lemma within a typing system. In order to understand these papers I started reading Pierce’s “Types and Programming Languages”.

In computer science, we use type systems to construct proof regarding our programs. In essence, we want to identify and reject programs that might “go wrong”. Imposing types onto the data allows automated reasoning about a program’s behavior. However, this ability comes at a cost: well-typed programs are a strict subset of all programs. For example, the program:

if (true) then 5 else false;

would be rejected by a strongly-typed system, such as ML, because the result of the if-statement should yield the same type in both branches. Languages, such as JavaScript, that have much more loosely typed systems usually allow such ill-typed programs, and deal with any evaluation errors at runtime.

If you want to be sure of some property about a program prior to running it, you must be able to perform a static type analysis, that proves the property you are interested in. Fortunately for my research, the non-interference proof can be encoded into a type system. Then, any well-typed program will never “go wrong” in the sense that I gave above.

Unfortunately, I research dynamic languages, in which constructs such as eval, and several mechanisms of polymorphism, prevent a precise static type check. (To preserve soundness, the analysis will have to be conservative, resulting in the rejection of almost all real-world programs.) In the next post, I shall examine to what extent we might still be able to leverage strong typing (automated proving) to enforce security in dynamic languages.

1. Fat Values. We can extend the native encoding of values to include a pointer to the label attached to that value. In JS, this means that we’d have to have, at minimum, a 64-bit representation. Both Spidermonkey and Webkit currently use a 64-bit representation, so we’d have to modify the encoding to account for the label pointer. Performing this modification on such a low-level aspect of a VM is not a trivial undertaking, as it will affect many places.
2. Cloaks (aka. labeled wrappers/proxies). We can also implement the labeling, by wrapping each object/value inside another object, whose sole purpose is to carry the label. At first glance, we would expect fewer modifications to be made to the underlying VM, as this only requires the introduction of a new wrapper/proxy class. The difficulty lies in making the wrapper as transparent as possible, it should not be evident (to the JS programmer) that all values are suddenly wrapped up inside labeling objects.

Let’s throw the first curveball that can let us distinguish between these two choices: primitives. In basically all implementations of JavaScript, primitive values are encoded (via tag bits) into a plain old data type. Evidence of this implementation detail occasionally leaks into view of the JavaScript programmer; Early 32bit implementations would auto-convert any integer which could not be represented in 31bits to a double. From an implementers perspective, having primitives makes operations on common types fast, at the cost of introducing some extra special-case logic for each primitive type. Unfortunately, this logic disperses itself across the entire VM.

To give real support to information flow, we will have to come up with a way of tagging both primitives and objects. Primitives represent a challenge because all of their bits are already in use, there simply isn’t any room to add a label pointer to the data payload. It is possible to create such room by changing the way in which primitives are encoded (as introduced in the fat value approach), but comes at a high cost, because it potentially changes the logic all over the system. Still, there remains a distinct advantage: all datatypes have their label directly attached to their representation (encoded into the payload). Taking this approach it would, with a large amount of engineering effort, be possible to give a labeled, 32bit implementation of JavaScript using a 64bit internal datatype.

Alternatively, we could avoid the cost of changing the data representation at the lowest level, and instead wrap each primitive with an object. Objects can be modified to hold a label in addition to all the other special fields (parent, prototype, etc). This field naturally labels the object, and its contents. To label a primitive, we simply stuff it, and the corresponding label, into a special wrapper class. Clearly, this will make some operations slower, because there will be a layer of indirection when the primitive value is unpacked prior to use.

During implementation, we discovered yet more difficulties that arise when cloaking primitives. There are many places within the VM that expect and require primitive values (such as the length field of an Array). Furthermore, when a wrapped class leaves the VM (other code is allowed to use JavaScript as a client) that code can become confused if the resulting class, a cloak, doesn’t match what was expected. That is, external code has many assumptions that it will get back a specific type, and cloaking breaks those assumptions.

In order to have success with the cloaking approach, we have to be able to introduce a new class into the VM, and keep it transparent at both the JavaScript and the VM levels. That is, we don’t want any JavaScript code to become aware that a primitive has been wrapped with an object (for example, attempting to set properties should be ignored) nor do we want the VM to become too aware, because that will require special case-logic it too many places. I’ve concluded that solving both of these constraints is nigh impossible. For example, let’s take the result of the typeof operator. In order to maintain transparency at the JS level, the cloak will have to lie about its type. A cloaked integer should return “number” and not “object”. However, the cloak can’t simply return the result of a dispatched call to typeof in every case, because that interferes with many places inside the VM that a switch-case decides what to do based on the type of an internal value. A jsvalue that encodes an object reference, yet returns “number” when type inspected confuses the logic of the VM.

There is also a strong semantic difference between the two approaches. When using fat values, the label is attached to data when the value is a primitive, and object references when the value is an object (or interned double). When using cloaks the label is attached only to objects themselves. I haven’t fully explored the difference between having a labeled reference vs having a labeled object, but I think the difference is analogous to having an Access Control Listing by columns vs Object Capabilities by rows, as discussed in Capability Myths Demolished.

At this point I am in favor of the fat value approach, because I’m liking the reference semantics, and the transparency with which primitives can be labeled. I’m also willing to accept the cost of having fatter values.

Now for the second curveball: How would you label interned objects? This primarily comes out of Java, but JavaScript does the same thing. With Java, interned objects have an abstraction leak at the == operator. For example, in Java:

Integer x = 5;
Integer y = 5;
Integer a = 10000;
Integer b = 10000;
System.out.println("Integer(5) == Integer(5)? " + (x==y));
System.out.println("Integer(10000) == Integer(10000)? " + (a == b));
 
---------
Integer(5) == Integer(5)? true
Integer(10000) == Integer(10000)? false

What amounts to an optimization, actually hurts our attempts at security. How should we label what are conceptually two different objects, based on their use in the code, if the VM wishes to intern them at the same location? I think it’s pretty clear, that having the objects contain their own labels will run us into trouble. Of course, it’s possible to wrap interned objects with a cloak, but I think it would be difficult to decide that an object (as opposed to a primitive) should be wrapped. Essentially, such a wrapper would amount to a labeled reference: exactly what the fat value approach already provides.

In my reading of information flow security, so far, I’ve yet to see anyone that is discussing these kinds of implementation details. Many papers invent some ideal (tiny) language, then performs a proof of non-interference for that language. Without a means for translating real-world languages (with prototype chains, dynamic field lookup, generators, co-routines, exceptions, continuations, etc.) into that ideal model, we haven’t made progress. Other papers tackle a subset of the real language, and claim that the approach extends to the full language; after trying to implement this stuff myself, I seriously doubt this claim. Many language features just don’t play well together, and can seriously upset some of the hidden assumptions that allow a proof of safety for the subset to be constructed.