On Thu, May 22, 2014 at 1:51 PM, Mike Perry <[email protected]> wrote: > Hrm.. What is the nature of the barrier between the $EVILBLOB and the > CRM host, then?
C++ linkage across a shared library dynamic linking boundary. > Can $EVILBLOB decide to alter the address space of the CRM host at will? Yes. > If so, what prevents it from going rogue and eliminating/ignoring your > salt entirely, or from being exploited and using the same > device-information gathering APIs that are allowed in the CRM host to > gather sufficient information about the device to break out of the > sandbox? The process having zeroed the inputs (origin-associated salt from the browser and device-unique information the CDM host has gathered) to the cryptographic hash function before passing control to CDM code and process having requested (before control is passed to CDM code) the kernel not service most system calls from the process. >> > For the record, in Tor Browser we are also trying to demonstrate that it >> > is possible to provide the same third party tracking protections as "Do >> > Not Track" through technology, rather than policy. >> > >> > In other words, we have jailed/double-keyed/disabled third party >> > cookies, cache, DOM storage, HTTP Auth, and TLS Session state to the URL >> > bar domain, to eliminate third party tracking across different url bar >> > sites. >> >> Cool. >> >> > To be completely clear, the salt is handed to the CRM host by browser >> > code that we can modify, if we disagree with your decision on the iframe >> > scoping of this salt? >> >> As currently planned, you should be able to do that. Each new salt >> results in some server load-causing initialization, so the main >> concern I see is unhappiness over making the system more chatty in a >> way that translates into server load (and user-perceived latency, but >> considering that Tor itself adds latency to buy privacy, I expect you >> to be OK with added user-perceived latency to buy privacy). > > Well, adding a full round trip over Tor will actually be quite > expensive, and I suspect will ultimately result in the > generation+transmission of the third-party trackable identifier *and* > the the jailed identifier, which will also still be a tracking issue. > > Is there a reason why we couldn't simply change the single salt that is > currently passed in to be based on url bar host + iframe url host, > instead of just iframe host, and avoid the extra round trip? If two sites embed a DRMed video from a video hosting service, the server load-causing initialization would happen separately for the two embedding sites if the salt was embedder-specific compared to it being only embeddee-specific only. Also, the post-initialization state of the CDM would have to be stored twice on the user's disk (not written by the CDM directly of course but in a way mediated by Firefox). Note that we might end up making the salt specific to the embedder/embeddee combination despite those disadvantages. On Thu, May 22, 2014 at 8:21 PM, Benjamin Smedberg <[email protected]> wrote: > When the user requests DRM activation, firefox.exe will set up launching > plugin-container.exe in a sandbox. No, the CDM host process has to gather the device-unique data first and only subsequently ask the kernel to take away its ability to do that again. Hence, the CDM host process can't be launched without the privileges needed to gather the device-unique information. Instead, it has to make the transition after gathing the device-unique information. > The Adobe DLL is free to poke around Poke around within the address space of the process it is in, that is. That process will contain the code of the CDM host executable and (by the time the CDM can do any poking) the code of the CDM .so/.dylib/.dll. On Thu, May 22, 2014 at 9:11 PM, Mike Perry <[email protected]> wrote: > Based on the combination of your and Henri's statements, it sounds like > the CDM Host (plugin-container.exe) process is still allowed a large > degree of access to OS APIs/interfaces in order to extract > device-identifying information. Unless these privileges are subsequently > dropped by plugin-container.exe after extracting this information but > *before* executing any $EVILBLOB code, then if $EVILBLOB is exploited, > it will still access these APIs, which it may be able to use to break > out of the sandbox, or at least to directly obtain device-identifying > information for its own purposes. For simplicity, let's say the browser consists of one executable and one process. (That the browser is becoming multi-process itself isn't relevant here.) So there are two processes: browser and CDM host. There are two executables to go with those processes: browser and CDM host. Additionally, there is a shared library, the CDM, that gets loaded in the CDM host process. So roughly this is what we are planning on implementing: 1) The browser process spawns the CDM host process that runs the code of the CDM host executable. 2) These two processes set up whatever IPC is going to be needed. 3) The browser passes the salt to the CDM host over IPC. 4) The CDM host goes gather device-unique information. 5) The CDM host passes the data obtained in steps #3 and #4 to a cryptographic hash function. 6) The CDM host zeros the memory that held the data obtained in steps #3 and #4. (The output of the hash function is kept.) 7) The CDM host maps the code of the CDM .so/.dylib/.dll into its address space. (This will require some trickery to inhibit the execution of static initializers at this point.) 8) The CDM host asks the kernel to stop servicing system calls (apart from using the already established IPC facilities, terminating the process and obtaining more memory). 9) The CDM host calls into CDM code passing the hash to it. 10) (This step goes beyond Mozilla's responsibility to implement, but I'm including it for clarity.) The CDM pokes around to convince itself that the address space belongs to an executable that matches the Mozilla-disclosed source and, therefore, has performed steps #4 and #5 in the manner expected. On Thu, May 22, 2014 at 9:20 PM, Benjamin Smedberg <[email protected]> wrote: > The device identification and salting is performed by Firefox and passed to > the plugin-container. As I explained earlier in this thread, the CDM won't trust Firefox to gather the device-unique information. That the device-unique information is gathered by neither the CDM nor by the browser is the crux of this solution. The CDM Tivoizes the CDM host from within, which makes it OK from the perspective of the DRM threat model for the CDM host to be responsible for gathering the device-unique information. The code for hashing and zeroing the device-unique information will be built by Mozilla, which make this OK from the perspective of the user privacy threat model which treats unauditable code as a potential threat to the user's privacy. -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
