642264 - Content can fill places.db with spurious history entries and generate significant disk IO by rapidly modifying window.location.hash

Status: NEW

(Toolkit :: Places, defect, P5)

Description

[Katelyn Gadd (:kael)]

I ran across a blog post (URL above) that describes how window.location.hash can be modified repeatedly to break the back button in the browser. This alone is a UX issue, but I noticed that it generates a significant amount of disk traffic and creates a history entry in places.db for every individual hash value. I suspect this could be used to fill an end user's hard disk, make the system relatively unresponsive (due to the disk traffic), and at the very least make using their Firefox profile an unpleasant experience.

You could probably do the same thing using regular URLs and redirects, but in that case the amount of latency involved in loading pages means that it would take a lot longer to fill the disk and it would be more difficult to saturate the machine with IO. Doing this with regular page loads also would show page loading indicators, making it clear to the end user that something was happening so they could kill it by closing the tab. In this case, an end user might not even notice what was happening.

I don't know how this would be fixed, precisely - perhaps rate-limiting the creation of artificial history entries would be enough.

Comment 1

[Katelyn Gadd (:kael)]

Attachment: The proof of concept from the referenced blog post (WARNING: Will generate a bunch of disk I/O for a few moments and possibly hang your browser)

Attaching the proof of concept from the referenced blog post. Note: It'll probably saturate your machine with disk I/O for a few minutes or hang the browser.

Comment 2

[Justin Lebar (not reading bugmail)]

I think content can do something similar (or same) by calling history.pushstate repeatedly.

Comment 3

[Justin Lebar (not reading bugmail)]

Testcase in bug 639952 generates a similar sequence of IOs to this testcase.  At least, the IO pattern sounds the same to my ear.  :)

Comment 4

[Justin Lebar (not reading bugmail)]

I don't think this is particularly dangerous (this isn't a silent attack on the hardware -- users will likely *hear* their hdd going crazy), and we already have bug 639952, which is a similar issue, so I'd be OK un-hiding this bug.

(I don't think this should be duped to bug 639952, since that's about filling up the history and this is about thrashing the hard disk; we might be able to fix one without fixing the other.)

Comment 5

[Boris Zbarsky [:bzbarsky]]

> users will likely *hear* their hdd going crazy

Except those users who have an SSD or flash storage on a tablet or phone... ;)

Comment 6

[Justin Lebar (not reading bugmail)]

> Except those users who have an SSD or flash storage on a tablet or phone... ;)

Sure, but that's not quite as bad, is it?  I guess it could wear out the cells, but I'd hope the flash drive would have caching to keep this kind of thrashing from wearing out the device...