Slashdot Mirror
Browser History Sniffing Is Back
An anonymous reader writes "Remember CSS history sniffing? The leak is plugged in all major browsers today, but there is some bad news: in a post to the Full Disclosure mailing list, security researchers have showcased a brand new tool to quickly extract your history by probing the cache, instead. The theory isn't new, but a convincing implementation is."
Fixed cache size of 0.
This tool seems unreliable (at least in Chrome). I've been on YouTube five times in the past 48 hours and it still showed up grey on the sniffer.
Browser developers are not doing proper development anymore. They are too busy playing stupid games like hiding http://, removing status bars, inflating the version numbers and breaking your extensions to do things like security or proper memory management.
This appears to require Javascript. Thank you, noscript.
Palm trees and 8
Convincing to who? to you?
ACM was quite convinced back in 2000 when they published the paper.
They obviously implemented it because it contains a lot of measurements.
Reality: Only a small number of users use NoScript et al. This is a problem for those that don't, and even if you do, what about when the site you want someone from requires JS?
-- Lattyware (www.lattyware.co.uk)
They say it can work without javascript, but I do not believe that. None of the samples work without javascript. In the paper, it says:
We omit the straightforward but tedious details of how to write HTML that causes popular browsers to make serialized accesses to files.
Can anyone provide this tedious, but allegedly straightforward, and extremely critical detail?
If it's a reputable site - my bank, my VOIP provider, even the main domain for youtube or something - sure, run the software. But random scripts from weird sites? You have to be a few cards short of a full deck to trust random shit from the internet. It's the damn *internet*. Anyone can do anything on it, so it only takes about three functional neurons to realize that you should use a bit of caution. Even if you don't get jacked, you'll get tracked!
This seems to work by loading well-known resources into an iframe and using a heuristic of the "time to load" to tell if it's cached or not. Hence, whether or not you have visited that site. I just scanned the source code, but this is what it looks like. It any case, it's not like this code reveals your history -- just whether or not your browser has visited one in a set of popular sites.
Yay stateless web.
There aint no pancake so thin it doesn't have two sides.
Subject says it all. I don't worry about cookies, cache, or malicious scripts (other than wastes-of-bandwidth) because every time I open FireFox, it looks shiny and new to the outside world.
When I visit a "sensitive" site, like my bank, I open a new browser session and close it when I finish. Aside from that, I just don't worry about it, and have never had a problem. Hell, even that great data-mining wizard Google - My home page and probably the single most frequent site I hit - Always defaults me to Georgia (presumably the location of my ISP's HQ), missing by over a thousand miles.
Tried the test for Opera, and it mostly worked (missed Newegg). Tried it in a private tab, didn't work at all. So, any site you don't want tracking you you load in a private tab. Which you should anyways.
Out of curiosity, I also tried the FF test (in Opera, still) and the IE test. The IE worked, better even than the dedicated test, while the FF test failed utterly. Curious.
And of course, as always, this test only works for the specific sites you test for, not generally. But that isn't surprising. Wasn't terribly fast, either, I'd certainly notice if you tested for hundreds or thousands of sites.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
It's a dutch boy's thumb, but that quick key-combo clears history in Opera. I just habitually hit it between domains to kill tracking without screwing up sites that need cookies or js to function. Likely there's a Firefox equivalent.
What neither has by default is a way to do this automatically. Browser makers finally got around to letting us limit cookies to the visited site, but they could go much further.
Like just rig browser cache to be per domain -- there's no need for all domains to share the same cache.
Maybe it's the festish for 'fastest' browser? It just seems the makers aren't doing what can be done easily enough on modest modern machines to improve privacy.
While this specific implementation is very inaccurate, others using a similar method may work. An obvious workaround to these kind of attacks is to turn off caching, but that would increase loading times. I was wondering if there was a hack in some browser that would allow you to ban a site from using resources from another domain, whether it's by HTML or scripts. Does anyone know such a solution?
That's because the test consists on downloading a file and measuring if it was instantaneous (cached) or not. Of course, the second time you run it, the script itself will have downloaded (and therefore put in cache) the same file, tricking itself.
Dilbert RSS feed
It seems like you could add a random delay of up to a couple hundred milliseconds before the browser reports that an iframe has successfully loaded, making it harder to tell by the timing.
Except that would make JavaScript slower, which is the exact opposite of what the browser makers are going for.
Cuz if they wanna sniff my browser history they are in for a surprise.
This kind of timing attack isn't easy to block.
Some kinds of timing attacks are. I think I heard once that a timing attack could be made against passwords in TOPS-20, because the passwords were stored in plaintext and compared one character at a time. The trick was to do the system call to check the password (or whatever it was) with the guess split across a page boundary (maybe the second page was forced out of memory or something). Since the system call would return as soon as one character didn't match, it was easy to see if the next character being guessed was correct or not. The fix was simple enough. Obviously there was a bit more to it than that, but I only heard this apocryphally as it was, and at that probably about 25 years ago.
This kind of thing is harder to fix, since it depends upon the difference between cache and non-cache access time, and the non-cached access time is not deterministic. It would be possible for the browser to introduce an artificial delay into the appropriate JavaScript calls, but that would make performance go down the tubes.
In any event, I tried it and the results didn't look very accurate (the first time, all of the sites it tried claimed that I had hit them; the secon time it caimed only one site was in cache, and after that it thought that nothing was).
Yes, it definitely would. You could certainly limit the scope to only apply to cross domain queries for out of viewport/small/hidden iframes, but that still might cause slowness issues for legitimate uses.
Java is considered such a security hole, and yet they sorted out this problem years ago. Java never could catch a break, geez.
Perhaps you are both right.
Let's start with the idea that NoScript by default is enabled.
Let's continue with the notion that application management should be as minimal as possible.
I give firewall software as a good example. If it is not easy to do one of the following, then the software (in my opinion, for me) fails:
1) Monitor all software incoming / outgoing. Block anything not on the whitelist, log connections, provide an interface in the *background* for the user to allow or deny in the future as Rules
2) Monitor all software incoming / outgoing. Allow all by default, log all connections, provide an interface for the user to allow or deny in the future as Rules
NoScript does most of this already. What it lacks is a reliable whitelist, similar to that used by Ghostery or AdBlock Plus, which loads the user up with 99% of the Rules they need.
I agree with your comment. For most users, you can whitelist all major bank sites - knowing that 99% of the time the sites are fine.
If the user disagrees then they can modify this setting.
Add onto that list a whole bunch of sites where the root site should be able to be trusted; news sites - slashdot, news.com, guardian, age, newspapers, etc.
Built onto that well known commerical sites.
Make this list auto-update once per month; but not to override user set preferences.
There you go. A tool very similar in nature to Adblock Plus and Ghostery which upon startup has a configuration to protect users and supply 99% of the functionality needed.
If this was the case, then I would put this on lots of people's PCs, knowing that if there are issues then they can be dealt with.
Although, at the moment, Ghostery + AdBlock Plus on Firefox provide most of the protection needed in a usable, safe and coherent manner.
You have a sick, twisted mind. Please subscribe me to your newsletter.
I ran this "test" three times in succession. First go it showed sites which yes I might have been to though one, Dogster I was fairly certain I had not. I then clicked it again and this time it came up with almost every site in green. Running a third time gave the same results as the first attempt.
But according to how this exploit works they are not "completely different". They, in fact, have a small overlap. Apparently the exploit works by using JavaScript to load a file from a website and see how fast it loads. It infers you have been to a website if the file loads quickly.
They seem to have a trick to stop the process just before the browser puts the loaded file into the cache which prevents it from poisoning the very cache it is "testing".
Thus, setting cache to 0, which the OP recommends, and which I have been doing for years, is exactly the fix needed. I admit that I do not know he also disables history, as that would not help with this exploit.
this signature has been removed due to a DMCA takedown notice
I'm using Linux and I'm trying the same thing that I do with Adobe Flash... I /dev/null it...
cd to .mozilla/firefox/xxxxxxx.default (replace x's with your specific alphanumeric string) /dev/null Cache (creates symlink of Cache to /dev/null)
rm -rf Cache (deletes Cache dir and all subfolders)
ln -s
Since nothing escapes the event horizon that is /dev/null, your Cache is written but cannot be inspected by others seeking to pry into your well-deserved privacy.
So far, so good. I have noticed no slowness by doing this.
By the way, you can do this with Adobe Flash to prevent your LSO/Super/Flash cookies from being farmed as well.
In your home dir, delete both the .adobe and .macromedia dirs. Some distros only have one or the other. Debian and variants have both.
rm -rf .adobe .macromedia /dev/null .adobe /dev/null .macromedia
ln -s
ln -s
Now you can experience the benefits of Flash without exposing yourself to privacy concerns.
Convenience comes at a price.
You can buy your bread and butter at the local grocery with all your neighbors watching.
Or you can disguise and go to the other end of town, which takes time and increases traffic.
It is meant to be non-destructive to the cache.
In other words, they don't actually download the files. They request the files to see if the browser starts parsing them within a certain time frame (indicating a cached document). Regardless, they abort the request after that time limit and the document is never cached.
If it did download the files as you suggest, the second and subsequent tests would always give the result that all sites had been visited. The OP and others on the page are reporting different behavior.
I'm seeing occassional transient false positives on Firefox and I'm not really certain how that can be the case.
Assuming the OP is seeing repeated false positives, I would guess he is behind a caching proxy that is caching aborted requests and, after repeated attempts, occassionally getting those documents to the browser faster than the tool can abort the request.
It seems to me there's an easy way to make browsers immune to this: Introduce random delays when cached resources are fetched from other sites via JavaScript.
In a well-designed web-page, the static (i.e. cached) resources are referenced in the html (often in the headers) and not subject to timing attacks as they can be fetched in random order.
When something is requested dynamically via JavaScript it is typically not the cache anyways, so there is rarely a performance penalty.
When there is a performance penalty, it is only on the order of a single http-request, even if a thousand resources are fetched from cache. (The random delay consumes no hardware resources, so the same number of requests can still be executed in parallel.)