HTML5 Storage Bug Can Fill Your Hard Drive

Dystopian Rebel writes "A Stanford comp-sci student has found a serious bug in Chromium, Safari, Opera, and MSIE. Feross Aboukhadijeh has demonstrated that these browsers allow unbounded local storage. 'The HTML5 Web Storage standard was developed to allow sites to store larger amounts of data (like 5-10 MB) than was previously allowed by cookies (like 4KB). ... The current limits are: 2.5 MB per origin in Google Chrome, 5 MB per origin in Mozilla Firefox and Opera, 10 MB per origin in Internet Explorer. However, what if we get clever and make lots of subdomains like 1.filldisk.com, 2.filldisk.com, 3.filldisk.com, and so on? Should each subdomain get 5MB of space? The standard says no. ... However, Chrome, Safari, and IE currently do not implement any such "affiliated site" storage limit.' Aboukhadijeh has logged the bug with Chromium and Apple, but couldn't do so for MSIE because 'the page is broken" (see http://connect.microsoft.com/IE). Oops. Firefox's implementation of HTML5 local storage is not vulnerable to this exploit."

Comments

So What's The Point

[Anonymous Coward]

This seems like mental masturbation to me. I see no point in initiating such an "attack".

If I understand correctly, you are going to expend great effort and possibly money on tens of thousands of subdomains, transfer a lot of data and incur bandwidth charges, in order to fill someone's hard drive? This is about the lamest DoS attack I have ever heard of. And the easy fix is to simply clear cookies?

Come on, this is a non-issue looking to be a problem.

Re:So What's The Point

[Qzukk]

Subdomains are free. With a wildcard DNS record, you have nearly an infinite supply of them.

Re:So What's The Point

[The Mighty Buzzard]

Really? You've never admin'd a dns server then. It's trivial to have one respond to wildcard subdomain names that you could generate dynamically on page load with one line of javascript.

Re:So What's The Point

[bill_mcgonigle]

If you have a popular blog, there's no need to pay for network backup anymore - just drop enough 5MB blocks encrypted and with decent FEC to each of your readers. If you ever have a failure, just throw up a basic page with a funny cat picture and start restoring from your distributed backup.

Re:So What's The Point

[arth1]

It doesn't take much work or time to set up a wildcard CNAME entry pointing to a single web server that answers a wildcard. You now have billions of subdomains with a couple of minutes of work.
The web instance serves a short javascript which generates a boatload of data on the client side, and then calls a random subdomain to reload the js with a new domain name.

All this can be linked to a single ad (or blog comment, for vulnerable boards that allow css exploits).

Re:So What's The Point

[thetoadwarrior]

It's a web app, let the client generate it. You generate the free sub domains with a script or something a bit more intelligent but either way the cost should be minimal. I assume as well you wouldn't necessarily need to fill it completely. A gig or two might ruin the browser's performance.

Re:So What's The Point

[Jiro]

That's not true.

"Nearly infinite" means "it's not infinite, but it's large enough that it has most of the same practical effects as it would if it were infinite".

You seem to be interpreting the word "nearly" to mean "has a numerical value close to" rather than "has effects similar to". Obviously it is nonsensical for something to be nearly infinite using that first definition, but that should be a warning sign that you're not using the definition that people mean, not that everyone else is speaking nonsense.

Re:So What's The Point

[TheRaven64]

You misunderstand how the attack works. The client-side code is allowed to store 5-10MB per domain, but it can generate this data (math.random() will do it fine). The per-domain thing mean that you need one HTTP request per 5-10MB, but on the server that will be a wildcard DNS entry always resolving to the same server. If you set the cache headers with a sufficiently long timeout, then you can probably have a single site hosting the .js (so the browser will only request it once) and then just send a tiny HTML page referencing it. The JavaScript then creates a new iframe with a new (random) subdomain as the target, and so you each HTTP request to your server (total of about 1KB of traffic) generates 5-10MB of data on the client's hard disk.

Re:So What's The Point

[geekboybt]

What if the data I stored was a string of "0" characters and the transfer was gz'd? That would shrink it quite drastically.

Re:So What's The Point

[Culture20]

Reminds me of the gif of death, a blank PB sized image LZW compressed. It would crash browsers back in the day. Today it would probably wreak havok with thumbnail file managers.

Re:So What's The Point

[geekboybt]

Don't forget zip bombs, like 42.zip. Over 4 PB compressed down to 42k.

Re:So What's The Point

[viperidaenz]

So 1k per 10MB. That's a 10,000x multiplier.

Say I have 1TB free space. Before I run out of disk, it'll take 100MB of data, I'd be waiting for my browser to write out 1TB of data and there will be 100,000 HTTP requests made. 100,000 IFrame's... Browser probably crashed after a few hundred.

I think I'd close my browser because it stopped responding before I get anywhere near running out of space. At 100MB/s (average spinny disk sequential write speed. I doubt Javascript could keep up generating data with that though) it'd take nearly 3 days to write out 1TB.

Re:So What's The Point

[Anonymous Coward]

And the impact to the victim? Not really a big problem.

Assume this happens to a typical Microsoft Surface user.

How long will it take, and what is the consequence? What will they need to do to recover?

Re:So What's The Point

[KiloByte]

1.955e393, actually.

You made three mistakes:
* placing dots differently can give quite a lot of combinations
* you can have subdomains shorter than the max, this effectively adds dots to the character set, with two restrictions: no two dots in a row/start/end, no string of >63 non-dots. The former reduces the base by a small but noticeable bit, the latter has only infinitessimal (colloquial sense) effect.
* DNS names are case-insensitive

Disable Javascript

[Anonymous Coward]

Also, you're not vulnerable if you have javascript enabled.

Such is life when your browser automatically downloads and runs arbitrary untrusted software.

Re:Disable Javascript

[DarkRat]

so if I disable JS, I shouldn't go to that site?

Support response

[Anonymous Coward]

but couldn't do so for MSIE because 'the page is broken" (see http://connect.microsoft.com/IE). Oops

FUD! We haven't recieved a complaint yet.

Yours truely,
MS support.

It's a feature!

[sootman]

1.porn.com, 2.porn.com, 3.porn.com...

Actually, that could be handy -- you could store lots of music from song.album.artist.someMP3site.com.

Re:It's a feature!

[sootman]

Come to think of it, it could lead to problems. What if you read a lot of blogs hosted on wordpress.com? Or use many apps on *.google.com?

Re:It's a feature!

[fatphil]

Of course, you highlight another potential DOS - in the scenario you mention, one site can reduce the quota available to another subdomain, as they share it. It's a lose-lose situation: permit DOSing the user, or permit DOSing other sites on the same 2LD.

Let's hope they understand how CCTLDs are organised. I don't like the idea of every site under *.co.uk sharing the same 5MB. When they specified cookies, they fucked up, I dont trust them to have learnt from their mistakes and got HTML5 correct, far from it.

Re:It's a feature!

[TheRaven64]

There's an interesting paper by the Chrome guys from a couple of years back trying to define exactly what a web application is. A modern browser is trying to be an OS, and one of the fundamental tasks of an OS is isolating applications from each other. This is relatively difficult, as two applications may exchange files or use the same libraries, but at least they are launched as different processes. A web application is a tangle of resources from a variety of different domains running in one or more browser windows, each of which may contain things from an overlapping set of servers that are not part of the application. Any serious attempt at isolation is doomed to fail.

One of the nice things about Java and Flash applets is that they provide a cleaner mechanism for saying 'this is part of the applet, but these other things aren't', although with the DOM APIs that these expose even that is quite flexible.

Re:I wonder how fast I can fill my harddisk...

[Sockatume]

Assuming 500GB free space and a 20Mbps ADSL connection, call it 2MB/s down... I make it almost three days.

I think you would notice.

Re:Bug, or exploit?

[DarkRat]

no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked

Re:Opera is not vulnerable

[Sockatume]

Is this a thing? People get tribal about browsers?

Mobile devices?

[dclozier]

Devices with smaller drives like a cell phone, tablet or laptops like Google's Pixel would be more vulnerable. Perhaps if you created some javascript that simply made requests to iterated subdomains that simply returned a small amount of javascript that then generated large amounts of text to store locally? The bandwidth needed would be much less then and the same amount of damage done. I have no idea if this scenario is possible though so take this with a grain of salt.

Re:Another annoying Chromium Bug...

[The MAZZTer]

Chrome will remain running if you have apps installed that want to run in the background. There is an option in Settings to suppress this behavior. On Windows Chrome keeps a notification icon showing so you can shut down the browser and force these background apps to quit. Other platforms probably have something similar.

Chrome also keeps a process running for Cloud Print, if you have it enabled.

The 5GB is probably a badly-behaving app/extension. Check Chrome's Task Manager to figure out which one.

Re:I wonder how fast I can fill my harddisk...

[claar]

You're assuming that you have to download the files. It's highly likely the data could be generated locally in JavaScript.

Re:wordpress.com?

[malignant_minded]

Let me clarify as I thought it was clear but apparently not, isn't everyone that uses wordpress.com to host a blog using a subdomain of wordpress.com? If that is true doesn't that make this standard a little difficult to follow.

much easier than you think

[Anonymous Coward]

, transfer a lot of data and incur bandwidth charges,

Posting anonymously since this shows how it could be done.

I don't see any need to transfer data. Simply generate random strings programatically. One could easily write a few lines of code. The storage API is a 'key' and 'value' system, so just randomly generate keys and randomly generate values in a loop. Super easy. For the subdomain stuff, like others have said, wildcard for DNS. Then just serve the small js file that runs, then programtically generates a new random subdomain to dynamically load the js file.

The end point is that you don't need a lot of data bandwidth to screw up someone's computer.

Re:Bug, or exploit?

[K. S. Kyosuke]

Except that the specification is perfectly fine, it's the implementation that does something different. Or do you claim that the HTML5 spec is wrong when it says that browsers should not allow for this DoS attack to happen? Stop being a dick and admit your mistake.

Read the spec: recommendation, not requirement

[DragonWriter]

no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked

Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W

Re:Read the spec: recommendation, not requirement

[DragonWriter]

You must be awful fun when talking to customers. They tend not to understand the distinction between "shall" and "should".

There is a reason why internet specifications (whether or not they are from IETF, and often whether or not they are even intended as standards-track) reference the RFC2119 definitions. "MUST" vs. "SHOULD" is an important distinction.

In this particular case, whats even more important is that the recommended functionality at issue isn't defined at all, there is just one example -- and the example doesn't fully specify the origins, so its an incomplete example -- given and no definition of the parameters of the identification of "affiliated origins". So if it was a "MUST", it would be a broken standard (since it would be impossible to assess conformance), and as it is, its impossible to say whether a particular implementation even implements the recommended functionality.

"there may exist valid reasons in particular circumstances to ignore a particular item" - in other words, this is a case where the feature should ALWAYS be applied to generic software because that must deal with all circumstances, not just "particular" ones

Any particular user agent is a "particular circumstance" (it is specific software with a specific use case within the scope of all possible kinds of user agents which might implement the Web Storage API); there is no such thing as an implementation that must deal with "all circumstances".

It really should not be hard to have a popup that says "This web page wants to create local storage on your computer allow/disallow"

Its not at all hard, but that's not related to the recommendation to implement per-origin quotas, or the further recommendation to build on top of the per-origin quotas functionality to detect and limit the use of "affiliated origins" to circumvent the per origin quotas, which is what is at issue here. Per-origin allow/disallow for Web Storage use isn't even a recommendation of the specification. (Though it is explicitly permitted behavior.)

Re:Bug, or exploit?

[DragonWriter]

It's not intended behavior being exploited. Did you even read the summary?

I read the summary. The author of the summary, however, has not read the spec, or, if they have, has failed to understand all of the following (a) that both the use of per-origin quotas is a recommendation, not a requirement, of the spec; (2) that the use of controls to prevent the use of affiliated origins to circumvent the recommended per-origin quotas are also recommendations, not requirements, of the spec, and (3) that the spec actually doesn't define what constitutes an affiliated origin, so that even if per-origin quotas and affiliated-origin identification-and-blocking were required by the spec, it would be impossible to judge whether any particular implementation complied with the requirement.

If they understood any of those points, they wouldn't describe this as a "bug".

Re:Opera is not vulnerable

[Baloroth]

Is this a thing? People get tribal about browsers?

Well, he could just be annoyed about the summary being blatantly wrong, since it specifically says that the bug exists in Opera when, in fact, it does not.

But yeah, people can be a bit competitive about their favorite browser. Not as bad as emacs vs. vi or anything, but it does happen a bit.

Opera?

[ledow]

I call crap on the Opera thing.

Latest stable Opera browser here, 12.14, updated 5th February:

http://www.ledow.org.uk/Opera.jpg

No mention of this in the 12.14 release notes (even as a "vulnerability with details to follow later", which is common practice for Opera changelogs), and silence on the article about exactly how/why/where Opera is vulnerable.

If something pops up a million times and asks you for a Gigabyte and you click yes, then that's perfectly accepted user permission to do so.

Re:Awesome for FireFox!

[gman003]

Erm, you got it backwards. Firefox implements the standard properly, and is thus not vulnerable to disc-filling attacks of this sort. It's every other browser that is vulnerable.

What I have seen

[azav]

I've seen Safari taking up to 8 GB of RAM. This seems due to sloppy variable clearing and this makes the swap file larger and can easily end up taking over your HD.

Safari ends up being the biggest bloated pig with regards to RAM management on my Mac.