or Connect
AppleInsider › Forums › General › General Discussion › HTML 5 bug allows huge data dumps on most Mac and PC Web browsers
New Posts  All Forums:Forum Nav:

HTML 5 bug allows huge data dumps on most Mac and PC Web browsers

post #1 of 46
Thread Starter 
A recently discovered flaw in the HTML 5 coding language could allow websites to bombard users with gigabytes of junk data, with a number of popular browsers being open to the vulnerability.

According to developer Feross Aboukhadijeh, who uncovered the bug this week, data dumps can be performed on most major Web browsers, including Apple's Safari, Google's Chrome, Microsoft's Internet Explorer and Opera, the BBC reported. The only browser to stop data dump tests was Mozilla's Firefox, which capped storage at 5MB.


Exploit proof of concept video. | Source: Feross Aboukhadijeh


The problem is rooted in how HTML 5 handles local data storage. While each browser has different storage parameters, many of which support user-definable limits, all provide for at least 2.5 megabytes of data to be stored on a user's computer.

Aboukhadijeh discovered a loophole that bypasses the imposed data cap by creating numerous temporary websites that are linked a user-visited site. Because most browsers don't account for the contingency, the secondary sites were allowed local storage provisions in amounts equal to the primary site's limit. By generating a multitude of linked websites, the bug can dump enormous amounts of data onto affected computers.

In testing the flaw, Aboukhadijeh was able to dump 1GB of data every 16 seconds on his SSD-equipped MacBook Pro with Retina display. He noted that 32-bit browsers like Chrome may crash before a disk is filled.

"Cleverly coded websites have effectively unlimited storage space on visitor's computers," Aboukhadijeh wrote in a blogpost.

The developer has released code to exploit the bug and has created a dedicated website called Filldisk to highlight the flaw. In true internet meme fashion, the site dumps images of cats on to an affected machine's hard drive.

Bug reports have already been sent to makers of the affected Web browsers, and Aboukhadijeh said malicious use of his code has yet to been seen in the wild.
post #2 of 46

Watch Adobe play this up big time.

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply
post #3 of 46
Quote:
Originally Posted by AppleInsider 
The developer has released code to exploit the bug and has created a dedicated website called Filldisk to highlight the flaw. In true internet meme fashion, the site dumps images of cats on to an affected machine's hard drive.

Bug reports have already been sent to makers of the affected Web browsers, and Aboukhadijeh said malicious use of his code has yet to been seen in the wild.

Nice of him to release this to the public before any of the browser developers can fix it.
post #4 of 46
I like how it emphasizes his "his SSD-equipped MacBook Pro with Retina display". Whether or not he has an SSD or what kind of display is completely irrelevant to the bug. I have one of those machines also, but I'm not talking to people like "hey, can you shoot me an email to my SSD-equipped MacBook Pro with Retina display, BTO with extra features btw, sitting on an expensive table in my spacious 5th Avenue apartment, in front of the Van Gogh?".

There are also no retina MBPs without an SSD.
post #5 of 46

i must know the name of that song on the video!

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #6 of 46
I can haz fill disk?

Sent from my iPhone Simulator

Reply

Sent from my iPhone Simulator

Reply
post #7 of 46
Quote:
Originally Posted by UncleOwn View Post

I like how it emphasizes his "his SSD-equipped MacBook Pro with Retina display". Whether or not he has an SSD or what kind of display is completely irrelevant to the bug. I have one of those machines also, but I'm not talking to people like "hey, can you shoot me an email to my SSD-equipped MacBook Pro with Retina display, BTO with extra features btw, sitting on an expensive table in my spacious 5th Avenue apartment, in front of the Van Gogh?".

There are also no retina MBPs without an SSD.

 

