Thus spake Robert Ransom (rransom.8774@gmail.com):
I rewrote most of the ‘Security Concerns’ section for BridgeFinder/Helper. Please merge: https://git.torproject.org/rransom/torspec.git bridgefinder2
Security Concerns: BridgeFinder and BridgeFinderHelper
Do not allow attacks on your IPC channel by malicious local 'live data'
The biggest risk is that unexpected applications will be manipulated into posting malformed data to the BridgeFinder's IPC channel as if it were from BridgeFinderHelper. The best way to defend against this is to require a handshake to properly complete before accepting input. If the handshake fails at any point, the IPC channel MUST be abandoned and closed. Do *not* continue scanning for good input after any bad input has been encountered; that practice may allow cross-protocol attacks by malicious JavaScript running in the user's non-Tor web browser.
Additionally, it is wise to establish a shared secret between BridgeFinder and BridgeFinderHelper, using an environment variable if possible. For an a good example on how to use such a shared secret properly for authentication; see Tor ticket #5185 and/or the SAFECOOKIE Tor control port authentication method.
Do not allow attacks against the Controller
Care has to be taken before converting BridgeFinderHelper data into Bridge lines, especially for cases where the BridgeFinderHelper data is fed directly to the control port after passing through BridgeFinder.
In specific, the input MUST be subjected to a character whitelist and should also be validated against a regular expression to verify format, and if any unexpected or poorly-formed data is encountered, the IPC channel MUST be closed.
Malicious control-port commands can completely destroy a user's anonymity. BridgeFinder is responsible for preventing strings which could plausibly cause execution of arbitrary control-port commands from reaching the Controller.
Provide information about bridge sources to users
BridgeFinder MUST provide complete information about how each bridge was obtained (who provided the bridge data, where the party which provided the data intended that it be sent to users, and what activities BridgeFinder extracted the data from) to users so that they can make an informed decision about whether to trust the bridge.
I like the idea of passing bridge authentication + attribution up to Vidalia via POSTMESSAGE somehow. However, encoding it properly is likely to be problematic and situation-specific.
It also feels weird to have this be a MUST, especially if we're not sure how it can be done right..
BridgeFinder MUST authenticate, for every piece of discovered bridge data, the party which provided the bridge address, the party which prepared the bridge data in BridgeFinder's input format, and the time, location, and manner in which the latter party intended that the bridge data be distributed. (Use of an interactive authentication protocol is not sufficient to authenticate the intended location and manner of distribution of the bridge data; those facts must be explicitly authenticated.) These requirements are intended to prevent or mitigate several serious attacks, including the following: * A malicious bridge can 'tag' its client's circuits so that a malicious exit node can easily recognize them, thereby associating the client with some or all of its anonymous or pseudonymous activities. (This attack may be mitigated by new cryptographic protocols in a near-future version of Tor.) * A malicious bridge can attempt to limit its client's knowledge of the Tor network, thereby biasing the client's path selection toward attacker-controlled relays. * A piece of bridge data containing the address of a malicious bridge may be copied to distribution channels other than those through which it was intended to be distributed, in order to expose more clients to a particular malicious bridge. * Pieces of bridge data containing the addresses of non-malicious bridges may be copied to other-than-intended distribution channels, in order to cause a particular client to attempt to connect to a known, unusual set of bridges, thus allowing a malicious ISP to monitor the client's movements to other network and/or physical locations. BridgeFinder MUST warn users about the above attacks, and warn that other attacks may also be possible if users accept improperly distributed bridge data.
Warning users about technically complicated potential attacks is unlikely to substantially protect them in practice, and will have many negative consequences wrt usability... There is a right place to document this stuff, but I'm not sure the BridgeFinder app itself is that place.
Warning in the event of unexpected behavior that actually happens is a good plan. But this again is something that requires another channel through Vidalia. I doubt most BridgeFinders will have guis :/
We could define a new POSTMESSAGE type "Alert" for example, so Vidalia can inform the user of something fishy on behalf of BridgeFinder? But that brings up localization issues... Do we leave it to BridgeFinder implementations to specify error codes to be sent over POSTMESSAGE, or do we leave it free-form?
Exercise care with what is written to disk
BridgeFinder developers must be aware of the following attacks, and ensure that their software does not expose users to any of them:
An attacker could plant illegal data on a user's computer, to be used later (after a search) as justification to imprison the user.
An attacker could plant malicious data intended to exploit bugs in processes which automatically inspect all files on a user's disks. (Some examples of such processes are indexing services for filesystem search tools, or anti-virus software.)
An attacker could plant malicious data intended to exploit code used by a file manager to extract metadata or thumbnails from files.
An attacker could plant malicious data intended to exploit code run when a user tries to open or view a file. (On Unixoid systems, executable files which are not in a recognized binary format are interpreted by /bin/sh if a user is persuaded to run them. A header is not enough to prevent all attacks of this class; malicious data anywhere within a file could take over a user's computer.)
Note that parties which can be trusted to supply bridges to users should not be trusted with full code-exec privileges on every user's computer. (For example, bridge descriptors are generated and signed by the person who runs a bridge -- but *anyone* can run a bridge and start signing bridge descriptors.)
In order to prevent the above attacks (and others), BridgeFinder MUST NOT create files whose contents (entirely or partially) or names or file extensions are controlled by a party not intended to have full code-exec privileges on every user's computer.
BridgeFinder SHOULD mark data files which are not intended to be executed by the operating system as non-executable, whenever that is possible. (It is not possible when Tor Browser Bundle is run on a FAT filesystem on a Unixoid operating system; that configuration is supported and known to be used.)
One way to avoid the code-exec attacks above is to obfuscate data (using strong cryptography) before writing it to disk. Possible obfuscation methods include 'grizzling' the data [1] (note that the random nonce is important here) or encrypting the data with a newly-generated random key and storing the key with the encrypted data on disk. These do not address the illegal-data attack (because the user is, in theory, able to de-obfuscate and read the data), but they do make it significantly harder for the attacker's goons to 'find' the data during a search.
If a BridgeFinder obfuscates data which it stores on disk, its authors MUST provide a simple program to de-obfuscate the data (with full source code) so that users can find out what data BridgeFinder has collected, and BridgeFinder MUST put a text file named "README.txt" in the directory containing the obfuscated files explaining how to obtain and use the de-obfuscation tool and why such a tool is necessary.
BridgeFinder SHOULD NOT store information to disk which reveals the user's activities in his/her/its non-Tor Browser; some of those activities may not otherwise be visible to a censoring attacker. BridgeFinder MUST NOT store such information to disk unless the user has explicitly asked it to.
Exercise care with where things are written to disk
The Tor Browser Bundle is designed to not leave traces that it has been run on a computer outside the directory in which it was unpacked, and, to the extent possible, to mitigate any such traces left by the operating system.
BridgeFinder MUST NOT write data to disk outside the Tor Browser Bundle directory at any time. BridgeFinder MUST NOT use any operating system features which are known to write data to disk outside the Tor Browser Bundle directory.
If BridgeFinderHelper operates as an extension of a program which the user has installed on his/her/its computer, it (or configuration data needed to cause the non-Tor Browser to load it) may need to be installed outside the Tor Browser Bundle directory. However, BridgeFinderHelper SHOULD NOT write data to disk or cause data to be written to disk outside the TBB directory.
BridgeFinderHelper MUST NOT be installed outside the TBB directory, and MUST NOT write data to disk, unless the user has explicitly permitted that.
The above paragraph makes many otherwise useful BridgeFinderHelpers impossible to implement in practice. It also contradicts the preceding paragraph in terms of MUST vs SHOULD.
In specific, Chrome addons are installed into the user's Chrome profile directory (unless you run them in 'unpacked' mode, which no one will do). I believe WoW addons are similar wrt restricted installation paths. There likely won't be a way to run BridgeFinderHelper plugins for these platforms from inside of the TBB dir.
Unless this is just a typo and you meant BridgeFinder above?
BridgeFinder, BridgeFinderHelper, and their installation routines, MUST warn users that traces written to a disk cannot be erased without erasing the entire filesystem before asking for permission to write outside the TBB directory. (The user has already chosen to leave traces of TBB in the directory it was unpacked into.) On multi-user operating systems which meaningfully support filesystem permissions on the filesystem containing the Tor Browser Bundle, BridgeFinder MUST set permissions correctly on the files it creates. In particular, when filesystem permissions are available, files containing software meant to be run by BridgeFinder MUST NOT be writable by any other OS-level user than the one running BridgeFinder, and files containing data not intended to be loaded by the operating system as an executable file MUST NOT be marked as executable.
Avoid assumptions about BridgeFinder's process environment
BridgeFinder and BridgeFinderHelper MUST NOT allow any data to be sent to their standard output and standard error files. (On Linux, those file descriptors often point to $HOME/.xsession-errors; on MacOS, data sent to an application's stdout or stderr is recorded in /var/log/system.log.)
BridgeFinder and BridgeFinderHelper MUST NOT change their behaviour based on the values or presence of environment variables except as required by IPC protocols which they must conform to. Very few users know that environment variables exist, and many of those who do do not understand how environment variables work. Naive users can easily be conned into setting environment variables which will cause BridgeFinder or BridgeFinderHelper to misbehave.
Do not attempt to operate from within Tor Browser
BridgeFinder and BridgeFinderHelper MUST NOT attempt to automatically obtain information about bridges from within Tor Browser. Doing so would allow an attacker to de-anonymize a pseudonymous user by sending pieces of bridge information to him/her/it, or learn about a user's anonymous activities by planting pieces of bridge information on websites of interest to the attacker. (Checking that pieces of bridge information are signed by a party trusted to provide them is not sufficient to defend against this class of attack; signatures on a piece of bridge information do not authenticate metadata such as the web page meant to distribute it or the e-mail address to which it was sent.)
BridgeFinder SHOULD NOT use information obtained by the user through the Tor Browser. If it does, it MUST only use information explicitly provided to BridgeFinder by the user for the purpose of bridge discovery, and it MUST warn the user that maliciously placed bridge information could be used to identify and/or locate users who receive and use it.
A BridgeFinder or BridgeFinderHelper MAY make its own active connections through Tor for the purpose of finding new bridge addresses (or updating previously acquired addresses), but MUST use Tor's stream isolation feature (Tor proposal 171) to separate BridgeFinder streams from the user's anonymous/pseudonymous activities.
Do not stick beans up the user's nose
Deployed versions of BridgeFinder and BridgeFinderHelper MUST NOT have any debugging features which cause them to log sensitive data to disk. Someone *will* turn them on, whether by accident or by malice.
Development versions of BridgeFinder and BridgeFinderHelper which have such debugging features MUST warn users that they are development builds and should not be used by non-developers.
Requiring users to run special development builds to get any logs is going to mean we won't ever get any logs when things break. I think we're hamstringing ourselves development-wise with this rather silly compile-time requirement.
Perhaps instead we should recommend a log scrubbing mechanism similar to the ones used by Tor and Torbutton.
If BridgeFinder and/or BridgeFinderHelper open listening sockets for IPC purposes, those sockets MUST be bound to a loopback address (not to e.g. IPADDR_ANY). Otherwise, They could probe for your IPC socket's presence on a user's computer.
Inform BridgeFinder developers about these issues
All documents prepared or promoted by Tor Project, Inc. which are intended to be sufficient for the reader to implement a BridgeFinder must describe the known security considerations for BridgeFinders and their underlying rationales.
The BridgeFinder interface is intended to allow developers who are not experts on Tor, and who may not be aware of the unusual threat models which Tor and Tor Browser Bundle address, to write software which users and distributors will integrate into Tor Browser Bundle. These developers are unlikely to be aware of Tor-specific and BridgeFinder-specific security considerations (e.g. attacks involving malicious bridges), and even developers who are informed about the rules stated above may see the rules as unnecessary and ignore them if their rationales are not explicitly stated.
In general, BridgeFinder developers need to be aware that they are writing security-critical code, with a large set of application-specific security requirements on top of the usual security requirements for all software which interacts with an untrusted network.