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."
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.
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?
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.
I've only gotten one internet virus in my life - via the "executable GIF" exploit, from visiting NVIDIA.COM !!!
If you think "reputable" means "safe", YOU'RE a few cards short of a full deck!
YES! I 2nd that! But it should be better integrated and off by default -- they can try to hint users into using it by other means. I have NoScript on by default just because I was sick of white listing everything; but any site I feel bad about I blacklist. Its not as secure but it is doing something. Add a subscription list like AdBlock has and it wouldn't be so bad for people who want to help compile black and white lists. Normal users would get a blacklist with it always on by default and others who know better will know enough to flip the policy. The paranoid would turn off the subscription lists and do it all themselves.
I would like a power-user area to block certain DOM features completely. I do not trust canvas by default or most the newer DOM features by default; it should ask me to ok those when a site tries to use them. (the lists mentioned above could specify what is white or black listed not just whole domains etc.) Actually, I'm wary of CSS3 fonts because font render engines haven't been a focus of security and 3D drivers... you are lucky to have stable fast 3D; security? currently a pipe dream.
A DOM js access list by domain would be a lot like a sandbox system for websites.
Democracy Now! - uncensored, anti-establishment news
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).
Completely different features; but not completely different datasets...
If I'm trying to infer where you've been, a nicely formatted(often with handy metadata, timestamps, etc.) history list sure is handy, if I can get access to it; but it's also an obviously juicy target, and something that browser designers are going to try to keep me away from.
Your cache is a lot messier; but it does provide grounds for inference about where you've been(and thus can retrieve from cache in essentially zero time) and where you haven't recently been(and thus have to burn a few tens to hundreds of milliseconds retrieving from a remote host)... Worse, unlike history(which is really just a convenience feature for the user, and can be totally frozen out of any remotely observable aspect of loading a page, those purple links aren't life or death...) the browser cache is an architectural feature that one cannot remove without sacrificing performance, and one cannot even easily obfuscate without sacrificing performance. It's a much lousier dataset than the history, since history is designed to document where you've been but cache only does that partially and incidentally; but it is one that is harder to get rid of without user-visible sacrifices and increases in network load...
You wouldn't need to eliminate the cache, just Javascript's ability to measure the load times reliably. For example, you could prevent scripts from reading the state of a particular resource during the e.g. 500 milliseconds after setting its URL, regardless of the source used (cache or network).
Dilbert RSS feed
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.
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.
I pay for my ISP's bandwidth. I have to pay a bill each month. Where is that you can get free ISP access? I pay indirectly for the pages from which I purchase items. Its part of the cost of them doing business.
Of course, if you are suggesting, for example, that the company providing the web page are paying unnecessarily bills because of the size of their web pages they should either improve the content of their web pages or give up on their web presence. The web pages are for the potential customers' benefit and if I find that they are full of flash, secondary advertising or other junk then I do not consider that a benefit. I don't think that I should be using a cache just to make their job easier.