Changes between Version 11 and Version 12 of Security


Ignore:
Timestamp:
2007-12-17T19:10:08Z (16 years ago)
Author:
zooko
Comment:

re-edit and add some new security issues (removed a lot of unfinished detail on the grounds that it was too technical for this audience)

Legend:

Unmodified
Added
Removed
Modified

  • Security

    v11 v12  
    77= Current Known Security Issues in Tahoe =
    88
    9 * XSRF / Browser-based Attacks
     9as of December 17, 2007
    1010
    11   * #127: the URI of a file is embedded in the URL that is used to access it.
    12     This URI should not be unintentionally revealed to anyone else, because
    13     that would reveal the full contents of the file. There are two current
    14     ways this URI can be unintentionally revealed:
     11 * privilege escalation for directory servers
    1512
    16     * If the file is HTML and contains a hyperlink to an external web server,
    17       any user who follows that hyperlink may reveal the URI to that web
    18       server through the Referrer header.
     13In the v0.6.1 release of Tahoe, it was intended and documented that you could grant read authority, read/write authority, or no authority to any person.  We overlooked the fact that the limitation on write authority does not apply to people who control the directory server on which your encrypted directory resides.  If you grant read-authority to such a person, they automatically get read-write authority.
    1914
    20     * If the file is HTML and contains active content such as Javascript,
    21       that javascript can read the URL (and consequently the secret URI)
    22       as it runs. This javascript may then find some clever way to reveal
    23       the URI to a third party (such as by changing the src= attribute of
    24       an image tag).
     15The next version of Tahoe, v0.7.0, which will be released soon, fixes this issue by using more powerful cryptography.  In Tahoe v0.7.0 you can grant read authority, read/write authority, or no authority to any person and they are unable to get more authority than you've granted them, even if they control some of the servers on which your encrypted files and directories reside.
    2516
    26   * We are thinking about ways to close off this leakage of authority while
    27     preserving ease of use -- the ticket associated with this issue is ticket
    28     #127. In the meantime, a good work-around is to remove all hyperlinks
    29     pointing to external servers from any HTML file that you upload to a
    30     Tahoe grid, and to not store HTML with embedded javascript, if you want
    31     the contents of the file to remain private. Note that no other files or
    32     directories are threatened, only the HREF/JS-bearing HTML file.
     17 * temporary exposure to local attacker
     18
     19In the v0.6.1 release of Tahoe, there was a short window of opportunity in which a local user on your system could read secrets out of the ~/.tahoe directory after they were written into that directory but before their permissions were set to be not-world-readable.  This would be prevented on unix-like systems if you turned off the 'x' permissions bit on your home directory or on the .tahoe directory.  In the upcoming v0.7.0 release of Tahoe such secrets are kept in a subdirectory of the ~/.tahoe directory, named ~/.tahoe/private, which is set so that users other than its owner cannot read data from files within it.
     20
     21 * potential exposure of a file through embedded hyperlinks or JavaScript in that file
     22
     23If there is a file stored on a Tahoe 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.  Anyone who receives the leaked capability gets access to the file.
     24  * JavaScript: if there is JavaScript in the file, then it could deliberately leak the capability to the file out to some remote listener.
     25  * hyperlinks: 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.
     26
     27For future versions of Tahoe, we are considering ways to close off this leakage of authority while preserving ease of use -- the discussion of this issue is ticket #127.
     28
     29For the present, a good work-around is that if you want to store and view a file on Tahoe and you want that file to remain private, then remove from that file any hyperlinks pointing to other people's servers and remove JavaScript unless you are sure that the JavaScript is not written to maliciously leak access.
    3330
    3431= General Security Properties of Tahoe =
    3532
    36 '''The rest of this page, below, is not complete.''' However, you can view
    37 [source:docs/architecture.txt@1432#L472 the detailed technical explanation]
    38 of which this page is eventually intended to be a summary.
     33This is a summary of the general properties of the Tahoe secure decentralized filesystem.
    3934
    40 = The Distributed Filesystem =
     35For technical details, there is [source:docs/architecture.txt the architecture document].
    4136
    42 == Access Control ==
    43 
    44 The Tahoe distributed filesystem is composed of files and directories.
    45 
    46 === Files ===
    47 
    48 ==== read access ====
    49 
    50 Each file has a unique and unguessable identifier, called a "CHK-URI", which
    51 may be derived from the file contents. Possession of this identifier is
    52 necessary and sufficient to download, reconstruct, decrypt, and verify the
    53 integrity of the file. If a person is not given the CHK-URI, then they cannot
    54 see the contents of the file.
    55 
    56 ==== mutation ====
    57 
    58 Files in the Tahoe grid are immutable. If you upload a file to the grid, and
    59 then change part of it and upload it again, then there are now two files in
    60 the grid -- the old one and the new one -- and each has a distinct, unique,
    61 CHK-URI. The directory to which the new file was uploaded will only contain a
    62 reference to the new file. If no other directories still reference the old
    63 file (and if no manual copies of the URI were retained), the old file will be
    64 unreachable.
    65 
    66 A future extension will provide mutable files. For these, a given URI will
    67 not necessarily refer to a specific sequence of bytes, but rather to just the
    68 most recent contents that were uploaded to that URI. Like dirnode URIs, these
    69 URIs will come in read-write and read-only forms, and the file can only be
    70 modified by someone who holds a read-write URI.
    71 
    72 == Traffic Analysis ==
    73 
    74 ''To be filled in.'' Traffic analysis is subtle and powerful. The distributed
    75 nature of Tahoe provides even more information to a passive observer than
    76 usual.
    77 
    78 All traffic between tahoe nodes uses transport-level encryption, so an
    79 attacker must participate in a Tahoe network to obtain visibility into which
    80 shares are being uploaded and downloaded. However, the promiscuous nature of
    81 tahoe's Introduction protocol makes this rather easy.
    82 
    83 In small networks, most server see upload and download requests for all
    84 files. In large networks, an attacker who can provide at least 10% of the
    85 servers (for 3-of-10 encoding) will get to see upload/download requests for
    86 all files. By seeing these requests, the attacker gets to know who is
    87 interested in which files, although they cannot determine the contents of
    88 those files unless they already have a copy (and convergence is being used).
    89 
    90 The directory nodes are encrypted, but all of the dirnodes are stored on the
    91 same central server (the "vdrive server"). This server is in an excellent
    92 position to see who accesses which dirnodes and when, and this information is
    93 sufficient to build a dirnode graph that is equivalent to the user's
    94 plaintext version. For example, if the server sees a get(dirnode#47, "34af")
    95 followed by a get(dirnode#13, "8bb3"), it is safe to assume that dirnode#47
    96 contains dirnode#13 as a subdirectory, and that "34af" is the encrypted form
    97 of the subdir's name.
    98 
    99 This reconstructed graph has file/subdir names which are encrypted but the
    100 same length as the real ones. The file URIs are not known, although if a file
    101 is uploaded or downloaded shortly after a dirnode is accessed it is easy to
    102 relate the two. Again, this points to the identity of the file, but not its
    103 contents. However, it makes it fairly easy for the dirnode server to tell,
    104 e.g., if a lot of users are all referencing the same file.
    105 
    106 A future design will include distributed directory nodes (to improve
    107 availability and reliability). This will result in the same traffic-analysis
    108 exposure as the centralized vdrive server, but makes the traffic visible to
    109 even more servers (anyone who controls more than 10% of the servers will be
    110 able to see all dirnode requests).