Thinking more on this, the issue is much deeper and stems from the organization of the policy protocol.

Its flaw is that there is no signature for the _whole_ response from the policy server. Only individual PolicyData's enclosed into individual PolicyFetchResponse's are signed.

A man-in-the-middle can just drop unwanted PolicyFetchResponse's, and client would have not much options for detecting this. Absence of a response for a given extension may mean two things: either a) there is no policy for the extension on the server anymore, or b) a man-in-middle took the policy fetch response out.


Mattias, do you have any thoughts on this?

It feels that the severity should not be very high, as 1. communication with DMServer happens through HTTPS; 2. client-side cache is anyway not resistant to blobs deletion.


Regarding the possible ways for fixing the issue, I see two options:
a) Ask server-side guys to guarantee that policy responses are still returned for the deleted policies for extensions (of course, such responses should contain empty URLs). Then we could change the implementation in Chrome so that it wipes policies _only_ in response to empty-URL policies.
b) Change the policy protocol, so that component policies are transmitted as a sub-proto of the superior policy (e.g. PolicyData). (This would anyway make much more sense from the logical perspective. On the other side, this would require a lot of work for performing the transition.)

Looks like there's not much we can do with this currently.

Solution a) from comment #1 doesn't look nice to me (it makes it very simple to start spoiling the client profiles with unused data).

Solution b) would be feasible only if we decide to change the policy protocol at some point.
Drew, this is not going to come about in the foreseeable future, right?

Do you think it's fine to live with this flaw with the component policies?

I think relying on SSL to prevent MITM-ing is OK. It's not ideal that an attacker could just drop individual policy for extension blobs, but at least you can't inject policy this way, just make an extension unmanaged.

RE comment #5: usually we have a second level of protection besides relying on SSL to DMServer. But I agree that the risk still looks to be relatively small here.

Marking this as WontFix then. The TODO in the code is still there, and it will point to this discussion in case anyone else starts thinking on this issue.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot