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

2

Comments

  • Reply 21 of 46
    mstonemstone Posts: 11,510member

    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.

  • Reply 22 of 46
    rednivalrednival Posts: 331member

    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.

  • Reply 23 of 46
    rednivalrednival Posts: 331member

    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.  

  • Reply 24 of 46
    nobodyynobodyy Posts: 377member
    ``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.
  • Reply 25 of 46
    misamisa Posts: 827member
    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"
  • Reply 26 of 46
    l008coml008com Posts: 163member
    Super misleading title on this article, I'd say.
  • Reply 27 of 46
    elrothelroth Posts: 1,201member


    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.

  • Reply 28 of 46
    mdriftmeyermdriftmeyer Posts: 7,502member

    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.

  • Reply 29 of 46
    john.bjohn.b Posts: 2,740member

    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.

  • Reply 30 of 46
    smiffy31smiffy31 Posts: 199member

    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.

  • Reply 31 of 46
    clemynxclemynx Posts: 1,510member
    Firefox seems to have been coded properly in this department.
  • Reply 32 of 46
    MarvinMarvin Posts: 14,509moderator
    ciparis wrote: »
    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.
    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.
  • Reply 33 of 46
    andyappleandyapple Posts: 152member
    Funny but I tried this out on my 2005 PPC eMac and it did not write any data to disk, just consumed RAM.
  • Reply 34 of 46
    anantksundaramanantksundaram Posts: 20,185member
    Marvin wrote: »
    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.....
  • Reply 35 of 46
    kdarlingkdarling Posts: 1,640member

    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.

  • Reply 36 of 46
  • Reply 37 of 46
    jpellinojpellino Posts: 652member
    Would a potential workaround be:

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

    (Loathe to test on my only rig...)
  • Reply 38 of 46
    jpellinojpellino Posts: 652member

    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...) 

  • Reply 39 of 46
    MacProMacPro Posts: 19,334member
    mstone wrote: »
    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 ;)
  • Reply 40 of 46
    kdarlingkdarling Posts: 1,640member

    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.)

Sign In or Register to comment.