Cross origin resource size infoleak
Categories
(Core :: Storage: Cache API, defect)
Tracking
()
People
(Reporter: feedthreatintel, Unassigned)
References
()
Details
Attachments
(1 file)
6.26 MB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Firefox for Android
Steps to reproduce:
VULNERABILITY DETAILS
I refer to this report: https://bugs.chromium.org/p/chromium/issues/detail?id=918293
It is possible to leak cross-origin resources exact size using appcache + storage estimator.
To exploit it it is enough to have an entry in the cache manifest file for this cross-origin resource and then receive size using a storage size estimator. If some more bytes are added to these resources then the returned size by the storage estimator has a difference by this value.
This attack doesn't work for cache API (I think some randomization of size is added to prevent from this attack)
Moreover, it works for resources that should be protected by CORB.
I have tested it on a resource that I was not able to load by Cache API because of CORB.
This vuln is pretty usefull when exploit xs-search bugs like this https://medium.com/@luanherrera/xs-searching-googles-bug-tracker-to-find-out-vulnerable-source-code-50d8135b7549
It is much easier with this appcache + estimator method, because it is possible to detected even single byte difference in response and this is reliable and don't require hard-to-perform timing side channels.
Note: Only affected on Firefox
REPRODUCTION CASE
PoC: https://poc-size-leak.adami.pl/exploit-leak-size.html (This has an example resource that should be protected by CORB)
Actual results:
Cross-origin resource size leakage is possible using a combination of appcache and storage estimator in Firefox.
A discrepancy in size exists that can be exploited by adding a few bytes to the cross-origin resource and comparing it with the size returned by the storage estimator.
Expected results:
There should be no method allowing the leakage of cross-origin resource size in this manner.
The size returned by the storage estimator should not be affected by additional bytes added to the cross-origin resource.
Updated•1 years ago
|
Updated•1 years ago
|
Comment 1•1 years ago
|
||
Your movie shows different output between Firefox and Chrome, but it does not show Firefox leaking the resource size. "-15829" comes from the initial value in the script and has no relation to the size of the cross-origin resource (which couldn't be negative in any case).
Actual results:
Cross-origin resource size leakage is possible using a combination of appcache and storage estimator in Firefox.
A discrepancy in size exists that can be exploited by adding a few bytes to the cross-origin resource and comparing it with the size returned by the storage estimator.
Your movie does not show this: you never changed the size of the remote resource and then got a different value in the test. I did perform the steps of the test and still did not get a different size. This is not surprising since the Appcache feature has been removed for a while, and disabled for even longer than that. There is equivalent functionality in the service worker cache API, but this test does not use that.
Updated•1 years ago
|
Description
•