[tor-bugs] #9701 [Firefox Patch Issues]: Prevent TorBrowser from creating clipboardcache turds
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 14 23:43:45 UTC 2014
#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
More information about the tor-bugs
mailing list