Could someone explain the actual tangible security implication of a browser without CORB and ORB?
markg85 opened this issue · 10 comments
Hi,
I'm basing my reason for ORBs existence on this post https://security.stackexchange.com/a/270918 as this repository does not explain it anywhere in detail. It states:
As to the idea behind this feature: CORB has nothing to do with preventing cross-site scripting. Instead, it is supposed to prevent cross-origin access to sensitive data through side-channel attacks like Spectre and Meltdown. The attack scenario is that a file which may contain sensitive user data (like HTML, XML or JSON) is loaded from a malicious website through an img or script element or fetch in no-cors mode. This is possible despite the same-origin policy and without CORS headers. Scripts from the malicious site cannot directly access the response, but the file content will be loaded into browser memory in order to render, execute or cache it. Through Spectre or Meltdown, it may then be possible to access the content in memory through Spectre/Meltdown exploits written in JavaScript.
If i understood the spec correctly then anything fetch does where no-cors is specified will follow the ORB rules.
With all that in mind i'd love to know that actual security hole that is fixed by having ORB with an actual example that shows me the fix is indeed serving a purpose. Yes, you can read a bit of skepticism in here. This is in part on you because there's just no example out there (that i could find) that explains this. Just a spec (this repo) that should be adopted.
Now i'm a developer and have some gut instinct of what could potentially happen (all still the assumption of no-cors) so please bear with me and improve this example to reflect the real world scenario.
Say site X includes some data with mime types specified by ORB, call it data Y.
X now parses Y which contains specially crafted data to abuse spectre.
Y - in some fluke of nature and stroke of genius luck - manages to get user sensitive data.
How does:
- X remain functioning? By which i mean that data that X included - Y - is nefarious and probably doesn't follow expectations of X anymore. By which i assume the site just wouldn't render anymore.
- If X somehow magically does stay functioning, how does Y send it's data back to a malicious party?
Don't get me wrong here, i'm for fixing actual security issues. But this one - and therefore the whole existence of CORB and ORB - seem such a far stretch and so far in the hypothetical realm that it doesn't seem worth it to me.
Don't agree with me? Well, just get your data through a cors enabled site which bypasses orb completely. If that cors enabled site is malicious then you have the exact same case again which kinda proves my assumption in thinking that orb is not worth the trouble. Also, if someone is skilled enough to make a malicious spectre-abusing data then i assume that person is skilled enough to hack a cors-enabled server to turn it malicious and serve it's data. So in my thinking the attack possibility (with or without cors) is the same.
But i could be completely wrong here!
Thus i'm asking. To learn :)
You have the attacker and victim reversed. X is the attacker.
How? What? I don't get it. Perhaps we need to add another entity.
X = the site (on some host somewhere)
Y = nefarious party wanting to steal private information
Z = user visiting site (X) using a browser
Z visits site X which isn't hacked at all. However, X includes external resources where one of those resources is under the control of a malicious entity (Y) and contains specially crafted data intended to exploit spectre.
Also, how likely is it that an exploit even works through this mechanism? Say you'd have no CORB/ORB. I'm asking because that too is nowhere to be found.
Are we talking about a 1 in 1000 chance of a succesfull attack?
1 in a million?
1 in a billion?
@markg85, does https://developer.chrome.com/blog/site-isolation/#corb help? (CORB protects less resources than ORB, but has the same motivation for protecting cross-origin no-cors resources.)
@anforowicz no.
While that link, thank you for sharing btw, does explain how CORB works and what it tries to prevent, it still leaves me with some of the same questions.
- What's the chance of a successful attack if CORB/ORB wouldn't exist? Surely there's metrics on this else the whole thing is just an overzealous security plug with no ground for tangible proof.
- If my assumption is correct then you can bypass all this security through CORS. And if that assumption is true then CORB/ORB serve no purpose other then to make life more difficult.
I'd instantly admit i'm wrong in those assumption if there's some backing behind it. But thus far this thread shines in absence of clarity from people who could know.
Your assumption is wrong as an attacker cannot make a victim adopt CORS. However, it's a bit unclear how to make you understand the threat model as both the README of this repository as the explanation linked by @anforowicz are pretty clear. You might have to study the same-origin policy in general a bit more first, perhaps.
Your assumption is wrong as an attacker cannot make a victim adopt CORS
Your interpretation of what i said is wrong, did i say anything that make you think this?
I never said that an attacker makes the victim adopt CORS.
I said the same attack vector is possible if the victim is already using a CORS enabled resource and if the attacker makes the CORS end malicious.
Or to put it differently.
What if an attacker makes a JS CDN malicious (one that many sites depend on).
In theory that would be a goldmine as an attacker would now have the ability to attack many sites at once with Spectre/meltdown/... directly at the user's pc where said CDN content is loaded. So you'd think there would have been such an attack. As far as i know, there hasn't.
Your readme is stellar in being vague in this regard. It's clear with your intent of what browsers should do, it's completely unclear with the thread model. Unless you call this a description:
CSS, JavaScript, images, and media (audio and video) can be requested across origins without CORS. Except for CSS there is no MIME type enforcement. Ideally we still block as many responses as possible that are not one of these types to avoid leaking their contents through side channels.
That's not explaining anything i'm looking for at all.
There is nothing on the attack vector that you're preventing with all of this.
I just want to know how feasible an attack would've been without these protections.
Because...
I fear this is a hypothetical once in a billion situation that would never happen in which case this whole CORB/ORB thing is an utter waste of time and serves only to satisfy security researchers hypothetical but non realistic scenarios. Your evading answers are pushing me more and more towards believing that this helps nothing besides annoy developers even more.
I'm sorry, but half of the things you write don't really make sense or are not related to the subject at hand.
There is nothing on the attack vector that you're preventing with all of this.
I'm not sure what this means, but perhaps it helps if I mentioned that "leaking their contents through side channels" is the problem and is what Spectre/Meltdown enable an attacker to do?
I'm not sure what this means, but perhaps it helps if I mentioned that "leaking their contents through side channels" is the problem and is what Spectre/Meltdown enable an attacker to do?
Oke, there are 2 ways to fetch data.
With cors and without if we limit it to just fetch. Agreed?
Without cors, your ORB rules kick in and prevent certain types of data from being fetched. Like a json or html blob.
With cors, the exact same data is processes just fine.
What i'm claiming is that the "sidechannel" to leak data can come in through one of both paths. Blocking one without the other is in my view just wasting time.
My point on top of this is wanting to know how feasible it is with leaking data to actually do harm? As in a realistic case, how probable is it? I keep asking this and that's the whole point of this whole topic. How feasible is an attack? Thus far you seem to be unable or unwilling (or both) to answer this, i hope you can finally provide some clarity here?
If a resource has opted in to sharing its data across origins (i.e. uses CORS), then there's no point in using side-channels to read its contents as you are allowed to read it directly (e.g. with fetch json()).
As for the feasibility, see https://spectreattack.com/#faq-demo-video and https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html
You're not getting the point.
None of your links show how feasible it is in a true web context. As in fetching a remote resource and doing something with it in terms of spectre/meltdown. All the examples are 1 on 1 testcases with everything local. The web example from googleblog is also a local case.
My question remains: How feasible is an attack?
But as that is misinterpreted over and over and over and over and over and over again, i'll rephrase it at the risk that that too gets misinterpreted yet again.
How feasible is an attack from external sources where CORB/ORB would prevent it?
If there is no answer then corb/orb is wasted time and should be removed.