Slashdot Mirror
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."
Also, you're not vulnerable if you have javascript enabled.
Such is life when your browser automatically downloads and runs arbitrary untrusted software.
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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked
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.
Subdomains are free. With a wildcard DNS record, you have nearly an infinite supply of them.
If I have been able to see further than others, it is because I bought a pair of binoculars.
You're assuming that you have to download the files. It's highly likely the data could be generated locally in JavaScript.
I'd give my right arm to be ambidextrous...
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.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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).
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.
, 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.
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.
Ezekiel 23:20
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:
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
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.
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.
I am TheRaven on Soylent News