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.
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.
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.
``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.
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"
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.
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.
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.
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.
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.
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
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.
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
Comments
Quote:
Originally Posted by rednival
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.
Quote:
Originally Posted by UncleOwn
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.
Quote:
Originally Posted by mstone
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.
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.
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"
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.
Quote:
Originally Posted by Nobodyy
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
openDatabasefrom the global page or an extension bar returnsnull.In short, in order for an exploit to be exploitable a user has to open up the storage to be made available.
Quote:
Originally Posted by ciparis
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.
Quote:
Originally Posted by mstone
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.
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.
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.....
Quote:
Originally Posted by mdriftmeyer
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
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.
http://www.hackersnewsbulletin.com/2013/03/html-5-exploit-can-fill-garbage-in-your.html
Quit Safari
Open, empty and lock the ~/username/library/safari/localstorage folder?
(Loathe to test on my only rig...)
Quote:
Originally Posted by andyapple
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...)
I know that's what you did, sorry I forgot the wink
Quote:
Originally Posted by jpellino
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.)