It's just another embarrassment for Apple. Time for Tim Cook to step down! /s

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #8 of 46
There is a well-known (to developers) feature of HTML5 that is designed to allow web applications to store data locally; it can be used for storing parts of the app (so you don't have to re-download them later), catalog data, big images -- whatever you want. Every browser has controls allowing you to delete this data.

The fact that it performs exactly that function is hardly a bug. It's arguable that various (among different browsers) built-in size limits should be domain-specific rather than host-specific, but this is really not a particularly earth-shattering distinction; using additional domains to get access to more storage space doesn't require much more "cleverness" than using additional hostnames.

I don't know whether Aboukhadijeh is an attention whore, or whether click-craving sites are so desperate for traffic that they'll post whatever sensational-sounding "security" story they come across, regardless of whether they have the slightest idea what it means. It's sensationalist nonsense, either way.
post #9 of 46
So this video allegedly proves it can be done with Chrome

What about the other browsers. Where is the proof for those

And what is the super huge issue. Is there some flaw that lets websites dump data into our computers and then come back and retrieve it, or possibly something else off our computers. Or is this just cached data that we can dump out like all other caches, ending the whole thing and the browser crashing. That is until a point update in the affected and allegedly affected browsers kills the issue.
post #10 of 46

Apple better block Safari and Chrome now....They block everything else for their users. 

Mac Mini (Mid 2011) 2.5 GHz Core i5
120 GB SSD/500 GB HD/8 GB RAM
AMD Radeon HD 6630M 256 MB

Reply

Mac Mini (Mid 2011) 2.5 GHz Core i5
120 GB SSD/500 GB HD/8 GB RAM
AMD Radeon HD 6630M 256 MB

Reply
post #11 of 46
Quote:
Originally Posted by UncleOwn View Post

I like how it emphasizes his "his SSD-equipped MacBook Pro with Retina display". Whether or not he has an SSD or what kind of display is completely irrelevant to the bug. I have one of those machines also, but I'm not talking to people like "hey, can you shoot me an email to my SSD-equipped MacBook Pro with Retina display, BTO with extra features btw, sitting on an expensive table in my spacious 5th Avenue apartment, in front of the Van Gogh?".

There are also no retina MBPs without an SSD.

I think this was mentioned to demonstrate how fast the data dumped to the drive.  1GB in 16secs

Apple increments product features one bite at a time...hence the logo. Want the next big thing? You're gonna have to pick another fruit from the Apple Tree.

Reply

Apple increments product features one bite at a time...hence the logo. Want the next big thing? You're gonna have to pick another fruit from the Apple Tree.

Reply
post #12 of 46
Originally Posted by macxpress View Post
They block everything else for their users. 

 

The implication being that you want unsafe plugins destroying your personal data, forcing Apple to be liable for something they're not.

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply
post #13 of 46
Quote:
Originally Posted by Suddenly Newton View Post

i must know the name of that song on the video!

Shazam is amazing.

Trololo by Eduard Khil
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #14 of 46
Quote:
Originally Posted by JBlongz View Post

Quote:
Originally Posted by UncleOwn View Post

I like how it emphasizes his "his SSD-equipped MacBook Pro with Retina display". Whether or not he has an SSD or what kind of display is completely irrelevant to the bug. I have one of those machines also, but I'm not talking to people like "hey, can you shoot me an email to my SSD-equipped MacBook Pro with Retina display, BTO with extra features btw, sitting on an expensive table in my spacious 5th Avenue apartment, in front of the Van Gogh?".

There are also no retina MBPs without an SSD.

I think this was mentioned to demonstrate how fast the data dumped to the drive.  1GB in 16secs

How do you figure since regular hard drives can write data at around 3GB/s?

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #15 of 46
Quote:
Originally Posted by Marvin View Post

Quote:
Originally Posted by AppleInsider 
The developer has released code to exploit the bug and has created a dedicated website called Filldisk to highlight the flaw. In true internet meme fashion, the site dumps images of cats on to an affected machine's hard drive.

Bug reports have already been sent to makers of the affected Web browsers, and Aboukhadijeh said malicious use of his code has yet to been seen in the wild.

Nice of him to release this to the public before any of the browser developers can fix it.

Why shouldn't he want -- indeed, deserve -- his fifteen minutes of fame?

You'd think that the supposedly smart smart people in these gazillion-billion dollar corporations would not leave something so seemingly stupidly vulnerable in something as basic and ubiquitous as a browser.

Hooray for little Firefox.....
post #16 of 46
Quote:
Originally Posted by Tallest Skil View Post

Watch Adobe play this up big time.

Why? 

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #17 of 46
Quote:
Originally Posted by ciparis View Post

There is a well-known (to developers) feature of HTML5 ...
Every browser has controls allowing you to delete this data.  ...
I don't know whether Aboukhadijeh is an attention whore, or whether click-craving sites are so desperate for traffic that they'll post whatever sensational-sounding "security" story they come across, regardless of whether they have the slightest idea what it means. It's sensationalist nonsense, either way.

 

This.  The situation is known to HTML5 developers.  The W3C also has a spec to prevent it, which just hasn't been implemented outside of Firefox yet.

 

As for implementation, you could also change just the port number, and HTML5 gives you another storage space set as well.

 

Quote:
Originally Posted by charlituna
And what is the super huge issue. Is there some flaw that lets websites dump data into our computers and then come back and retrieve it, or possibly something else off our computers.

 

They can't steal anything.  This is just about filling up the hard drive with HTML5 storage, after which you can go to the options on any browser and delete it manually.

 

Hmm.  So another thing that should be implemented in browsers to prevent this, might be a setting for max portion of hard drive to allocate for localstorage, just like they do for web page caching.

post #18 of 46
Quote:
Originally Posted by mstone View Post

How do you figure since regular hard drives can write data at around 3GB/s?

Please tell me where you get your 3 GB/s Hard drives I really want one!
Use duckduckgo.com with Safari, not Google Search
Been using Apples since 1978 and Macs since 1984
Long on AAPL so biased. Strong advocate for separation of technology and politics on AI.
Reply
Use duckduckgo.com with Safari, not Google Search
Been using Apples since 1978 and Macs since 1984
Long on AAPL so biased. Strong advocate for separation of technology and politics on AI.
Reply
post #19 of 46
``The problem is rooted in how HTML 5 handles local data storage.''

FYI: Local Data Storage implementations are just in the early stages of being ready to role outside of nightly builds for WebKit and/or Mozilla, not to mention IE.

These boundary conditions will be put in place.

Making this an AI fluff piece is pathetic.
post #20 of 46
Quote:
Originally Posted by digitalclips View Post

Quote:
Originally Posted by mstone View Post

How do you figure since regular hard drives can write data at around 3GB/s?

Please tell me where you get your 3 GB/s Hard drives I really want one!

Sorry that should be Gbits not bytes and as I just looked it up, 3Gb is the theoretical maximum write speed for SATA II so practically speaking it would be quite a bit less however it could be pointed out that even at the easily attainable 150 MB per second, the HDD is still plenty fast enough to write 1GB in a lot less than 16 seconds so the specification of SSD mentioned in the article is still irrelevant. 

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #21 of 46
Quote:
Originally Posted by Tallest Skil View Post

Watch Adobe play this up big time.

 

Flash has web site storage.  The problem, as described, would very likely exist in Flash's own storage engine.  

 

 

Mozilla, on the other hand, has every right to brag and play this up. I do not think Mozilla will though.  

post #22 of 46
Quote:
Originally Posted by rednival View Post

 

Flash has web site storage.  The problem, as described, would very likely exist in Flash's own storage engine.  

 

To my knowledge there has never been an exploit of Flash's local storage. Adobe has designed it with very strict controls and is limited to 100 kilobytes by default. In order to enable local storage in Flash the user has to specifically allow it in the settings and specify the the size limit.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #23 of 46
Quote:
Originally Posted by UncleOwn View Post

I like how it emphasizes his "his SSD-equipped MacBook Pro with Retina display". Whether or not he has an SSD or what kind of display is completely irrelevant to the bug. I have one of those machines also, but I'm not talking to people like "hey, can you shoot me an email to my SSD-equipped MacBook Pro with Retina display, BTO with extra features btw, sitting on an expensive table in my spacious 5th Avenue apartment, in front of the Van Gogh?".

There are also no retina MBPs without an SSD.

 

 

You're correct about the Retina display.  The SSD is another story, though the issue would not be limited to Macs.  

 

Writing occurs much faster with SSD and the maximum storage is usually much lower. If something were writing huge amounts of data to your HDD, you would be more likely to detect the heat, sound or vibration.  It would also take longer for the exploit to fill your drive due to the slower writing speed and the increased storage capacity.

 

The results would vary greatly on a HDD, so specifying the experiment involved a SSD was fair.  Mentioning the Retina Display, or even the fact that a Mac the test was done on a Mac, seems ridiculous.  It feels like a cheap shot.  The monitor and brand of computer did not impacted the outcome or results.  The type of drive used would.

post #24 of 46
Quote:
Originally Posted by mstone View Post

To my knowledge there has never been an exploit of Flash's local storage. Adobe has designed it with very strict controls and is limited to 100 kilobytes by default. In order to enable local storage in Flash the user has to specifically allow it in the settings and specify the the size limit.

 

It was unfair for me to assume Flash would be affected, that I will admit.  Flash was not mentioned.  

 

I knew you had to enable local storage for Flash, but did not know about the the strict size limits.  I don't see the setting to limit size in my system preferences.  When I add a site, a size limit does not show up there.  It isn't obvious the limits you describe exists.  I am not saying you're wrong, but pointing out there's a good reason I did not know about them.  

 

The main point is that Flash has local storage, so it COULD be vulnerable.  You gave a good reason why it might not be, but it sounds like working around restrictions is how the whole exploit works.  


Edited by rednival - 3/3/13 at 9:19pm
post #25 of 46
Quote:
Originally Posted by mdriftmeyer View Post

``The problem is rooted in how HTML 5 handles local data storage.''

FYI: Local Data Storage implementations are just in the early stages of being ready to role outside of nightly builds for WebKit and/or Mozilla, not to mention IE.

These boundary conditions will be put in place.

Making this an AI fluff piece is pathetic.

I don't think early stages is as early as you believe, local storage is well beyond nightly builds and is well implemented across sites like Google and Facebook. And even if you are forced to rely on it, there are applicable substitute to fall back on. But I'd certainly agree. Overall I'd say that this bug is rudimentary at best. Other than being a clutch to cause confusion and annoyance it's not something I'd be too concerned about.
post #26 of 46
This is actually nothing new.

A malicious site, could use it to store junk on a user's machine. Most sites don't even make use of the feature to begin with. Still obsessing over 4KB cookies.

The real danger here comes from the fact that the browsers are still 32-bit and can thus be crashed, leading to other exploits. It would be nice to set some ground rules for storage (particularly tablet's and smartphones) where the storage is disabled by default, and the user is not prompted to allow the site to enable it until some action that requires enabling storage is performed.

"This website is asking for (additional) 2MB of diskspace
(o)refuse all storage requests from this page
or allow all requests for this:
(o)domain
( )site
(^) show me what is being stored"
post #27 of 46
Super misleading title on this article, I'd say.
post #28 of 46

I'm not sure if this relates exactly, but there's a "Local Storage" folder at   ~/Library/Safari/LocalStorage. I long ago emptied and locked that folder, so nothing can be stored there.

post #29 of 46
Quote:
Originally Posted by Nobodyy View Post


I don't think early stages is as early as you believe, local storage is well beyond nightly builds and is well implemented across sites like Google and Facebook. And even if you are forced to rely on it, there are applicable substitute to fall back on. But I'd certainly agree. Overall I'd say that this bug is rudimentary at best. Other than being a clutch to cause confusion and annoyance it's not something I'd be too concerned about.

 

https://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/ExtensionSettings/ExtensionSettings.html

 

 

Quote:

Settings and Local Storage

You can define settings for your extension using Extension Builder. You can choose a type of user interface—such as a checkbox, radio button, text field, or slider—and a default value for each setting. You can choose to make any setting secure (encrypted).

 

The settings you define appear in your extension’s preference pane, in Safari preferences. Safari handles the user interface, stores the values, and notifies you when a value changes.

 

There is also an API for accessing your settings programmatically. The API provides for both normal and secure (encrypted) settings. The API is similar to the HTML5 local storage API, but the settings API has an additional feature: support for default values.

 

You can also make use of HTML5 client-side data storage, commonly referred to as local storage. You can use both Safari settings and HTML5 local storage if you like.

 

Using HTML5 Local Storage

Safari provides full support for HTML5 client-side storage, both simple local storage of key-value pairs, and the client-side database API that allows you to create persistent relational databases on the client machine.

 

When used from an injected script, the domain of the local storage is the domain of the webpage the script is injected into. In other words, local data is stored with the webpage’s data.

 

For injected scripts, the amount of database storage available is set in the user’s security preferences.

 

In Safari 5.0.1 and later, you can use client-side databases in your global page or in extension bars as well. When used from a global HTML page or extension bar, the domain of the local storage is the extension. This data belongs to your extension.

Note: In Safari 5.1, attempting to use local storage to convey data between the global page or an extension bar and full page content does not work. As a workaround for this limitation, use message passing to convey the data. Message passing is the best mechanism for this purpose.

 

To use client-side databases from your global page or an extension bar, you need to allocate database storage for your extension in the Extension Storage section of Extension Builder, as shown in Figure 16-3.

Figure 16-3  Extension storage

The default storage amount is none. You can choose a value from 1 to 100 megabytes.

Important: If you do not allocate storage in Extension Builder, any call to openDatabase from the global page or an extension bar returns null.

 

In short, in order for an exploit to be exploitable a user has to open up the storage to be made available.

post #30 of 46
Quote:
Originally Posted by ciparis View Post

There is a well-known (to developers) feature of HTML5 that is designed to allow web applications to store data locally; it can be used for storing parts of the app (so you don't have to re-download them later), catalog data, big images -- whatever you want. Every browser has controls allowing you to delete this data.

 

It should be user configurable.  Not just capped at 5MB, but opt-in, on a per site whitelist basis.

 

If a website that I visit wants to store data on my computer, they can damn well ask my permission.

  Google Maps: ("Directions may be inaccurate, incomplete, dangerous, or prohibited.")

 

  MA497LL/A FB463LL/A MC572LL/A FC060LL/A MD481LL/A MD388LL/A ME344LL/A

Reply

  Google Maps: ("Directions may be inaccurate, incomplete, dangerous, or prohibited.")

 

  MA497LL/A FB463LL/A MC572LL/A FC060LL/A MD481LL/A MD388LL/A ME344LL/A

Reply
post #31 of 46
Quote:
Originally Posted by mstone View Post

How do you figure since regular hard drives can write data at around 3GB/s?


With my provider 1Gb would take about 2 days, even floppy disks can write faster than that.

post #32 of 46
Firefox seems to have been coded properly in this department.
post #33 of 46
Quote:
Originally Posted by ciparis View Post

Every browser has controls allowing you to delete this data.

The fact that it performs exactly that function is hardly a bug. It's arguable that various (among different browsers) built-in size limits should be domain-specific rather than host-specific, but this is really not a particularly earth-shattering distinction; using additional domains to get access to more storage space doesn't require much more "cleverness" than using additional hostnames.

I don't know whether Aboukhadijeh is an attention whore, or whether click-craving sites are so desperate for traffic that they'll post whatever sensational-sounding "security" story they come across, regardless of whether they have the slightest idea what it means. It's sensationalist nonsense, either way.

There definitely seems like a publicity seeking element here but I'd say that browsers should put a sensible cap on the total local storage across all websites. There really should be no reason for a browser to need more than even 1GB for all websites combined.

This affects iOS too, which has a 5MB default so you can imagine people being duped into visiting a link, losing all the free space and the iOS device starts acting up. You don't get warnings on iOS about lack of storage and it actually causes a lot of instability. If you leave an iOS device with less than about 100MB free, the App Store and other apps start crashing and hanging as they don't have anywhere to store their caches. You'd have to figure out the problem manually.
Quote:
Originally Posted by anantksundaram 
Why shouldn't he want -- indeed, deserve -- his fifteen minutes of fame?

He could also go out and shoot someone famous. It's not ethical to promote harmful code while it can still be exploited.
post #34 of 46
Funny but I tried this out on my 2005 PPC eMac and it did not write any data to disk, just consumed RAM.
Hey, this Kool-Aid is delicious, what do you put in it?!
Reply
Hey, this Kool-Aid is delicious, what do you put in it?!
Reply
post #35 of 46
Quote:
Originally Posted by Marvin View Post

He could also go out and shoot someone famous. It's not ethical to promote harmful code while it can still be exploited.

Ok, I must've missed that ethics class on the moral equivalency of murder and calling out (possibly) poorly coded software.....
post #36 of 46
Quote:
Originally Posted by mdriftmeyer View Post

FYI: Local Data Storage implementations are just in the early stages of being ready to role outside of nightly builds for WebKit and/or Mozilla, not to mention IE.

 

You might be thinking of other local database and file system access implementations.

 

The type of local storage used in this article has been around for a while.

 

I started playing with it in 2011, and in 2012 we deployed an internal enterprise tablet web app that uses it and the HTML5 manifest (which has its own problems).

 

Quote:

Originally Posted by anantksundaram View Post

Ok, I must've missed that ethics class on the moral equivalency of murder and calling out (possibly) poorly coded software.....

 

They're not the same level, but they're both questions of ethics.

 

A code attack can affect millions of people and cost millions of dollars.   So it's usually considered more responsible to first submit the error reports and give some time to see if it gets fixed, rather than tell every idiot on the planet how to do it.

 

This was a publicity grab, just like that guy who claimed to have hacked NFC (but really didn't).

 

On the good side of things, this is much easier for the user to correct (just clear it in the browser) than to fix, say, a badly written native app that fills or deletes the disk.


Edited by KDarling - 3/4/13 at 5:23am
post #37 of 46
Would a potential workaround be:

Quit Safari
Open, empty and lock the ~/username/library/safari/localstorage folder?

(Loathe to test on my only rig...)
post #38 of 46
Quote:
Originally Posted by andyapple View Post

Funny but I tried this out on my 2005 PPC eMac and it did not write any data to disk, just consumed RAM.

Don't worry - that 2005 eMac will get around to processing all that web data in a day or two... it's a feature!

(I have a few of them still in service...) 

post #39 of 46
Quote:
Originally Posted by mstone View Post

Sorry that should be Gbits not bytes and as I just looked it up, 3Gb is the theoretical maximum write speed for SATA II so practically speaking it would be quite a bit less however it could be pointed out that even at the easily attainable 150 MB per second, the HDD is still plenty fast enough to write 1GB in a lot less than 16 seconds so the specification of SSD mentioned in the article is still irrelevant. 

I know that's what you did, sorry I forgot the wink 1wink.gif
Use duckduckgo.com with Safari, not Google Search
Been using Apples since 1978 and Macs since 1984
Long on AAPL so biased. Strong advocate for separation of technology and politics on AI.
Reply
Use duckduckgo.com with Safari, not Google Search
Been using Apples since 1978 and Macs since 1984
Long on AAPL so biased. Strong advocate for separation of technology and politics on AI.
Reply
post #40 of 46
Quote:
Originally Posted by jpellino View Post

Would a potential workaround be:

Quit Safari
Open, empty and lock the ~/username/library/safari/localstorage folder?

 

You could try it with a simple localstorage test like this one:

 

 http://people.w3.org/mike/localstorage.html

 

Also see if you find the storage under Preferences - Privacy.  (Apparently Safari keeps moving around where these things are.)

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: General Discussion
AppleInsider › Forums › General › General Discussion › HTML 5 bug allows huge data dumps on most Mac and PC Web browsers