On Thu, May 22, 2014 at 1:51 PM, Mike Perry <
mike...@torproject.org> 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
<
benj...@smedbergs.us> 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 <
mike...@torproject.org> 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
<
benj...@smedbergs.us> 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.