Re: [tor-bugs] #13670 [Tor Browser]: ensure OCSP & favicons respect URL bar domain isolation

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13670: ensure OCSP & favicons respect URL bar domain isolation
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  arthuredelstein
  arthuredelstein        |     Status:  needs_review
         Type:  defect   |  Milestone:
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  tbb-linkability, ff38-esr,
  Browser                |  TorBrowserTeam201505R, MikePerry201505R
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by mikeperry):

 Issues I've spotted so far:
 1. It seems that in nsHttpChannel::BeginConnect(), the isolationKey is the
 full URI spec. Shouldn't it be using
 ThirdPartyUtil::GetFirstPartyHostForIsolation() instead of the full spec?
 2. nsHttpConnectionInfo::SetOriginServer() is also using the isolationKey
 here. This is going to cause much stronger HTTP Keep-Alive isolation than
 we originally had, esp if the isolationKey differs from how we use SOCKS
 u+p.
 3. I am made very nervous by the use of bare char pointers rather than
 nsCStrings for passing (and in NSSCertDBTrustDomain, holding) the
 isolationKey string. Are we absolutely sure the lifetime of the objects
 using the bare pointer is always shorter than wherever this isolationKey's
 pointer memory is held? This seems especially tricky because there are a
 couple of different places that hold a copy of the isolationKey, and it is
 hard to untangle which bare pointer is really held by which object. Is the
 additional string allocation+copy really a serious perf concern here?
 Otherwise, I think we risk some really annoying-to-debug UAFs, especially
 if the OCSP request handling is refactored, made more async, or otherwise
 further decoupled from the HTTP layer in future Firefox releases.

 In fact, I suspect that it may be the case that our longer HTTP keep-alive
 is just causing us not to see more cases where issue 3 would cause
 crashes. If the original HTTPS connection gets torn down long before the
 OCSP request completes, I suspect we'll again see issues...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13670#comment:35>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs