[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