See also cautions.rst.
Known Issues
Below is a list of known issues in recent releases of Tahoe-LAFS, and how to manage them. The current version of this file can be found at https://github.com/tahoe-lafs/tahoe-lafs/blob/master/docs/known_issues.rst .
If you’ve been using Tahoe-LAFS since v1.1 (released 2008-06-11) or if you’re
just curious about what sort of mistakes we’ve made in the past, then you
might want to read the “historical known issues” document in
docs/historical/historical_known_issues.txt
.
Known Issues in Tahoe-LAFS v1.10.3, released 30-Mar-2016
Disclosure of file through embedded hyperlinks or JavaScript in that file
Capabilities may be leaked to web browser phishing filter / “safe browsing” servers
Traffic analysis based on sizes of files/directories, storage indices, and timing
Privacy leak via Google Chart API link in map-update timing web page
Disclosure of file through embedded hyperlinks or JavaScript in that file
If there is a file stored on a Tahoe-LAFS storage grid, and that file gets downloaded and displayed in a web browser, then JavaScript or hyperlinks within that file can leak the capability to that file to a third party, which means that third party gets access to the file.
If there is JavaScript in the file, then it could deliberately leak the capability to the file out to some remote listener.
If there are hyperlinks in the file, and they get followed, then whichever server they point to receives the capability to the file. Note that IMG tags are typically followed automatically by web browsers, so being careful which hyperlinks you click on is not sufficient to prevent this from happening.
how to manage it
For future versions of Tahoe-LAFS, we are considering ways to close off this leakage of authority while preserving ease of use – the discussion of this issue is ticket #127.
For the present, a good work-around is that if you want to store and view a file on Tahoe-LAFS and you want that file to remain private, then remove from that file any hyperlinks pointing to other people’s servers and remove any JavaScript unless you are sure that the JavaScript is not written to maliciously leak access.
Command-line arguments are leaked to other local users
Remember that command-line arguments are visible to other users (through the ‘ps’ command, or the windows Process Explorer tool), so if you are using a Tahoe-LAFS node on a shared host, other users on that host will be able to see (and copy) any caps that you pass as command-line arguments. This includes directory caps that you set up with the “tahoe add-alias” command.
how to manage it
As of Tahoe-LAFS v1.3.0 there is a “tahoe create-alias” command that does the following technique for you.
Bypass add-alias and edit the NODEDIR/private/aliases file directly, by adding a line like this:
fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
By entering the dircap through the editor, the command-line arguments are bypassed, and other users will not be able to see them. Once you’ve added the alias, if you use that alias instead of a cap itself on the command-line, then no secrets are passed through the command line. Then other processes on the system can still see your filenames and other arguments you type there, but not the caps that Tahoe-LAFS uses to permit access to your files and directories.
Capabilities may be leaked to web browser phishing filter / “safe browsing” servers
Firefox, Internet Explorer, and Chrome include a “phishing filter” or “safe browing” component, which is turned on by default, and which sends any URLs that it deems suspicious to a central server.
Microsoft gives a brief description of their filter’s operation. Firefox and Chrome both use Google’s “safe browsing API” (specification).
This of course has implications for the privacy of general web browsing (especially in the cases of Firefox and Chrome, which send your main personally identifying Google cookie along with these requests without your explicit consent, as described in Firefox bugzilla ticket #368255.
The reason for documenting this issue here, though, is that when using the Tahoe-LAFS web user interface, it could also affect confidentiality and integrity by leaking capabilities to the filter server.
Since IE’s filter sends URLs by SSL/TLS, the exposure of caps is limited to the filter server operators (or anyone able to hack the filter server) rather than to network eavesdroppers. The “safe browsing API” protocol used by Firefox and Chrome, on the other hand, is not encrypted, although the URL components are normally hashed.
Opera also has a similar facility that is disabled by default. A previous version of this file stated that Firefox had abandoned their phishing filter; this was incorrect.
how to manage it
If you use any phishing filter or “safe browsing” feature, consider either disabling it, or not using the WUI via that browser. Phishing filters have very limited effectiveness , and phishing or malware attackers have learnt how to bypass them.
To disable the filter in IE7 or IE8:
Click Internet Options from the Tools menu.
Click the Advanced tab.
If an “Enable SmartScreen Filter” option is present, uncheck it. If a “Use Phishing Filter” or “Phishing Filter” option is present, set it to Disable.
Confirm (click OK or Yes) out of all dialogs.
If you have a version of IE that splits the settings between security zones, do this for all zones.
To disable the filter in Firefox:
Click Options from the Tools menu.
Click the Security tab.
Uncheck both the “Block reported attack sites” and “Block reported web forgeries” options.
Click OK.
To disable the filter in Chrome:
Click Options from the Tools menu.
Click the “Under the Hood” tab and find the “Privacy” section.
Uncheck the “Enable phishing and malware protection” option.
Click Close.
Known issues in the SFTP frontend
These are documented in Tahoe-LAFS SFTP Frontend and on the SftpFrontend page on the wiki.
Traffic analysis based on sizes of files/directories, storage indices, and timing
Files and directories stored by Tahoe-LAFS are encrypted, but the ciphertext reveals the exact size of the original file or directory representation. This information is available to passive eavesdroppers and to server operators.
For example, a large data set with known file sizes could probably be identified with a high degree of confidence.
Uploads and downloads of the same file or directory can be linked by server operators, even without making assumptions based on file size. Anyone who knows the introducer furl for a grid may be able to act as a server operator. This implies that if such an attacker knows which file/directory is being accessed in a particular request (by some other form of surveillance, say), then they can identify later or earlier accesses of the same file/directory.
Observing requests during a directory traversal (such as a deep-check operation) could reveal information about the directory structure, i.e. which files and subdirectories are linked from a given directory.
Attackers can combine the above information with inferences based on timing correlations. For instance, two files that are accessed close together in time are likely to be related even if they are not linked in the directory structure. Also, users that access the same files may be related to each other.
Privacy leak via Google Chart API link in map-update timing web page
The Tahoe web-based user interface includes a diagnostic page known as the “map-update timing page”. It is reached through the “Recent and Active Operations” link on the front welcome page, then through the “Status” column for “map-update” operations (which occur when mutable files, including directories, are read or written). This page contains per-server response times, as lines of text, and includes an image which displays the response times in graphical form. The image is generated by constructing a URL for the Google Chart API, which is then served by the chart.apis.google.com internet server.
When you view this page, several parties may learn information about your Tahoe activities. The request will typically include a “Referer” header, revealing the URL of the mapupdate status page (which is typically something like “http://127.0.0.1:3456/status/mapupdate-123”) to network observers and the Google API server. The image returned by this server is typically a PNG file, but either the server or a MitM attacker could replace it with something malicious that attempts to exploit a browser rendering bug or buffer overflow. (Note that browsers do not execute scripts inside IMG tags, even for SVG images).
In addition, if your Tahoe node connects to its grid over Tor or i2p, but the web browser you use to access your node does not, then this image link may reveal your use of Tahoe (and that grid) to the outside world. It is not recommended to use a browser in this way, because other links in Tahoe-stored content would reveal even more information (e.g. an attacker could store an HTML file with unique CSS references into a shared Tahoe grid, then send your pseudonym a message with its URI, then observe your browser loading that CSS file, and thus link the source IP address of your web client to that pseudonym).
A future version of Tahoe will probably replace the Google Chart API link (which was deprecated by Google in April 2012) with client-side javascript using d3.js, removing the information leak but requiring JS to see the chart. See ticket #1942 for details.
Known Issues in Tahoe-LAFS v1.9.0, released 31-Oct-2011
Integrity Failure during Mutable Downloads
Under certain circumstances, the integrity-verification code of the mutable downloader could be bypassed. Clients who receive carefully crafted shares (from attackers) will emit incorrect file contents, and the usual share-corruption errors would not be raised. This only affects mutable files (not immutable), and only affects downloads that use doctored shares. It is not persistent: the threat is resolved once you upgrade your client to a version without the bug. However, read-modify-write operations (such as directory manipulations) performed by vulnerable clients could cause the attacker’s modifications to be written back out to the mutable file, making the corruption permanent.
The attacker’s ability to manipulate the file contents is limited. They can modify FEC-encoded ciphertext in all but one share. This gives them the ability to blindly flip bits in roughly 2/3rds of the file (for the default k=3 encoding parameter). Confidentiality remains intact, unless the attacker can deduce the file’s contents by observing your reactions to corrupted downloads.
This bug was introduced in 1.9.0, as part of the MDMF-capable downloader, and affects both SDMF and MDMF files. It was not present in 1.8.3.
how to manage it
There are three options:
Upgrade to 1.9.1, which fixes the bug
Downgrade to 1.8.3, which does not contain the bug
If using 1.9.0, do not trust the contents of mutable files (whether SDMF or MDMF) that the 1.9.0 client emits, and do not modify directories (which could write the corrupted data back into place, making the damage persistent)