At RSA this year, Feross.org released an HTML5-based hard disk filler which succeeded in engaging enough subdomains to exploit the 5MB local storage data permitted per domain. Ultimately, this led to all available space on the victim machine being allocated, resulting in consequences such as denial of service. While this is clever, HTML5 also introduces another feature called the File System API which makes hard disk filler attacks even more convenient for malicious attackers. This API allows web applications to create a sandboxed file system on the client machine that can be used to create, store, modify or delete files as needed by the application. Web applications can request this space either as TEMPORARY or PERSISTENT storage. The main characteristics of TEMPORARY and PERSISTENT storage are:
• Temporary space is 10% of total available disk space per application
• The combined temporary space requested by all applications together is capped at 50% of the total available disk space, and requests for additional storage forces the browser to delete the data stored by the least recently accessed domain; resulting in the entire storage for that domain being emptied at once
• There are no limits on PERSISTENT storage
• PERSISTENT sandbox creation first requires the application to obtain permission from the user
The prompt for the user’s permission is expected to protect users from a rogue application attempting to perform a hard disk filler attack without their knowledge. Although this addresses the foremost concern any security professional would have about such a feature, the UI implementation looks like a mockery of the actual purpose of permission prompt when we ran the experiment and noticed the following message:
The notification fails to specify the exact storage size requested and also fails to convey the dangers of granting this permission; which certainly isn’t strong enough of a warning for any unsuspecting user to pause and consider the consequences before proceeding. The screenshot below clearly demonstrates the damage that can be easily inflicted with this feature:
Notice the red warning indicator against the C: drive informing about disk utilization. Moreover, once the permission is granted, it’s cached until the application requests additional space.
We firmly believe that, over time, activities like the one mentioned above will be addressed by browser vendors by more prominently expressing the implications and details of such actions (i.e. a clear depiction of previously allocated space or set thresholds) or prohibit them altogether. However, as we’ve seen with prompts for SSL-related discrepancies, it is inevitable that these warnings will likely end up falling on deaf ears from visitors eager to access their desired resource anyway.