[tahoe-lafs-trac-stream] [tahoe-lafs] #1859: Proof-of-concept attack: Upload and execute attacker controlled js from any domain.

tahoe-lafs trac at tahoe-lafs.org
Thu Nov 15 17:42:37 UTC 2012


#1859: Proof-of-concept attack: Upload and execute attacker controlled js from any
domain.
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  davidsarah
  nejucomo               |     Status:  new
         Type:  defect   |  Milestone:  undecided
     Priority:  major    |    Version:  1.9.2
    Component:  code-    |   Keywords:  security javascript same-origin
  frontend-web           |  capleak
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by nejucomo):

 **Impact**:

 I'm a bit embarrassed that I didn't include an impact summary for users:
 I believe using only this technique, a victim would be vulnerable to
 malicious javascript which:

 * uploads content into a grid (possibly filling up available space)
 * accesses any content in the grid for which it (or the attacker) *already
 knows* a capability
 * phishes, by presenting pages that look like the normal tahoe UI but
 which record any secrets entered into those modified pages
 * other annoyances: using bandwidth, opening browser windows, running
 distributed bitcoin miners, burning cpu, eating memory


 **Detection, Mitigation, and Recovery Strategies**:

 In all cases, there are two broad mitigations: Do not use a browser which
 can connect to a tahoe gateway, *or* disable javascript on that browser.

 Note that the first strategy may actually be tricky: Even if you never
 access a gateway from your browser, if they are both running on the same
 host, this attack may be possible.


 Storage Attack:

 The scenario of an attacker storing data with this technique is very
 similar to an attacker knowing the introducer and uploading it themselves.
 It is already the case that any participant in a grid may upload "too
 much" content, so the primary difference is that the attacker may not be
 someone who has received the introducer.furl.

 Detection would require all participants to attest to their storage usage
 then to subtract the difference.  This assumes garbage collection is in
 place.  If the participants don't trust each other they *could* publish
 all of their verify caps, but this exposes some privacy details (the size
 of files/directories and their shape).

 For the first case, this is very similar to a shared grid in which one
 participant uploads a lot of content.  Detection would require noticing
 more data is being uploaded than is expected.

 The attacker gains the ability to upload which they could also have by
 knowing the introducer furl, so this scenario is not too different from a
 loosely managed friend net.

 Whether or not the grid is a loosely banded friend net or a centrally
 managed grid, recovery involves garbage collection.  Detection re

 In the case that the grid is "tightly" controlled, so that all
 participants are known and their storage needs are known


 Accessing Attacker-Controlled Data:

 Once a malicious script has stored data it can retrieve that data.  The
 primary impact is using the victim's bandwidth.  I'm not sure of any
 mitigation or recovery strategies.


 Phishing:

 A mitigation for phishing is to familiarize yourself with the URL scheme
 for all of the standard pages.  If the URL path begins with {{{/uri}}},
 {{{/file}}}, {{{/cap}}}, or {{{/named}}} *and* it looks like one of the
 other url pages, it is potentially a phishing attack.


 Other Annoyances / General:

 In general, detecting malicious javascript may be possible by using your
 browser's javascript console or debugger.  Using a network diagnostic tool
 which shows all http requests (also typically available in a browser's
 javascript or web-developer console), could reveal malicious requests,
 although it may take some effort to distinguish legitimate and
 illegitimate requests.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1859#comment:7>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list