Tor Browser Security Under Scrutiny 80
msm1267 writes: The keepers of Tor commissioned a study testing the defenses and viability of their Firefox-based browser as a privacy tool. The results (PDF) were a bit eye-opening since the report's recommendations don't favor Firefox as a baseline for Tor, rather Google Chrome. But Tor's handlers concede that budget constraints and Chrome's limitations on proxy support make a switch or a fork impossible.
Why not work with Mozilla (Score:5, Interesting)
Why not work with Mozilla to address the issues? What about Chromium? I'd put the brakes on anything Google does with Chrome. Their ever-shifting policies have meant that it's no longer a preferred solution to our clients and to my customers. These aren't minor issues either since Google has been building their own walled garden, something a lot of FOSS and Commercial Software organizations won't support. Firefox at least for now, is void of these issues and is much friendlier to the community as a whole.
Re:Findings... (Score:3, Interesting)
One question I have is:
They say ASLR is disabled, and then they recommend using the product with EMET. However, if ASLR is disabled, doesn't that mean that EMET won't be compatible? EMET requires a number of features to be handled correctly before it can be used.
Seems to me that what really has to happen (in this order) is:
1) Mozilla fixes jemalloc or just replaces it with something like PartitionAlloc, fixing these issues for ALL variants that depend on it.
2) TorBrowser takes the Firefox code and recompiles the source as a single package for each target platform, and feeds THAT into its reproducable build system, instead of using standard cross-compile methods. No library loads, etc, just build a binary blob + chrome. This should be able to work under ASLR, if they do it right.
3) Fix whatever's left that prevents TorBrowser running alongside EMET. However, I think after 1 and 2 are done, there shouldn't be a problem here. Some of EMET's features are already baked in to OS X, so if the above issues are fixed, OS X should be in a stable state as well.
4) Assuming 1 and 2 are listed as priorities for both OTF and Mozilla, this should be doable by sometime in Jan/Feb 2015. Probably the best route would be to start a kickstarter ending at sometime in Feb to raise money for a pwn2own slot. If they don't make the deadline in tightening things up, pledges are dropped and nobody loses. If they DO make the deadline, they get the funds, and contestants will proceed to punch holes in the browser. Mozilla will also benefit from this attack, and should probably contribute to said kickstarter.
Re:Why not work with Mozilla (Score:5, Interesting)
My questions are thus... why not move to a model where the entire OS is forced through the tor proxy, This could be done with the use of a dummy network adapter and disabling the current adapter while tor is in use. Yes it would likely break certain OS features during that time, but there it is.
TFA also discusses putting a dumbed down security 'slider' on the browser, but still the default is to allow JIT/JS. Currently you have noscript installed, but not turned off in a fresh install. A few lines of JS is enough to identify an IP or fingerprint more of the system. The default should be most secure with warnings to open it up. Period. At install time you already explin that things do not work like you are used to and then allow the user to decide to reduce security. Anything else provides an illusion of security to a naive user, but still allows an adversary easy means of detection.