773338 - history timing attack with href switching

Status: RESOLVED FIXED

(Firefox :: Security, defect)

Description

[Chris McGowen]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

Have anchor tag
1. Change anchor tag href to ""
2. Append anchor tag to document
3. Change anchor tag to correct href (ie: wikileaks.org)
4. Remove anchor tag from document
5. Go to 1


Actual results:

After recording the execution time, it is apparent that it takes significantly longer to perform this loop on visited URLs than non-visited ones.


Proof of Concept:
http://badcoding.net/test22_l4jjig4yunmmng127fj112/index.html

This bug is filed without the "security" option because it is already public.



Expected results:

It should take the same amount of execution time to switch visited hrefs as non-visited.

Comment 1

[Chris McGowen]

Any update on this?

Just checked:
Still valid on Firefox 26.0
Purple links (visited urls) generate longer delta values and can lead to browsing history discovery.

Comment 2

[Chris McGowen]

Attachment: test.html

The previous POC had a strange need to be clicked twice before showing a discernible difference in timing. I found that by adding a visited and then non visited link initially, this quirk was resolved.

Comment 3

[Jefferson]

Attachment: Screen capture, newer POC results, layout.css.visited_links_enabled toggled

The results are not so consistent on my Fx30 (Windows 7). I'm a little puzzled that toggling layout.css.visited_links_enabled to false doesn't equalize the times. That would seem to make a history check superfluous.

Comment 4

[Chris McGowen]

Attachment: POC_historyattack.html

Updated POC with higher iteration count and moved unnecessary work from timing loop.

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Fixed in Bug 1632765