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

Re: [tor-bugs] #9701 [Firefox Patch Issues]: Prevent TorBrowser from creating clipboardcache turds



#9701: Prevent TorBrowser from creating clipboardcache turds
-------------------------------------+-------------------------------------
     Reporter:  cypherpunks          |      Owner:  mikeperry
         Type:  defect               |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Firefox Patch        |    Version:
  Issues                             |   Keywords:  tbb-disk-leak,
   Resolution:                       |  interview
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-------------------------------------

Comment (by michael):

 DEFENSE OF SIMPLISTIC SOLUTION (IN ATTACHMENT 'msvb-9701.diff') TO THIS
 PROBLEM

 Q1) Why didn't you make the same change in other parts of tor-browser?
 A1) Because there is exactly one place where the data in question is
     written to a disk cache, and it is in the SetData method of the
     nsTransferable interface.

 Q2) Won't other blocks try to read from the disk cache instead of mData?
 A2) No, since they test mData for existence before testing for a cache
 file.

 Q3) Won't the mData memory buffer be exhausted with excessive clipboard
 data?
     In other words isn't the proposed solution vulnerable to a buffer
 overflow?
 A3) Only a reference to the actual data is copied avoiding a buffer
 overflow.
 A3 Oberservation 1) While it's not well understood how the underlying
 browser
                     logic handles memory problems when populating aData,
 any
                     such testing falls into a larger scope of
 DOM/Dragdrop/
                     and other more generic storage questions (and bugs.)
 A3 Oberservation 2) It would seem from the patched code that a valid case
                     for caching clipboard data to disk exists.
 Unfortunately,
                     no documentation exists to support this. Worse, the
                     upstream source code repository doesn't reflect any
                     earlier file history to gain insight.

 Q4) You mean neither writing nor reading of data can lead to a memory
 overflow?
 A4) Yes, the data is in aData from the beginning. Regardless of whether
 the
     data is later stored to a disk cache or not, it was present in memory
     before this solution changed any storage allocation logic.
 A4 Oberservation 3) Investigation is needed to better understand why the
                     upstream author chose to disk cache in the first
 place.

 Q5) What are the security implications of this bug report?
 A5) This bug report (wether applying the proposed solution or not)
     implies memory conditions which could lead to a buffer overflow
     and root compromise of a system running the tor-browser software.
     Note that this potential (probably very low) exists equally whether
     the proposed solution is applied (tor-browser is patched) or not,
     that is the proposed solution carries no added risk.

 Q6) Has the tor-browser been tested thoroughly for the named buffer
 overflow?
 A6) Security analysis of tor-browser without applying the proposed
 solution
     falls outside the scope of this bug report, so it hasn't been carried
     out. Furthermore, the proposed solution carries no added security
 risk.

 Q7) Where did the value kLargeDatasetSize come from?
 A7) Nobody knows, since the very first revisions of nsTransferable.cpp
     and nsTransferable.h contain the logic and constant value.

 Q8) What about implementing memory chunking for large data sets?
 A8) This would require alternative storage, probably defeating the purpose
     of disk avoidance by design. It would also open a large can of worms
     due to Firefox's portable nature as the paste interface of underlying
     platforms behaves differently, requiring several chunking
 implementations.
     Lastly, it is out of the scope of the corresponding bug report.

 Q9) What is the mathematical proof behind the proposed solution defense?
 A9) Assuming that all web pages (DOM) are stored entirely in virtual
 memory,
     and that any web page consumes at most 1/2 available virtual memory,
     and that selected or copied data consumes at most 100% DOM
 representation,
     ...the proposed solution carries no side effects while correcting the
     otherwise violated premise of disk avoidance by design.

 Q10) What documentation was referred to while engineering the proposed
 solution?
 A10  https://developer.mozilla.org/en-US/docs/Using_the_Clipboard/
      https://wiki.mozilla.org/Firefox/Projects/ClipboardAPI
      https://bugzilla.mozilla.org/show_bug.cgi?id=407983
      http://kb.mozillazine.org/Clipboard_not_working
      http://kb.mozillazine.org/Memory_Leak

 Q11) In which source context was the proposed solution engineered?
 A11) After cloning tor-browser and checking out tor-
 browser-24.5.0esr-1-build4

 Q12) How was the proposed solution built?
 A12) By carrying out the command 'cd tor-browser && make -f client.mk'
      After gaining confidence by QA, TBB packages were built for all
 variants.

 Q13) What was tested to assure the quality (QA) of this change?
 A13) The binary tor-browser/obj-x86_64-unknown-linux-gnu/dist/bin/firefox
 was
      launched using code in tor-browser/obj-x86_64-unknown-linux-
 gnu/toolkit/library/libxul.so
      After that, similar launches were carried out on Mac OSX 10.9 AMD64
 and
      Windows 8.1 AMD64 platforms. The launches were observed for symptoms
 of
      the clipboard turd bug and found to be free of this problem once the
      proposed solution was applied. All platforms are affected by this
 bug.

 Q14) Were only tor-browser builds tested for the platforms in question?
 A14) No, the Tor Browser Bundle was created for all platforms (32-bit EN
      variants and 64-bit Linux EN) and tested as well.

 Q15) What was not tested to assure the quality of this change?
 A15) Unit tests were not constructed using the ClipboardHelper and
      Clipboard XPCOM interfaces in order to fully guarantee correctness.
      This can optionally be carried out on request by TPI.
 A15 Oberservation 4) Does a tor-browser or Firefox test harness exist?

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