[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #19400 [Applications/Tor Browser]: [Asan] Crash in js::AsmJSModule::deserialize / DeserializeSig

#19400: [Asan] Crash in js::AsmJSModule::deserialize / DeserializeSig
-------------------------------------------------+-------------------------
 Reporter:  cypherpunks                          |          Owner:  tbb-
     Type:  defect                               |  team
 Priority:  Very High                            |         Status:
Component:  Applications/Tor Browser             |  assigned
 Severity:  Critical                             |      Milestone:
 Keywords:  tbb-crash, TorBrowserTeam201606,     |        Version:
  tbb-gitian                                     |     Resolution:
Parent ID:                                       |  Actual Points:
 Reviewer:                                       |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):

 * cc: boklm (added)
 * keywords:  tbb-crash, TorBrowserTeam201606, tbb-6.0-issues => tbb-crash,
     TorBrowserTeam201606, tbb-gitian


Comment:

 Replying to [comment:30 mcs]:
 > Kathy and I are waiting for our own gitian build to finish before we can
 be sure (and you may already know some of this), but we believe that a
 not-so-beautiful combination of factors led to this crash:
 >
 > 1) This Firefox change that was made for 45.2.0 ESR:
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-45.2.0esr-6.5-1&id=fcb31773712f1e2adce790771f7978ba30056645
 >
 > 2) The fact that our build ID does not change between releases. The
 asmjscache code includes the build ID in serialized files and uses it to
 determine if cached files should be used or not (because serialized data
 structure sizes may change between browser releases). I would feel better
 if the serialized data structures had built-in bounds checking, e.g., by
 using a <length><payload> format for everything, but they do not. For
 build ID usage, see:
 >  https://gitweb.torproject.org/tor-
 browser.git/tree/dom/asmjscache/AsmJSCache.cpp?h=tor-
 browser-45.2.0esr-6.5-1#n113
 >  https://gitweb.torproject.org/tor-
 browser.git/tree/dom/asmjscache/AsmJSCache.cpp?h=tor-
 browser-45.2.0esr-6.5-1#n1697
 >  https://gitweb.torproject.org/tor-
 browser.git/tree/js/src/asmjs/AsmJSModule.cpp?h=tor-
 browser-45.2.0esr-6.5-1#n2000
 >  https://gitweb.torproject.org/tor-
 browser.git/tree/js/src/asmjs/AsmJSModule.cpp?h=tor-
 browser-45.2.0esr-6.5-1#n2317
 >
 > The build ID issue also explains why our non-gitian builds do not crash
 (those builds use a build ID that is based on the actual build date like
 Firefox does).
 >
 > If we do not want to disable the asmjscache unconditionally, then we
 will have to come up with a way to return a value from
 dom/asmjscache/AsmJSCache.cpp's GetBuildId() method that is unique for
 each of our releases.

 Thanks for this analysis! Things are starting to make sense. :) Your idea
 is actually #11506 which I did not find a good solution for while looking
 briefly at the options Gitian itself gives us.

 I am inclined to stop using the asmjscache for now at least until #19417
 is somehow solved. This would fix both issues for us. I wonder whether
 just backing out the patch in 1) would work as well which would then be
 another option.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19400#comment:33>
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