HTML5 Storage Bug Can Fill Your Hard Drive 199
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."
So What's The Point (Score:2, Insightful)
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: (Score:2)
Imagine the network usage bill for your VPS trying to fill every hard drive of every device that visits your site.
Re:So What's The Point (Score:5, Interesting)
Re:So What's The Point (Score:5, Informative)
Re: (Score:3)
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
Re: (Score:2)
If you look at what he's saying, you'll see that the javascript only gets downloaded once for all the domains. For each domain you need an html page that just has a script link to the fixed js file (that your browser already has cached). So, think maybe 100 bytes per 5-10MB.
Re: (Score:2)
Add all the HTTP headers to your 100 bytes as well, along with the HTTP request too. The browser will be sending the referrer url, the user agent string, cache control headers, etc.
1k seems reasonable.
Re: (Score:3)
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: (Score:3)
Re: (Score:3)
Don't forget zip bombs, like 42.zip. Over 4 PB compressed down to 42k.
Re: (Score:2)
Imagine the network usage bill for your VPS ...
Imagine the profits for the HDD companies as people run out of space and order bigger and bigger disks. The HDD companies have the most obvious motive to exploit this bug.
Mobile devices? (Score:5, Insightful)
Re:So What's The Point (Score:5, Insightful)
Subdomains are free. With a wildcard DNS record, you have nearly an infinite supply of them.
much easier than you think (Score:3, Informative)
, 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
Re: (Score:2)
The DNS specifications state the max length of a domain name is 253. Assuming you could get the smallest possible root domain name of 4 characters (x.cc for example) that means you would have 249 characters left.
To complicate things a little more the specifications state each label (subdomain) can't exceed 63 characters. That means 3 full subdomains of 63 characters + 1 subdomain of 56 characters if you include the periods. Grand total of 245 characters to play with.
The specifications state that the only va
Re: (Score:3)
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
Re:So What's The Point (Score:5, Insightful)
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: (Score:2)
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.
But that would mean I'd have to agree that context carries as much information as the lexical meaning! How can I be an asshole on the Internet if I can't equivocate!
Re: (Score:2)
That's being foolish. A wildcard DNS entry will easily match more than hundreds of billions of domains. This is large enough that it's more than anybody could conceivably have a use for. The number of subdomains is in fact bounded, but actually even figuring out the limit is a mathematical exercise - not a practical concern.
Consider - you have more than 200 quadrillion plastic ballpit balls. This is large enough that you can't count them in more than a million years, even if you counted very, very quickly.
Re: (Score:2)
Well, the number of particles in the observable universe is finite.
So everything that is included in this universe is also finite, and everything I know and can imagine in our universe is pretty much finite.
Re: (Score:2)
Re: (Score:2)
Bandwidth is nearly nothing because I don't have to transfer any data to create data on the victim's drive if I use javascript.
Lastly, you're not thinking about threats holistically. This just becomes one single tool added to a group of other tools that can be employed in an advanced persistent threat attack.
Re:So What's The Point (Score:4, Interesting)
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: (Score:2)
Of course not. You will hack someone else's server and burn up their bandwidth.
Re:So What's The Point (Score:5, Informative)
Re:So What's The Point (Score:5, Informative)
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: (Score:2, Funny)
And those ads will be from Western Digital, Toshiba and Seagate.
Re: (Score:2)
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.
Call me crazy but I seem to think that this is part of the default configuration for out of the box BIND. You set up all your domains and then drop the wildcard in at the bottom to catch everything else?
Re: (Score:2, Funny)
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: (Score:2)
Re: (Score:2)
ServerAlias *.badguys.com
Re: (Score:2)
So THIS is how Mega is getting all their disk space....
Imagine:
Everyone who uses the site is a node that is getting filled up by other people's encrypted garbage.... Free space, redundant, encrypted, distributed, and can charge for it... Perfect.
Re: (Score:2)
Re: (Score:2)
Disable Javascript (Score:3, Insightful)
Also, you're not vulnerable if you have javascript enabled.
Such is life when your browser automatically downloads and runs arbitrary untrusted software.
Re: (Score:2)
I wonder how fast I can fill my harddisk... (Score:2, Funny)
This sounds like a nice weekend project, wonder how fast you can fill up a harddisk with just some javascript.
Re: (Score:3)
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:I wonder how fast I can fill my harddisk... (Score:5, Insightful)
You're assuming that you have to download the files. It's highly likely the data could be generated locally in JavaScript.
Re: (Score:2)
Of course it is, ha.
Re: (Score:2)
Support response (Score:2, Funny)
but couldn't do so for MSIE because 'the page is broken" (see http://connect.microsoft.com/IE [microsoft.com]). Oops
FUD! We haven't recieved a complaint yet.
Yours truely,
MS support.
Re: (Score:2)
It's a feature! (Score:4, Interesting)
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! (Score:4, Interesting)
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: (Score:3)
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: (Score:2)
There's probably a reason that, contrary to the implication in TFS, the actual Web Storage Candidate Recommendation:
Re: (Score:3)
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 bro
Re: (Score:2)
Another annoying Chromium Bug... (Score:2)
On Linux using the pepperflash plugins, lots & lots of zombie processes get created and aren't even killed after you exit the browser. When I noticed 5GB of memory usage on an empty desktop, I realized that Chromium is a pro-zombie browser.
Re: (Score:3)
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.
wordpress.com? (Score:2, Insightful)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Editing (Score:2)
A Stanford comp-sci student has found a serious bug in Chromium, Safari, Opera, and MSIE.
OK, so we're talking about Google, Apple, Opera and Microsoft. But then...
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.
Now we're talking about Google, Mozilla, Opera and Microsoft. Where did Mozilla come from, and where did Apple go?
Chrome, Safari, and IE currently do not implement any such "affiliated site" storage limit.' Firefox's implementation of HTML5 local storage is not vulnerable to this exploit.
Now we're talking about Google, Apple, Microsoft and Mozilla. Apple's back, and Opera is left out this time, and even though the author seemed to be indicating that Mozilla's browser was on the vulnerable list, now it's set apart.
Editors, if a summary is inconsistent, please clean it up or don't promote the story.
Re: (Score:2)
Where did Mozilla come from, and where did Apple go?
The first part was talking about bugs; the second was talking about storage limits. Mozilla has no bug but does have a storage limit. Apple presumably has the bug, but we don't know what its storage limit is.
Re: (Score:2)
And Opera loses mention later on entirely. Probably because the bug doesn't exist on the last few Opera stable versions at all:
http://www.ledow.org.uk/Opera.jpg [ledow.org.uk]
Opera? (Score:3)
I call crap on the Opera thing.
Latest stable Opera browser here, 12.14, updated 5th February:
http://www.ledow.org.uk/Opera.jpg [ledow.org.uk]
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: (Score:2)
What I have seen (Score:3)
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.
Re: (Score:2)
Is it also the application you use the most? And was that RAM actually in contention for other processes?
Plenty of ways to do it (Score:2)
Cautionary tale (Score:2)
And this is why software homogenization is bad. Webkit is becoming the new IE6 but has far greater consequences because every smartphone is using a webkit based browser by default. Yes it also affected IE and Opera but Opera cut their core developers and are moving to Webkit so soon there will only be 3 major engines with one of them having a complete monopoly on smartphones.
Re: (Score:2)
There are 3 or 4 smartphones out there using the Trident layout engine.
Re: (Score:2)
3 or 4 phones that nobody is buying. Android and IOS dominate the market and both use Webkit browsers.
Re: (Score:2)
You misread what I said. I said 3 or 4 phones, not 3 or 4 models of phones :)
Business opportunity (Score:2)
You should try my new HTML5-enabled cloud storage site. Unlimited cheap space, really fast uploads :)
standard is broken (Score:2)
So, where is the limit supposed to apply? To all subdomains of .com? To all subdomains of .au? How about my ISP who offers me FOO.power.on.net? Should every customer's website on power.on.net have to share the same space?
Poorly thought out standard is poor.
The browsers obviously didn't put a limit in for subdomains because it doesn't make sense. You have no idea where the organisational boundary is with regards to domain vs. subdomain.
C
Re: (Score:2)
Re:Bug, or exploit? (Score:5, Informative)
Read the spec: recommendation, not requirement (Score:5, Informative)
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 [ietf.org]), and its not the same as "must", instead:
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/ [example.com] and https://www.example.com/ [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: (Score:2)
"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.
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
Re:Read the spec: recommendation, not requirement (Score:5, Informative)
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.
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".
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: (Score:2)
You must be awful fun when talking to customers. They tend not to understand the distinction between "shall" and "should".
So are you saying that a fun systems engineer talking to a client will therefore land the client in legal hotwater? These kind of things should not be fun for exactly that reason. As a customer I would greatly appreciate if some of the vendors dispelled with the bullshit and clearly defined what should and what shall be done. Projects have a tendency to go much better when that happens and everyone leaves happy.
Re: (Score:2)
Re: (Score:2)
There are two errors in this statement:
Re: (Score:2)
I'd call that a design error. The browser is behaving as it is designed to, it's just that the way it's designed to behave is wrong.
Which is, in other words, a bug.
Why do people persist in believing that bugs can only happen in code?
Re: (Score:2)
A bug is unwanted, undesigned for response. As this was designed in the equipment, it's a design flaw, not a bug.
BTW, the world's first bug was a moth caught in a computers wiring, hence its name. The first bug was indeed a hardware error, a short circuit caused by the moth.
Re: (Score:2)
No, it wasn't. The term "bug" predates that (and computers) as a term for faults in electrical systems. The well-known moth that is the source of this myth was described in the notebook to which it was taped as the "first known instance of an actual bug being found", clearly indicating that computer "bugs" had existed before that time, but that the novel thing wasn't the term, but the fact than an actual arthropod was locate
Except that it isn't inconsistent with the spec (Score:2)
I think you need to review the relevant portion of the specification, particularly the use of the word "should" and the reference to RFC2119 for the specific definition of "should" that is applicable when used in the specification.
Re: (Score:2)
Re:Bug, or exploit? (Score:4, Insightful)
Re: (Score:2)
Well, except that if you actually read the specification, nothing raised in TFS involves doing something different than required by the specification, and, in fact, the relevant recommended-but-not-required functionality described in the specification isn't defined at all (there is no definition of "affiliated origin", and only one example given.). Its outside of the simplest naive generalization of the ex
Re: (Score:2)
I have a doctorate and spend more time bathing in a given week than on videogames.
Re: (Score:2)
I have a doctorate and spend more time bathing in a given week than on videogames.
I spend more time on videogames than on bathing, and I don't have a doctorate. Hmm... I wonder if there is some sort of correlation?
Re: (Score:2)
Are we done here? My coffee break ends soon.
Re: (Score:3)
I read the summary. The author of the summary, however, has not read the spec [w3.org], 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 ac
Re: (Score:2)
The lack of ability to determine whether or not bar.foo.com and baz.foo.com are affiliated with one another. They may be the same company, they may be entirely different organsiations. They should NOT therefore be forced to share the same storage quota.
The spec as TFA author is interpreting it is broken. In actual fact, the spec leaves this open as an implementation detail and
No evidence spec is not being followed. (Score:2)
The specification at issue is not a standard, its a Candidate Recommendation [w3.org]. Ikay, that's a technicality, but more importantly:
They are following it; both the per-origin quotas themselves and the controls regarding preventing use of affiliated origins to circumvent the quotas are recommendations (should), not a requirements (must), of the spec, so even if they were not implemented at all, the implementation could be following the spec completely.
Re: (Score:3)
Is this a thing? People get tribal about browsers?
Re: (Score:3)
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.
Re: (Score:2)
Yeah I'd say it's not vulnerable to a harddrive filling exploit.
Opera definitely has issues with site-compatibility - usually due to b
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Since the actual behavior of the recommended-but-not-required functionality to identify "affiliated" origins and prevent their use to circumvent the likewise recommended-but-not-required per-origin quotas is not actually specified in the Web Storage specification (particularly, the criteria for defining affiliated origins are never specified, all that is provided is one example of a set of incompletely-specified origins as an example of affi
Re: (Score:2)
Not only that, but on his other point, the memshrink project took off, Firefox has been using significantly less memory than other browsers.
On my system, for 5-10 tabs, Firefox uses about half as much memory as Chrome. For a large number of tabs, Chrome explodes to gigabytes of memory while Firefox doesn't go up by much at all.
Not to mention tab groups make organising that large number of tabs a lot easier.
https://blog.mozilla.org/nnethercote/category/memshrink/ [mozilla.org]
Re: (Score:2)
Re: (Score:2)