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

Re: [tor-bugs] #7085 [Tor bundles/installation]: Integrate Cryptocat Browser Extension into Tor Browser Bundle



#7085: Integrate Cryptocat Browser Extension into Tor Browser Bundle
--------------------------------------+-------------------------------------
 Reporter:  kaepora                   |          Owner:  erinn                        
     Type:  enhancement               |         Status:  new                          
 Priority:  normal                    |      Milestone:  TorBrowserBundle 2.2.x-stable
Component:  Tor bundles/installation  |        Version:  Tor: unspecified             
 Keywords:                            |         Parent:                               
   Points:                            |   Actualpoints:                               
--------------------------------------+-------------------------------------

Comment(by kaepora):

 Replying to [comment:29 mikeperry]:

 > Replying to [comment:27 kaepora]:
 >
 >
 > > Replying to [comment:26 mikeperry]:
 > >
 > >
 > > > Second, I am very concerned that there were XUL XSS bugs in the chat
 windows. To me, that's a bad sign. Ideally, I'd like to see something on
 your side (ie a tag in your bugtracker or some other document you wrote)
 that enumerates the patches that resulted from your first audit.
 > > >
 > > >
 > >
 > > The patches in which we fixed the audit bugs are enumerated (perhaps
 incompletely) in this [https://blog.crypto.cat/2012/11/security-update-
 our-first-full-audit/ blog post].
 > >
 > >
 >
 > This is great. You should show this to whoever you contact about further
 audit. Bugs tend to come in groups of similar nature, and seeing the types
 of mistakes you made will help the second auditor find more of them.
 >

 Thanks :-)

 >
 >
 > > > Third, while it does look like the audit was extremely thorough, I
 think I'd prefer a second one for this reason. XUL XSS is quite serious,
 and since you're writing a network-facing app with lots of user and
 network provided content, its critical that your code receives lots of
 this type of review.
 > > >
 > > >
 > >
 > > Very well. Who would you recommend to perform the second audit? If you
 can give me a preferred auditor or a list of auditors that the Tor Project
 would feel comfortable with, I have no problem getting in touch with them.
 > >
 > >
 >
 > A quick search for "Firefox extension XSS" and related queries turns up
 Roee Hay and Roberto Liverani as previous folks who have done similar
 audits. I don't know these people, but I suppose an email couldn't hurt.
 >
 > You should also send Dan Veditz an email (dveditz at mozilla). He is a
 very Tor-friendly Mozilla security engineer. He might be too busy to give
 you a full review, but I bet if you also mention that integration with
 Mozilla's Social API is something you're considering, he might be able to
 justify devoting his time for such a review. Or at least point you in the
 right direction for getting a better understanding of the security issues
 the Social API team has had to deal with. I bet they are similar in
 nature.
 >
 > I can also do a review later, but for the next month or two I will be
 extremely busy trying to get TBB working with Firefox 17ESR. I also think
 the people I mentioned might actually be better at it than me (except
 perhaps for spotting potential proxy bypass issues). My approach with
 Torbutton has mostly been "Zomg, don't ever interact with or display
 content window material in XUL." Sadly, even that failed me when
 implementing the content window JS hook injection. Luckily, Dan Veditz
 came to the rescue in that case :).
 >

 I'll get in touch with Dan Veditz.

 >
 >
 > > > Fourth, I guess I am mildly concerned about the crypto security. I
 don't believe it's impossible to do crypto with JS, but I would prefer it
 if the underlying primitive implementations also had a chance for review,
 especially since our inclusion of this addon would probably be seen as
 endorsement of its crypto and security by many.
 > > >
 > > >
 > >
 > > Our OTR implementation has been reviewed. If there is a specific type
 of further review you would wish to ask for, we can see it done.
 > >
 > >
 >
 > I think Nick is the person to best answer this. Or Ian himself. I also
 thought Moxie's observations on the website version were spot-on. Has he
 looked into the browser version?

 Moxie has commented positively on the switch to a plugin version and has
 been optimistic in general. He has not audited the code (or at least, he
 hasn't informed me), but he was the person who recommended the team behind
 our first audit.

 >
 > Things that come to my mind include:
 >
 > Is your implementation fully compatible with other OTR and MPOTR
 implementations? Verifying this to be the case can be one way to probe for
 implementation errors.

 Our OTR implementation is fully compatible with Pidgin-OTR and Adium-OTR.
 We have tested this thoroughly.

 >
 > One question academic researchers in need of racking up publication
 count will drool over is "Can content window JS extract side channel info
 about your crypto operations?" If the JS scheduling mechanism is
 predictable/discoverable and/or runs in the same thread, the answer here
 might actually be "Yes. Very Yes.". Unfortunately, the publication bias in
 academia may very well cause them to structure their experiments such that
 the answer is "Yes" anyway regardless of threading model or content window
 JS timer resolution... :/

 What you wrote here really draws on how new all this research is. Hence
 our long, careful and uncertain discussion...
 I'll get some stuff done on my end and get back to you. Thanks for being
 considerate and open, it really means a lot.

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