VULNERABILITY DETAILS Not checking the domain from which to download the file to match the same domain from which the file was obtained earlier in the cache VERSION Chrome Version: [9.0.597.107] + [stable] Operating System: All REPRODUCTION CASE 1. Replace i.src property of attached HTML to page, whose presence in the cache you want to check 2. Clear cache. 3. Visit to page, whose presence in the cache you want to check. 4. Run attached HTML from anywhere. Track the time. 5. Clear cache. 6. Run attached HTML from anywhere. Compare the times. Especially well noticeable difference for large pages. Thus, a remote attacker can check the cache files.
Mar 4 2011,
Michal, isn't this of the general cross-browser unsolved info leaks, documented in the Browser Security Handbook?
Mar 5 2011,
Yes, "cache timing" and "general resource timing" in: http://code.google.com/p/browsersec/wiki/Part2#Privacy-related_side_channels I would be surprised if we want to fix it, especially given: http://test.w3.org/webperf/specs/NavigationTiming/
Mar 5 2011,
Thanks, Michal. Another reference, for the worst I've personally found with browser timing attacks, is: http://scarybeastsecurity.blogspot.com/2009/12/cross-domain-search-timing.html Careful use of incognito mode should help with both.
Mar 21 2011,
Oct 13 2012, Project Member
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 10 2013, Project Member
Mar 11 2013, Project Member
Mar 13 2013, Project Member
Nov 18 2013,
Bulk release of old security bug reports.
Feb 6 2014, Project Member
Bulk update: removing view restriction from closed bugs.
Oct 2 2016,
Aug 8 2017,
Issue 750998 has been merged into this issue.
Feb 27 2018,
Issue 817028 has been merged into this issue.
Issue 889598 has been merged into this issue.
Issue 911307 has been merged into this issue.
Sign in to add a comment