Sandboxing expectation #383
Comments
|
I can't even parse (from an english point of view) the first sentence "User Agents are responsible for providing users with a secure way to browse the web, including any functionality, such as CDMs, from third parties.". What is 'including' attached to? 'the web'? 'a secure way'? but CDMs are not 'from the web'... can someone re-write this sentence to make it closer to comprehensible by mere motals? |
|
How about "User Agents are responsible for providing users with a secure way to browse the web. This responsibility covers any functionality used by User Agents, including functionalities from third parties like CDMs." |
|
Is this to be an Editorial in the REC, or for future work ? Your proposal is what I believe was intended by that text, yes. |
|
Given that:
a. there are many user agents that are written by one party as applications on top of operating systems written by another party, and
b. there are a great many key web APIs which are interfaces to functionality that is often in large part implemented by operating systems as a service to applications, such as File API, indexedDB, XHR, Geolocation, Canvas, WebGL, KeyboardEvent, TouchEvent, MSE and, in some OSs, EME.
While there are security expectations of browser applications and also security expectations of OSs, I don't think that there are (or could reasonably be) expectations that a browser application is responsible for the security of OS services implemented by another party, when the browser accesses those services by one of the APIs above. For example, I don't think anyone expects that a Chrome browser downloaded to Windows becomes responsible for Windows file system security, just because the Chrome browser accesses the Windows file system via the File API.
I think this applies to all the APIs above (and other OS-interface APIs), including EME.
|
|
@mav Yes, the CDMs referred to there were those bundled with the browser. That is to say, the user should have to consider only whether they trust their browser supplier with their security and privacy, not take an inventory of all the 3rd party components shipped with or downloaded by the browser and individually decide whether they trust those. In addition, the browser is free to use any resources the user provides, like the Operating System, for example, under the assumption that the user trusts those resources with their security and privacy. The User Agent should not need to treat the Operating System as user-hostile. |
|
@mwatson2 Thanks for clarifying the intent. This is not clear from the text:
@plehegar I suggest the text be explicit that this only applies to CDMs bundled with a browser application and doesn't apply to CDMs that are part of the OS. |
|
@mavgit, @mwatson2: While "the User Agent should not need to treat the Operating System as user-hostile," that doesn't mean user agents should assume that the OS is secure against attacks. I think there is generally an assumption that modern user agents (and even specs) make reasonable efforts to avoid exploit of OS capabilities. For example, storage APIs don't have access to the OS file system and WebGL implementations check the GL commands in some way. @plehegar, CDMs are not necessarily from third parties, so I think we need to modify the end of your proposed text. I don't see a simple way to integrate "such as CDMs," so maybe we should just drop it and let the following sentences address this. For example:
|
|
@plehegar Regarding your original comment, I think there are a number of expectations in Implementation Requirements, Security, and Privacy that may not be explicitly covered in the algorithms because there was no clean way to address them in an algorithm. (I suppose we could say, "If the CDM implementation does not meet requirements X, Y, and Z, the implementation SHOULD NOT load it." We actually do something like that in one step.) On the other hand, some are covered in the algorithms and explained in these other sections. |
|
#382 proposes adding a |
|
@ddorwin the easy solution is to make it a requirement. Those who do not conform will not be in compliance with the standards. Standards are for how it should be, not a description of how it is currently. |
|
I think we should state the requirement -- that security is maintained and offered by the browser -- and not try to tell the browser vendors how to achieve that. Is a CDM implemented in a chip 'sandboxed', for example? I fear making an untestable shall, and a statement of implementation rather than effect -- we should tell implementers what to achieve, not one way to achieve it. Sandboxing is a common way to enhance security, yes. (Mind you, the thesis that CDMs are necessarily insecure seems rather suspect to me, as well.) |
Few people are worried that a CDM might get hacked. A lot of people are worried that CDMs will be used to hack you. Malware CDMs are a very real threat and should be taken seriously because currently CDMs have little to no limitations.
If it's resources are isolated from the OS then yes it is. You should read up on what sandboxing actually is before blindly arguing against it. |
I think a key word in @dwsinger's response was "necessarily". Clearly, if you have a third-party component of uncertain provenance you need to take great great care with it. In fact you probably shouldn't use that thing at all. On the other hand, if the browser implementor and CDM implementor are one and the same and they take the same approach to the security of their CDM code as they do for the rest of their browser code, there's no reason to expect the CDM to be less secure than the rest of the browser. And, of course, there are cases in-between. |
Let's say your average user stumbles onto a malicious site. This site prompts the user to agree to install a CDM to view the content on that site. Without a mandatory sandbox, your average user is one click away from having randsomware take over their entire machine. With a mandatory sandbox, your average user at least stands a chance of being protected. Kinda seems like we should have some sort of specification for CDMs, eh? If you don't think this is plausible then you are either in denial or haven't been paying attention to the news about people getting randsomwared. |
But this is not the model envisaged by EME. Sites do not get to prompt the user to install arbitrary CDMs. CDMs are integrated by the browser and only those the browser has chosen to support can be used by sites. Right now, each of the four major browsers supports a single CDM implementation, in three cases that implementation is created by the browser implementor themselves and in the fourth (Firefox) there are code signing mechanisms to ensure that the CDM is indeed exactly the thing Mozilla expects it to be. |
|
OK, you're not talking about a characteristics of CDMs, but of downloaded code. Indeed, when a user downloads any kind of code from an otherwise unknown site, it should be treated with the utmost circumspection; plugins, codecs, whatever. But we're discussing CDMs, and as Mark says, this is not the model. |
Do you honestly expect me to believe that Microsoft's code is sufficiently secure? I see no logical reason to not require an additional level of security. If you have one in mind, please share it. @dwsinger |
|
If you don't think Microsoft's code is secure, why on earth are you using their browser and operating system? Codecs can be immediately invoked. Plugins can be immediately invoked. This is all to do with downloaded code and nothing to do with CDMs per se. I agree that if the browser allows installation of third-party code of any kind, then it had better be pretty sure it's restricting that code to only get the info it needs and performing its stated purpose; this is not restricted to CDMs. |
|
@GravisZro Yes, it's exclusionary in the sense that only the browser implementor gets to choose what CDM to implement / integrate with. That's by design. Sites have to use the CDM the browser supports or stream unprotected. I do think browsers will not include poor CDMs because it is easy to users to switch if the browser is found to be exposing them to excessive security or privacy risk. By contrast, when the sites got their choice of plugin, it was impossible for users to change that and still access the same content. Browsers have a huge market share incentive to do the right thing by their users. Do you understand how markets work ? If you do not trust Microsoft's code, I see no logical reason why you would want to sandbox just one tiny part of it. |
Wrong. The browser implementor gets the privilege of which CDMs to implement if they pay some company millions of dollars. Do you really think Microsoft was going to let their latest DRM work with Linux without giving them money? They would sue you until you couldn't defend yourself. How much did Qualcomm have to pay to have their smartTVs use Microsoft's DRM so that they could play 4K content on Netflix?
This couldn't be more wrong. Sites can outright refuse to support browser ABC because company XYZ made a contract with them for exclusivity. If it was expecting to use a CDM, there is no way they would stream it unsecured, they'll just screw over the user and leave them with a big ol'e "sorry, but your platform is not supported" type message. However, if modules could be used between browsers and platforms, this wouldn't be an issue. It's almost as if we need a CDM specification to ensure access for all.
Microsoft has endlessly abused their users and yet some people still use their browser. It's almost as if some people don't know about the technical details of how their computer much less browser works. Reality and theory are very different things which is something you should learn.
This one part of their code is exceptionally vulnerable because it's in a binary format coming from the internet. In the past, Windows has been compromised by trying to parse simple images in their browsers, including their own proprietary formats! Add to that, their is a long history of people getting hacked from trying to play WMV files that there player didn't validate. CDMs are sophisticated parsers and I have no doubt Microsoft has bungled this task like all their others. Nobody can force Microsoft to sandbox it's code but this is an important piece of code that we can ensure gets sandboxed if they want to be complaint with standards. |
|
Sure, when I said "Sites have to use the CDM the browser supports or stream unprotected" I was assuming a site that actually wants to stream to a given browser. If they don't want to they don't have to, obviously. My point was that sites don't get to request some arbitrary CDM the browser implementor has never heard of, like they did with plugins.
But this was exactly the situation with plugins which all browsers wanted to get away from (with good reason).
No, it's not expected that browsers would download unknown binary code. In the cases where browsers are today downloading CDM code, they have code signing mechanisms to ensure they're getting the specific thing they expect (this is what Firefox does). |
The reason they wanted to get away from plugins was because they were a security vulnerability. I'm telling you to make sure they are more secure sandboxing and you're saying, "there's no reason to do that". Perhaps you should put this on the list Sherlock.
I'm not talking about binary code, I'm talking about the binary format that the video stream comes in. Please re-read my comment with that in mind. This one part of their code is exceptionally vulnerable because it's in a binary format coming from the internet. In the past, Windows has been compromised by trying to parse simple images in their browsers, including their own proprietary formats! Add to that, their is a long history of people getting hacked from trying to play WMV files that there player didn't validate. CDMs are sophisticated parsers and I have no doubt Microsoft has bungled this task like all their others. Nobody can force Microsoft to sandbox it's code but this is an important piece of code that we can ensure gets sandboxed if they want to be compliant with standards. |
That's not what I said at all. Please read the thread. Your argument regarding components that process binary data from the internet is well-taken, but it applies all audio and video codecs and image codes (as you mention) and other components too. I certainly agree that CDMs need to be subject to the same security protections as those other components. |
|
No, CDMs need to be subject to even greater protections than open standardized formats because they have only a single implementation and a total lack of oversight. Companies like Microsoft have shown they cannot be trusted to parse complex binary structures like video in a secure manner. Third parties who have unknown or even non-existent security practices have the real possibility of having their code included as a CDM because money talks. With this in mind, explain to me your objection to sandboxing as a requirement. |
|
I still see no particular difference between Microsoft's proprietary closed source implementation of PlayReady and their proprietary closed source implementation of H.265 or OpenGL or any one of a hundred OS components which are Microsoft proprietary and closed source. Same for Apple. The security experts at those companies have a much better idea of how best to invest resources in securing their implementations than this WG could possibly have. Perhaps sandboxing is the answer - our specification calls it out as a likely option - but in the end the best approach is a judgement call that we are not well placed to make here. We do, however, need to make it clear where the responsibility lies. Browsers are responsible for the user's security and privacy when they integrate with CDMs. |
|
To add to that last point, if you have a form of words which better characterizes the level of security we should expect without mandating a specific solution, that would be interesting. |
|
When systems start getting randsomwared because of shitty security in a CDM, I'll be sure your name is in the byline as the person responsible for the lack of security. |
|
@GravisZro That's not really spec language. |
|
So how much does the security of millions go for these days, Mark? |
|
On Apr 15, 2017, at 18:19 , Gravis ***@***.***> wrote:
When systems start getting randsomwared because of shitty security in a CDM, I'll be sure your name is in the byline as the person responsible for the lack of security.
Again, why is a CDM special? Because you dislike them, or because of some technical characteristic they have that distinguishes them? Can you make an argument based on their intrinsic and necessary characteristics?
You are failing to make a case that they are intrinsically different from other components.
You *have* restated the case that (any) arbitrary code that the user downloads and installs should be treated with due caution — but that case was made very clearly decades ago, so you’re a little late to the game. We know this.
David Singer
Manager, Software Standards, Apple Inc.
|
The CDM, PlayReady is within the scope of this technical specification. The other things are not within the scope of this technical specification. It's best we learn from the past to improve our future, especially in standards. |
|
@graiszro Just to check I understand, are are saying that whenever a new W3C standard admits an implementation based on interaction with platform / OS components, it should require that such implementations interact with those components only if they are known to be sandboxed ? It's still not clear to me why this is different from the |
|
@GravisZro I don't get your "single implementation" problem. You seem to be saying that something is intrinsically less secure if there is only one implementation. If Fred develops the first implementation of something, and later, unknown to Fred, Cedric and Ismael develop implementations, does Fred's become more secure (through some magic process)? The decryption module is actually a fairly safe piece of software, compared say to codecs. The inputs are either well-constrained (the keys) or uninterpreted bitstreams (the datastream). By contrast, codecs have to parse complex structures with a lot of internal interdependencies (and indeed the industry has had problems with codecs). So indeed, companies often sandbox codecs to reduce problems with them being attacked. |
If the behavior of the new component if fully defined and it's limitations understood, then no, there is no reason to sandbox. However, CDMs are completely undefined and therefore not limited in any way. It's components like these that needs to be sandboxed.
Proprietary video codecs should also be sandboxed.
Software and software components are in an evolutionary competition of survival of the fittest. If something is poorly implemented then you drop it in favor of a better designed code. CDMs take away this possibility because they are all singular implementations. Take the Adobe Flash plugin for example. It was a total disaster but it didn't have any competition to wipe it out. However, one HTML5 gained adequate capabilities, the Flash plugin died because it was a peice of shit. Without an alternative to CDMs, we are stuck with them regardless of how shitty they are. Also, feel free to address my other points about foreign code and the endless failings of Microsoft. |
Browsers can switch to different CDMs. People can create new ones. Firefox already switched from Adobe Access to Google Widevine. |
|
@mwatson2 How about you address my other arguments. |
|
Like I said, Firefox already made a switch. I don't think I've anything new to add to what I've said above. We agree that some components need to be sandboxed. W3C does not require sandboxing of proprietary video codecs despite that you say it is necessary and they are accessible through the |
|
I filed #405 to track cleaning up the sentence mentioned in #383 (comment). |
|
That should mean this issue can be closed, correct? PR #394 was merged and it noted here. |
|
Agreed. This issue can be closed. |
Section 10.2 says:
[[
User Agents are responsible for providing users with a secure way to browse the web, including any functionality, such as CDMs, from third parties
[...]
Exploiting a CDM implementation that is not fully sandboxed and/or uses platform features may allow an attacker to access OS or platform features [...]
If a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured, the user agent SHOULD ensure that users are fully informed and/or give explicit consent before loading or invoking it.
]]
However, this expectation isn't really reflected earlier in the specification, especially the graph in Section 1 Introduction.
#382 proposes to address this issue by adding a sandbox around the CDM in the graph.
The text was updated successfully, but these errors were encountered: