deian
I think CSP helps with 1 & 2, unless I'm missing something? (Our labels map down to CSP policies pretty naturally.)
Points 3-4 and phishing, in general, are definitely a concern. Unfortunately, I'm not sure that a great solution that does not get in way exists, but we'll see how close we can get :)
That's actually not the entire point. At least in this paper, we do not claim to address attacks that leverage covert channels. But the attacker model assumption is weaker (i.e., the attacker is assumed to be more powerful) than that originally assumed by the Chrome design (e.g., that only pages are malicious and will try to exploit extensions). And this is important. Particularly because the design that we end up with will be more secure than the current one. So, at worst, the new system addresses the limitations of the existing system under their attacker model. Then, depending on how far you are willing to hack up the browser, underlying OS, or hardware you can also try to address the covert channel leaks.
IFC/tainting mechanism:
The style of IFC we are proposing is not not the tainting style used by more typical language-level systems. In particular, we're proposing a mostly-coarse grained system:
- A single label is associated with a context. A context can be the main extension context or, more likely, a light-weight worker the main extension context created. This single label is conceptually the label on everything in scope. As such, when performing some I/O this label is used by the IFC mechanism to check if the code is allowed to perform the read/write. This coarse-grained approach alleviates the need to keep track of tricky leaks due to control flow: the branch condition has the label of the context so any control flow within the context is safe. If you want to perform a public computation after a secret computation, you need to structure your program into multiple contexts (e.g. create a new worker wherein you intend to perform the secret computation).
- Labels can also be associated with values. A new constructor Labeled is provided for this task. You can think of it as a boxing the value and, by default, only allowing you to inspect the label of the value. You can pass such labeled values around as you see fit (and this is pretty useful in real applications). Importantly, however, when you read the underlying (protected) value the IFC system taints your context---i.e., it raises the context label to let you read the value, but also restricts your code from writing to arbitrary end-points since doing so may leak something about the newly-read value.
An important requirement of this IFC approach is that there be no unlabeled (implicit) shared state between the different contexts. For example, rand() in context A and B must not share an underlying generator. This kind of isolation can be achieved in practice and is an important detail when considering covert channels.
Timing channels:
It turns out that if you do IFC in this coarse-grained fashion you can prevent leaks due to timing covert channels, if you are willing/able to schedule contexts using a "secure scheduler." In [1] we showed how to eliminate timing attacks of the style described in this thread (internal timing channels) that are inherent to the more typical IFC systems. In [2] we extended the system to deal with timing attacks due to the CPU cache by using an instruction-based scheduler (IBS). IBS and other techniques to deal with timing channels are nicely described in [3]. (I'd be happy to expand here, but this is already a long reply.)
[1] http://www.scs.stanford.edu/~deian/pubs/stefan:2012:addressi... [2] http://www.scs.stanford.edu/~deian/pubs/stefan:2013:eliminat... [3] https://ssrg.nicta.com.au/projects/TS/timingchannels.pml
[1] http://www.ieee-security.org/TC/W2SP/2012/papers/w2sp12-fina... [2] http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecti...
Fully agree. We actually described exactly that mechanism in an early version of our paper (declarative APIs), but didn't have enough space to do it for the final version.
"While the tainted data approach sounds interesting, I don't think there's an easy way to guarantee the safeness of arbitrary code executed on your machine. It's possible to sandbox code, but as soon as you allow any communication at all, there's no automated way to prevent data theft."
It turns out, it is possible with information flow control (IFC). The simple idea behind IFC is to protect data by labeling/tagging it and restricting code according to the kinds of labeled data it reads. Once code in an execution context (e.g., iframe or process) reads some labeled data, IFC restricts where it can further communicate. In the simplest form: once you read data that is SECRET, you can't write to any PUBLIC communication channel. (You can, of course, write to a SECRET channel.)
Essentially, yes. Requests from the extension should be treated as if they are of an origin different from the page. (We could potentially piggy-back on existing notions of security principals (e.g., that Firefox has) to avoid huge performance hits.) And if the extension is tainted the kinds of requests will be restricted according to the taint (as in COWL [1], likely using CSP for the underlying enforcement).
"What if the main script is sensitive to the request receive time? Then the shadow DOM may act differently."
If by main script you mean a script on the page, then there should be no real difference.
"From more practical standpoint, having two DOMs for every page will eat even more of my laptop's RAM."
I hope this won't be so bad down the line (assuming we'd be able to leverage some underlying shadow DOM infrastructure and that performs relatively well).
[1] http://cowl.ws
Of course there are other ways malicious extensions can used to leak data---pick your favorite covert channel. But the idea was to propose APIs (and mechanisms) that are not overtly leaky. (We are early in the process of actually building this though.)
[1] https://www.usenix.org/conference/hotos15/workshop-program/p...