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.
I just tried, and it came up empty: nothing happened when I pushed the button.
I suspect this is YET ANOTHER case where it only works if you voluntarily run their software. And who, any more, is dumb enough to run random javascript from random web sites you don't trust? Whitelist the stuff you want, and leave the rest alone. Would you let random strangers into your house, too? No, you'd let your friends in, and not that drug gang down the street.
So, yeah, amazingly enough, if you run somebody's software on your machine, their software runs on your machine. Trivial fix: don't do that shit.
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!
What a load of crap this supposed new tool is. For one...I never go to Facebook, and rarely go to Youtube, and most certainly have never visited Ebay on this machine. I currently use Chrome over most, but have IE and FF installed in case for some reason I need to test a website's browser support. Not sure who the users are that give feedback saying the FF port of the tool for Chrome is working...but I suspect those users wouldn't know their hand from their ass in most cases.
Keywords for the NSA overthrow oppressive regime true believers marathon Manhatten the financial district blueprints I
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
By running the test repeatedly Chrome started showing pages I had never visited as being visited.
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?
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).
I just looked at the Home Depot sale paper, and they've got Mexicans on sale. Buy 1, get 18 free.
You are welcome on my lawn.
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
makes me proud to be polish
That's not just that. What about an img tag for example? With JavaScript, you can query the position of the elements below the img (unrelated to the img itself). When they've been pushed down, you know the image has loaded, without actually ever dealing with the particular img tag.
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.
i do not use facebook and yet got a positive score on it. Most likely its scripts really do litter around.
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.)