DoSinStyle CSS
Reported by
pal...@us.ibm.com,
Sep 28 2016
|
||||||||
Issue descriptionThis template is ONLY for reporting security bugs. If you are reporting a Download Protection Bypass bug, please use the "Security - Download Protection" template. For all other reports, please use a different template. Please READ THIS FAQ before filing a bug: https://www.chromium.org/Home /chromium-security/security-faq Please see the following link for instructions on filing security bugs: http://www.chromium.org/Home/chromium-security/reporting-security-bugs 1. Product & Affected Version Chrome 53.0.2785.124 on Android Chrome 53.0.2785.116 m on Windows Chrome 51.0.2704.79 (64-bit) on Linux 2. Background CSS(Cascading Style Sheets) describes how HTML elements are to be displayed on screen, paper, or in other media.CSS can be added to HTML elements in 3 ways: ● Inline - by using the style attribute in HTML elements ● Internal - by using a <style> element in the <head> section ● External - by using an external CSS file An external style sheet is used to define the style for many HTML pages. With an external style sheet, you can change the look of an entire web site, by changing one file! To use an external style sheet, you need to add a link to it in the <head> section of the HTML page, for ex. <link rel="stylesheet" href="styles.css"> Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched file must match. From https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity we can see that the very first example of SRI usage is a link entity with css file : “Using Content Delivery Networks (CDNs) to host files such as scripts and stylesheets that are shared among multiple sites can improve site performance and conserve bandwidth. However, using CDNs also comes with a risk, in that if an attacker gains control of a CDN, the attacker can inject arbitrary malicious content into files on the CDN (or replace the files completely) and thus can also potentially attack all sites that fetch files from that CDN. The Subresource Integrity feature enables you to mitigate the risk of attacks such as this, by ensuring that the files your Web application or Web document fetches (from a CDN or anywhere) have been delivered without a third-party having injected any additional content into those files — and without any other changes of any kind at all having been made to those files.” To sum up this section, I would expect that If I am a site owner and I use a css file that is hosted in untrusted/external cloud and is protected by SRI - no attacker will be able to tamper the css file in this server and damage my clients/site. 3. Vulnerabilities We generate a fake css file, using “dd if=/dev/zero of=file.css count=1024 bs=1081991”. The result is a 1107958784 bytes (1.1 GB) file. We copy the SRI sample page(https://googlechrome.github.io/samples/subresource-integrity/ ), and add a link to our new generated fake css file, using this command: “<link rel="stylesheet" href="file.css “integrity="sha256-OBVIOUSLY_INCORRECT_HASH">” As a result, the impacted browser’s tabs will crash A live demo for it can be seen here : http://michaelgoberman.com/cssCrash.html 4. Impact The impact of this attack is a DoS attack for any site linked to this css file, since most of the popular browsers are vulnerable to it. Theoretically SRI is exactly the feature which is supposed to protect from tampering 3rd party hosted files and prevent this type of attack. Unfortunately it doesn’t in this case. For Chrome based browsers it seems that the issue is in PartitionAllocator.h:59 file, in “static size_t quantizedSize(size_t count)” function. We see that there is a “RELEASE_ASSERT(count <= kGenericMaxDirectMapped / sizeof(T));” which cause the issue. It is important to mention that this kind of attack won’t work with other attributes like img/script, and this is a very specific flow. From this line we understand that generating file smaller than we chose won’t cause the issue (and indeed “dd if=/dev/zero of=file.css count=1024 bs=984335”=1007959040 bytes (1.0 GB) works fine in Chrome for example). This attack vector may have a significant impact on many sites, hence we report it early and will continue investigating this area for potential additional issues. 5. Credit The vulnerabilities were discovered and documented by IBM X-Force researcher Michael Goberman.
,
Sep 28 2016
As per our FAQ, we don't consider process crashes to be security bugs, because users can reasonably react by simply not loading that page again. http://www.chromium.org/Home/chromium-security/security-faq?pli=1#TOC-Are-denial-of-service-issues-considered-security-bugs- I understand that you are pointing out that a CDN compromise could enable this as a DoS against a targeted website, which can undermine SRI for sites that are using it. That's a good point and seems to warrant the problem being addressed. It's basically a compression bomb against the resource loader, which exhausts memory during the decoding in blink::TextResource.
,
Sep 29 2016
,
Sep 29 2016
We understand your point of view. However, you are missing our point about what is resulting: 1. user can't reload the page...the site is down - it won't work...in the demo we've provided, there is only one page affected because I didn't want my site to be down... [so this can be extended] In addition, usually the same css file will be in many pages, if the owner wants the site to have the same look & feel; plus there are more files we still can perform the same attack on them (usually located in the same cloud). 2. It is a security issue; if SRI is a security feature and it fails to protect for its intended / original purpose - it becomes a security issue with the result that the site doesn't work for the user... 3. The issue doesn't exhausts the memory, there is an assert check which is causing the fault...we would advise you to re-read the disclosure...
,
Sep 29 2016
In all instances of this that I repro on 64bit Windows Chrome 53 and Chrome 55, the failure is here: -partitionallocator.h:59 WTF::PartitionAllocator::quantizedSize<unsigned char>(unsigned __int64) -vector.h:1346 WTF::Vector<unsigned char,16,WTF::PartitionAllocator>::append<unsigned char>(unsigned char const *,unsigned __int64) -stringbuilder.h:107 WTF::StringBuilder::append(WTF::StringView const &) -textresource.cpp:41 blink::TextResource::decodedText() -cssstylesheetresource.cpp:120 blink::CSSStyleSheetResource::checkNotify() -resourcefetcher.cpp:984 blink::ResourceFetcher::didFinishLoading(blink::Resource *,double,__int64,blink::ResourceFetcher::DidFinishLoadingReason) const &) This matches the assert you're reporting. Having said that, the assertion in question exists to verify that the memory allocation is not too large. > if SRI is a security feature and it fails to protect for its intended / original purpose SRI is a security feature designed to prevent web pages from loading resources that have been replaced. The malicious resource in this scenario fails to load, meaning that SRI is not circumvented (or even consulted, in this repro).
,
Nov 22 2016
Right, we can't determine integrity until we've loaded the resource in full. I think this is outside the scope of SRI. Marking as WontFix. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by elawrence@chromium.org
, Sep 28 2016